Are CAs allowed to issue certificates where CN = IP address, no domain name?
Kai Engert
names:
Version: 3 (0x2)
Serial Number: 1156776108 (0x44f300ac)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=CN, O=CNNIC SSL, CN=CNNIC SSL
Validity
Not Before: Jul 17 05:41:12 2009 GMT
Not After : Jul 17 05:41:12 2011 GMT
Subject: C=CN, O=CNNIC SSL, OU=CNNIC SSL, CN=218.241.105.65
It's running live on the IP address seen in the certificate, at the
time of writing, I'm able to connect there using https://
The certificate is being reported as valid in Firefox. It chains up to
CNNIC SSL intermediate CA, further up to Entrust's builtin CA root.
The server cert has no subject-alt-name extension. I'm including the
full chain at the end of this message.
Does the Mozilla CA policy allow to issue such certificates for IP
addresses that belong to the public space (as opposed to Intranet
addresses)?
Kai
-----BEGIN CERTIFICATE-----
MIIDGzCCAgOgAwIBAgIERPMArDANBgkqhkiG9w0BAQUFADA1MQswCQYDVQQGEwJD
TjESMBAGA1UEChMJQ05OSUMgU1NMMRIwEAYDVQQDEwlDTk5JQyBTU0wwHhcNMDkw
NzE3MDU0MTEyWhcNMTEwNzE3MDU0MTEyWjBOMQswCQYDVQQGEwJDTjESMBAGA1UE
CgwJQ05OSUMgU1NMMRIwEAYDVQQLDAlDTk5JQyBTU0wxFzAVBgNVBAMMDjIxOC4y
NDEuMTA1LjY1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyhkj3xQt
Oe04HdZQsxg2tXGftD54REF09xxYK2qwfAPI7/41BLRkJVAuuYYxhx59391A1WUl
NJfG1dwMfUS9/vCONAKbo6fNde/ipjIqkoD+BJFreKB9jzlP/aoG/CUKLNXUozdT
fEXpWv4g5lduA4wdSNoCfzOhiYpMqY1wl7Y46+1GjNii9YnfW+s6wCtWyB/PALDG
B3W/SdEXVtMnk6o9Zig2gjd13dccodqS6biV8LET7ANm3G6EAMwEHrGiIPn4hXnH
52EvDCPs2I82EvSPHjRhntJ610QnAgPMVVZP33NBfkw9dAyAZua3aN/ShWCqP60E
UA8nk5736KTVowIDAQABoxowGDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE8DANBgkq
hkiG9w0BAQUFAAOCAQEAC9H8nzkLNEQLzbnilAvIEC8XzYdICKA3NQBvuIM9k5/A
gTrFvitrxfQRifHtG55SpyJckVImOyTwufLQEXZPIftiW5uPSs7jKQTdwe8rTaaG
l25M80J6uvtc+7wsPQ3tj8dK88vs0ybbYuesy7egSkr5QAPVIpZPjGW38jrOQs/v
QqOguUYg9HWm4yJaTtjaQXgySqmP6Ckk3I1ki/2V5Pc52QeHK1qWWuDTXlbmxTN6
kjcN6czQ8v4XLaMu371TiR0xtVZBlrql2lbrDmqS0Q0BaC7cyz8t7ePejBjGybhi
plUEe63qYIOxhv7pCg9vRbQ0KQP6KNXjjnE8HkztKg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEFzCCA4CgAwIBAgIEQoeioDANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u
ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc
KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u
ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzA1
MTExNDAzMjJaFw0xMjAzMDEwNTAwMDBaMDUxCzAJBgNVBAYTAkNOMRIwEAYDVQQK
EwlDTk5JQyBTU0wxEjAQBgNVBAMTCUNOTklDIFNTTDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAJi/7qMONmdodRqKb5QMZM8XaQLXy26EjTnBblL+WC1y
PGXxTFyYSjrJKB3iUKP1Inj9dymNfQqD0F0p/aWh6RClHb/NoAwR2zjIf8xrStVO
eUCieuDz5l7TVKZ/aklW/UcIzImj9SjRzixzJ0Qdd7L0SW11WgzUd/IEqHHy2DHq
3qJC3qUnfkWLmmPlE7QUJ4cg62kFwZ2vznHb9tlwGEPd2ik4iACBUL8X17x4BV//
DeOl1z75DpDMLjmUTi/vwmsc/1Ko9ElwrfkjF4L7XY/hbQ/N/qmhMMn8OBiIwbTI
14oRS/8eiUqTe0L0KwrC+Yo96HBTBRObAZWgV/X0ZxkCAwEAAaOCAR8wggEbMA4G
A1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEBBCcw
JTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9zZXJ2ZXIxLmNybDARBgNV
HSAECjAIMAYGBFUdIAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8G
A1UdIwQYMBaAFPAXYhNVPbP/CgBr+1CEl/PtYtAaMB0GA1UdDgQWBBRL1eFRFqKn
7aOlx+D/sYcYDsDj1TAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG
9w0BAQUFAAOBgQBE8Wd1YSChOVKq/nmol4vS1BFliayedJBiTW9EfeyCtfPvCb9m
RjpT2+k4P2y9xJSFOB7Z9FsvcjMwqUWdf9qDMWqm4QXddxlztDtZ6PZiSvZ3H+mX
iWa/mCLLmFhoTElB/XYY4aqg/smxWaVJzHcbcP0ED5PeCxQiFpgbHeRVig==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u
ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc
KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u
ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTA1
MjUxNjA5NDBaFw0xOTA1MjUxNjM5NDBaMIHDMQswCQYDVQQGEwJVUzEUMBIGA1UE
ChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5j
b3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBF
bnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUg
U2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGdMA0GCSqGSIb3DQEBAQUA
A4GLADCBhwKBgQDNKIM0VBuJ8w+vN5Ex/68xYMmo6LIQaO2f55M28Qpku0f1BBc/
I0dNxScZgSYMVHINiC3ZH5oSn7yzcdOAGT9HZnuMNSjSuQrfJNqc1lB5gXpa0zf3
wkrYKZImZNHkmGw6AIr1NJtl+O3jEP/9uElY3KDegjlrgbEWGWG5VLbmQwIBA6OC
AdcwggHTMBEGCWCGSAGG+EIBAQQEAwIABzCCARkGA1UdHwSCARAwggEMMIHeoIHb
oIHYpIHVMIHSMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5
BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1p
dHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1pdGVk
MTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCmgJ6AlhiNodHRwOi8vd3d3LmVu
dHJ1c3QubmV0L0NSTC9uZXQxLmNybDArBgNVHRAEJDAigA8xOTk5MDUyNTE2MDk0
MFqBDzIwMTkwNTI1MTYwOTQwWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8Bdi
E1U9s/8KAGv7UISX8+1i0BowHQYDVR0OBBYEFPAXYhNVPbP/CgBr+1CEl/PtYtAa
MAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJKoZI
hvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7Rw7/JXyNEwr75Ji174z4xRAN
95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9n9cd
2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI=
-----END CERTIFICATE-----
Eddy Nigg
> Does the Mozilla CA policy allow to issue such certificates for IP
> addresses that belong to the public space (as opposed to Intranet
> addresses)?
>
Yes :-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
> On 03/02/2010 03:57 PM, Kai Engert:
>> Does the Mozilla CA policy allow to issue such certificates for IP
>> addresses that belong to the public space (as opposed to Intranet
>> addresses)?
>
> Yes :-(
>
Kai, by the way, issuing to internal IP addresses (and host names) is
far worse than to a public IP. Read my article I wrote a while ago about
this subject: https://blog.startcom.org/?p=221
Nelson Bolyard
> On 03/02/2010 03:57 PM, Kai Engert:
>> Does the Mozilla CA policy allow to issue such certificates for IP
>> addresses that belong to the public space (as opposed to Intranet
>> addresses)?
> Yes :-(
There is a place in a certificate specifically intended to be where IP (v4
or v6) addresses may be placed. It is in the Subject Alternative Names
extension. The SubjectAltNames extension has places for both additional DNS
names and for IP addresses. The place for IP addresses takes them in binary
form, not in printable ASCII (e.g. dotted decimal) form.
IMO, it is NOT valid (not standards compliant) for printable ASCII
representations of IP addresses to be placed in any certificate field that
is intended to hold DNS names, including the subject common name and the
DNSName field of the Subject Alternative Names extension.
I would hope that Mozilla's policy explicitly allows only DNS names to be
placed in subject common names, and in the dNSName portion of Subject
Alternative Names. But I suspect that Mozilla's policy does not explicitly
address this, because it instead expects the CAs to conform to the relevant
standards, which impose similar restrictions.
Perhaps we should add code in NSS to not match subject common names to
"domain names" passed in by the client (browser) that appear to be IP
addresses in dotted decimal form.
However, if we did that, it would still be possible for this (or any) CA
to issue standards-compliant certs valid for this same IP address, simply
by putting the IP address where it belongs, rather than in the subject CN.
If we want Mozilla policy to also disallow that, we may have a larger task.
Kathleen Wilson
> On 2010-03-02 07:07 PST, Eddy Nigg wrote:
>> On 03/02/2010 03:57 PM, Kai Engert:
>>> Does the Mozilla CA policy allow to issue such certificates for IP
>>> addresses that belong to the public space (as opposed to Intranet
>>> addresses)?
>
>> Yes :-(
>
> There is a place in a certificate specifically intended to be where IP (v4
> or v6) addresses may be placed. It is in the Subject Alternative Names
> extension. The SubjectAltNames extension has places for both additional DNS
> names and for IP addresses. The place for IP addresses takes them in binary
> form, not in printable ASCII (e.g. dotted decimal) form.
>
> IMO, it is NOT valid (not standards compliant) for printable ASCII
> representations of IP addresses to be placed in any certificate field that
> is intended to hold DNS names, including the subject common name and the
> DNSName field of the Subject Alternative Names extension.
>
Should this be added to the potentially problematic page that talks
about IP addresses?
https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses
> I would hope that Mozilla's policy explicitly allows only DNS names to be
> placed in subject common names, and in the dNSName portion of Subject
> Alternative Names. But I suspect that Mozilla's policy does not explicitly
> address this, because it instead expects the CAs to conform to the relevant
> standards, which impose similar restrictions.
I don't see it in the policy.
> Perhaps we should add code in NSS to not match subject common names to
> "domain names" passed in by the client (browser) that appear to be IP
> addresses in dotted decimal form.
Should I file a bug requesting this code change?
> However, if we did that, it would still be possible for this (or any) CA
> to issue standards-compliant certs valid for this same IP address, simply
> by putting the IP address where it belongs, rather than in the subject CN.
>
> If we want Mozilla policy to also disallow that, we may have a larger task.
Note that the particular cert in this discussion thread is both owned
and issued by CNNIC, for their own website. They have not issued other
certs like this to their clients.
Kathleen
Nelson Bolyard
> On 3/2/10 9:49 AM, Nelson Bolyard wrote:
>> On 2010-03-02 07:07 PST, Eddy Nigg wrote:
>>> On 03/02/2010 03:57 PM, Kai Engert:
>>>> Does the Mozilla CA policy allow to issue such certificates for IP
>>>> addresses that belong to the public space (as opposed to Intranet
>>>> addresses)?
>>> Yes :-(
>> There is a place in a certificate specifically intended to be where IP (v4
>> or v6) addresses may be placed. It is in the Subject Alternative Names
>> extension. The SubjectAltNames extension has places for both additional DNS
>> names and for IP addresses. The place for IP addresses takes them in binary
>> form, not in printable ASCII (e.g. dotted decimal) form.
>>
>> IMO, it is NOT valid (not standards compliant) for printable ASCII
>> representations of IP addresses to be placed in any certificate field that
>> is intended to hold DNS names, including the subject common name and the
>> DNSName field of the Subject Alternative Names extension.
>>
>
> Should this be added to the potentially problematic page that talks
> about IP addresses?
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses
Sure, why not?
>> I would hope that Mozilla's policy explicitly allows only DNS names to be
>> placed in subject common names, and in the dNSName portion of Subject
>> Alternative Names. But I suspect that Mozilla's policy does not explicitly
>> address this, because it instead expects the CAs to conform to the relevant
>> standards, which impose similar restrictions.
>
> I don't see it in the policy.
>
>> Perhaps we should add code in NSS to not match subject common names to
>> "domain names" passed in by the client (browser) that appear to be IP
>> addresses in dotted decimal form.
>
> Should I file a bug requesting this code change?
Yes, please.
>> However, if we did that, it would still be possible for this (or any) CA
>> to issue standards-compliant certs valid for this same IP address, simply
>> by putting the IP address where it belongs, rather than in the subject CN.
>>
>> If we want Mozilla policy to also disallow that, we may have a larger task.
>
> Note that the particular cert in this discussion thread is both owned
> and issued by CNNIC, for their own website. They have not issued other
> certs like this to their clients.
That's good to know.
> Kathleen
Eddy Nigg
>> Note that the particular cert in this discussion thread is both owned
>> and issued by CNNIC, for their own website. They have not issued other
>> certs like this to their clients.
>>
> That's good to know.
LOL, how do you know? Because....????
Eddy Nigg
> Note that the particular cert in this discussion thread is both owned
> and issued by CNNIC, for their own website. They have not issued other
> certs like this to their clients.
Kathleen, does their CA policy prohibit or allow issuance of
certificates to IP addresses? Either they don't issue certificates to IP
addresses or they do. I don't think it can be both.
Kathleen Wilson
>>> There is a place in a certificate specifically intended to be where IP (v4
>>> or v6) addresses may be placed. It is in the Subject Alternative Names
>>> extension. The SubjectAltNames extension has places for both additional DNS
>>> names and for IP addresses. The place for IP addresses takes them in binary
>>> form, not in printable ASCII (e.g. dotted decimal) form.
>>>
>>> IMO, it is NOT valid (not standards compliant) for printable ASCII
>>> representations of IP addresses to be placed in any certificate field that
>>> is intended to hold DNS names, including the subject common name and the
>>> DNSName field of the Subject Alternative Names extension.
>>>
>>
>> Should this be added to the potentially problematic page that talks
>> about IP addresses?
>>
>> https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses
>
> Sure, why not?
>>> I would hope that Mozilla's policy explicitly allows only DNS names to be
>>> placed in subject common names, and in the dNSName portion of Subject
>>> Alternative Names. But I suspect that Mozilla's policy does not explicitly
>>> address this, because it instead expects the CAs to conform to the relevant
>>> standards, which impose similar restrictions.
>>
>> I don't see it in the policy.
>>
>>> Perhaps we should add code in NSS to not match subject common names to
>>> "domain names" passed in by the client (browser) that appear to be IP
>>> addresses in dotted decimal form.
>>
>> Should I file a bug requesting this code change?
>
> Yes, please.
Bug created... https://bugzilla.mozilla.org/show_bug.cgi?id=550592