Closed Bug 526560 Opened 15 years ago Closed 14 years ago

Investigate Comodo issuance of cert to .int domain that doesn't exist

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: johnath, Assigned: kwilson)

References

()

Details

From dev.security:

Hi All,

Yesterday I found a new false issued certificate for defence.external.int. It looks like the
problems with Comodo are still not solved. Isn't it?

The certificate below has been issued by Comodo just a few days ago on the domain external.int which
hasn't been registered.

I'm surprised that this bug is still listed as "new" after it has been open for almost a year.
Comodo apparently not solved the problem.

They are still seen as a trusted certificate authority. But how many false issued certificate would
there be on the Comodo roots? Or is this the only one? I don't think so.

>>>>>>>>>>>>>>>>>>>> THE CERTIFICATE <<<<<<<<<<<<<<<<<<<<

-----BEGIN CERTIFICATE-----
MIIFAzCCA+ugAwIBAgIQNDAhbYnYDq1arx2R5g5oWzANBgkqhkiG9w0BAQUFADB7
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE
AxMYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTA5MTAyOTAwMDAwMFoXDTEw
MTAyOTIzNTk1OVowgcQxCzAJBgNVBAYTAk5MMRAwDgYDVQQREwcyNTE2IEFCMRUw
EwYDVQQIEwxadWlkLUhvbGxhbmQxEjAQBgNVBAcTCVRoZSBIYWd1ZTEVMBMGA1UE
CRMMTWFhbndlZywgMTc0MRAwDgYDVQQKEwdJQ0MtQ1BJMQ0wCwYDVQQLEwRJQ1RT
MSEwHwYDVQQLExhDb21vZG8gUHJlbWl1bVNTTCBMZWdhY3kxHTAbBgNVBAMTFGRl
ZmVuY2UuZXh0ZXJuYWwuaW50MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/
OOGdLQkom++eMFElFnpHt6kJ5IXKYq0+xVMU2IzVtiFE9sbnJgDNVnmMAQckbWyR
y9gd+6fmQDgruYWeCvGJKPOSv2VqqE74EaT2oBpgTEg/g3e3lpbVv8rWCuEx56bH
Cq9oLeKnmnpIr9pEVIBHITEMOIhARd8Z2LHXYTFU2wIDAQABo4IBuzCCAbcwHwYD
VR0jBBgwFoAUMEPcZM0ZXKnzGdI3CZaRngzo1j0wHQYDVR0OBBYEFItAyyoypBx2
5NiOQBkpJUZYt+cyMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEB
AgEDBDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ
UzB/BgNVHR8EeDB2MDqgOKA2hjRodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BQUFD
ZXJ0aWZpY2F0ZVNlcnZpY2VzXzIuY3JsMDigNqA0hjJodHRwOi8vY3JsLmNvbW9k
by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlc18yLmNybDA0BggrBgEFBQcBAQQo
MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTA5BgNVHREE
MjAwghRkZWZlbmNlLmV4dGVybmFsLmludIIYd3d3LmRlZmVuY2UuZXh0ZXJuYWwu
aW50MA0GCSqGSIb3DQEBBQUAA4IBAQAh2751OyeeorzVSe2dDadctYdNNnyEuYKp
8BFRdqjw2/R12zSNHDYaz13ETgFUFqimrdeRcDGgKyy6NC9q/QXmqxbYxnia1SoU
87TzxaK4zW7RlDwfMH2CtUmiSFuB5FAEEjaBsPBF/DrxH7yr8o+Cgb6TRSF8i+SV
MDEBB/DSNeXggLVoBGSAM/qiDTTw0nRcgNX8MUNspMSyaVxjl2wjLKk4yJY9G6kE
R2tzNFfwrrzOrAG9UMNwgqt6MsOEUIf+gSnInawG1DnZbD5gzD9xwU4rIDYs/Lw8
5hh7Ybse5li/RckCC1mAVWk56g9LNLRDoMFOtBwuPfU656nudg94
-----END CERTIFICATE-----

>>>>>>>>>>>>>>>>>>>> WHOIS <<<<<<<<<<<<<<<<<<<<

Registry:  whois.iana.org
Results:

Domain external.int not found.

This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.

>>>>>>>>>>>>>>>>>>>> CRL <<<<<<<<<<<<<<<<<<<<

The crl at:
 http://crl.comodoca.com/AAACertificateServices_2.crl

has no entry of this certificate with serial number:
 ‎3430216D89D80EAD5AAF1D91E60E685B

Certificate Revocation List (CRL):
  Version 2 (0x1)
  Signature Algorithm: sha1WithRSAEncryption
  Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
  Last Update: Nov  3 01:51:21 2009 GMT
  Next Update: Nov  7 01:51:21 2009 GMT
  CRL extensions:
    X509v3 Authority Key Identifier:
      keyid:30:43:DC:64:CD:19:5C:A9:F3:19:D2:37:09:96:91:9E:0C:E8:D6:3D
    X509v3 CRL Number:
      1139

-- 



Rob, Robin - What's the deal, here?
Just to confirm:

$ whois -h whois.iana.org external.int

Domain external.int not found.

This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.
Oh, comment #0 already included my comment #1. My apologies for not reading it completely.
[hoping to hear some feedback from Comodo on how this occurred - I see some @comodo.com addresses in copy]

For those who can't read Base 64, ASN.1 & X.509:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            34:30:21:6d:89:d8:0e:ad:5a:af:1d:91:e6:0e:68:5b
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited,
CN=AAA Certificate Services
        Validity
            Not Before: Oct 29 00:00:00 2009 GMT
            Not After : Oct 29 23:59:59 2010 GMT
        Subject: C=NL/postalCode=2516 AB, ST=Zuid-Holland, L=The
Hague/streetAddress=Maanweg, 174, O=ICC-CPI, OU=ICTS, OU=Comodo PremiumSSL
Legacy, CN=defence.external.int
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bf:38:e1:9d:2d:09:28:9b:ef:9e:30:51:25:16:
                    7a:47:b7:a9:09:e4:85:ca:62:ad:3e:c5:53:14:d8:
                    8c:d5:b6:21:44:f6:c6:e7:26:00:cd:56:79:8c:01:
                    07:24:6d:6c:91:cb:d8:1d:fb:a7:e6:40:38:2b:b9:
                    85:9e:0a:f1:89:28:f3:92:bf:65:6a:a8:4e:f8:11:
                    a4:f6:a0:1a:60:4c:48:3f:83:77:b7:96:96:d5:bf:
                    ca:d6:0a:e1:31:e7:a6:c7:0a:af:68:2d:e2:a7:9a:
                    7a:48:af:da:44:54:80:47:21:31:0c:38:88:40:45:
                    df:19:d8:b1:d7:61:31:54:db
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
               
keyid:30:43:DC:64:CD:19:5C:A9:F3:19:D2:37:09:96:91:9E:0C:E8:D6:3D

            X509v3 Subject Key Identifier: 
                8B:40:CB:2A:32:A4:1C:76:E4:D8:8E:40:19:29:25:46:58:B7:E7:32
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
                  CPS: https://secure.comodo.net/CPS

            X509v3 CRL Distribution Points: 
                URI:http://crl.comodoca.com/AAACertificateServices_2.crl
                URI:http://crl.comodo.net/AAACertificateServices_2.crl

            Authority Information Access: 
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name: 
                DNS:defence.external.int, DNS:www.defence.external.int
    Signature Algorithm: sha1WithRSAEncryption
        21:db:be:75:3b:27:9e:a2:bc:d5:49:ed:9d:0d:a7:5c:b5:87:
        4d:36:7c:84:b9:82:a9:f0:11:51:76:a8:f0:db:f4:75:db:34:
        8d:1c:36:1a:cf:5d:c4:4e:01:54:16:a8:a6:ad:d7:91:70:31:
        a0:2b:2c:ba:34:2f:6a:fd:05:e6:ab:16:d8:c6:78:9a:d5:2a:
        14:f3:b4:f3:c5:a2:b8:cd:6e:d1:94:3c:1f:30:7d:82:b5:49:
        a2:48:5b:81:e4:50:04:12:36:81:b0:f0:45:fc:3a:f1:1f:bc:
        ab:f2:8f:82:81:be:93:45:21:7c:8b:e4:95:30:31:01:07:f0:
        d2:35:e5:e0:80:b5:68:04:64:80:33:fa:a2:0d:34:f0:d2:74:
        5c:80:d5:fc:31:43:6c:a4:c4:b2:69:5c:63:97:6c:23:2c:a9:
        38:c8:96:3d:1b:a9:04:47:6b:73:34:57:f0:ae:bc:ce:ac:01:
        bd:50:c3:70:82:ab:7a:32:c3:84:50:87:fe:81:29:c8:9d:ac:
        06:d4:39:d9:6c:3e:60:cc:3f:71:c1:4e:2b:20:36:2c:fc:bc:
        3c:e6:18:7b:61:bb:1e:e6:58:bf:45:c9:02:0b:59:80:55:69:
        39:ea:0f:4b:34:b4:43:a0:c1:4e:b4:1c:2e:3d:f5:3a:e7:a9:
        ee:76:0f:78
With an NS lookup, domain external.int traces to both IP 63.251.179.27 and 65.200.200.58.  Both of those IP addresses are controlled by AllMar Networks LLC in Virginia, USA.
That would be on your internal network, the domain external.int is not registered.

Public DNS lookup on the OpenDNS name servers:

; <<>> DiG 9.3.4-P1.2 <<>> external.int @208.67.222.222
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63888
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;external.int.                  IN      A

;; Query time: 1 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Nov  4 21:36:23 2009
;; MSG SIZE  rcvd: 30

And directly on one of the .int registered name servers:

; <<>> DiG 9.3.4-P1.2 <<>> external.int @dns1.icann.org NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15402
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;external.int.                  IN      NS

;; AUTHORITY SECTION:
int.                    86400   IN      SOA     dns1.icann.org. noc.icann.org. 2009102300 3600 1800 604800 86400

;; Query time: 153 msec
;; SERVER: 192.0.34.17#53(192.0.34.17)
;; WHEN: Wed Nov  4 21:36:56 2009
;; MSG SIZE  rcvd: 84
(In reply to comment #4)
> With an NS lookup, domain external.int traces to both IP 63.251.179.27 and
> 65.200.200.58.  Both of those IP addresses are controlled by AllMar Networks
> LLC in Virginia, USA.

mojaveg.lsan.mdsg-pacwest.com resolves to those IP addresses (at least from time to time; DNS seems to slightly misconfigured).  I have no idea how that comes into play here.
The DNS resolver services of a number of VERY large ISPs, and at least one 
"open" public DNS service, now have a "feature" whereby, instead of sending 
NXDOMAIN responses, they send back records bearing the IP address of a 
"domain helper" server.  They call this "helping" their subscribers.  
Others call it MITM.  I suspect David ran into one of those.
(In reply to comment #0)
> 
> Rob, Robin - What's the deal, here?

Johnathan,
   We have been investigating this in some detail today (4th Nov).
We have revoked that certificate.
I will post a more extensive answer tomorrow (5th Nov).

Regards
Robin Alden
Comodo
Jonathan,
    The RA through which the certificate was issued is a highly
regarded specialist seller of SSL certificates in The Netherlands.
They are an RA for Comodo and they also sell certificates from the
other major CAs.
They have been involved in the issuance of tens of thousands of
certificates for Comodo.  Their validation work has been checked
repeatedly by us and found to be exemplary.

The certificate in question is an OV certificate issued to the
International Criminal Court in The Hague.  We have double checked
the Organizational element of the validation and found it to be
correct.  It really was ordered by the ICC.

There are two main factors to the error that caused/allowed this
certificate to be issued.

1) Comodo issue SSL certificates for internal domain names - by
which I mean domain names that are not resolvable through the
public DNS.

2) An individual at the RA made a mistake and thought that the
.int domain was not a public TLD, so instead of running their own
domain control validation check they assumed it was an
internal domain name whose control could not be externally
validated.

There are further contributory factors that exacerbated the
problem in this particular case.

The ICC is entitled to a .int domain, and already has one (but not
external.int).

The person who ordered the certificate from the ICC also thought
that .int was an internal TLD and was in fact using it in that
manner.

Actions taken so far:
* The certificate in question has been revoked.
* All other .int certificates issued through that RA, through any
other RA, and directly by Comodo have been reviewed by Comodo.
* As a result 5 further certificates were revoked.
* As a temporary measure, the RA has had their discretionary
ability to use their own domain validation systems removed.
Despite this error we still have confidence in their validation
skills and will be providing training to rectify the shortcomings.

In the light of this mistake, and with the forthcoming flurry of new TLDs from Icann, we will review our provision (both internally and to our RAs) of controls for the correct identification of internal/external domain names.

The mis-issuance of this certificate was due to human error.
We do not regard this as a systemic failure of the RA, or of
Comodo's policies or practices.

Regards
Robin Alden
Comodo
Rob,

issuance of "internal" domains like "www.local" or "www" is a direct violation of the Mozilla policy for CAs:

http://www.mozilla.org/projects/security/certs/policy/, Section 7:
> verify that the entity submitting the certificate signing request has
> registered the domain(s) referenced in the certificate or has been
> authorized by the domain registrant to act on the registrant's behalf;

Given that nobody has "www" or "www.local" registered, nobody can be issued certs for that. The policy is clear on that.
I'm not a mozilla policy expert, but hostname or intranet CNs are a reality and a customer requirement. 
Are you saying that mozilla prohibits securing intranets with SSL?
Intranets can be served by real domain names, for example where domain.com is the public domain name:

www.domain.com => public IP

intern.domain.com => internal network like 10.0.1.0

server.intern.domain.com => Class C IP 10.0.1.25

Hostnames, non-valid TLDs and Class C IP addresses provide no protection whatsoever if public CAs can issue the same certificate to me, you or anybody else. It's snakeoil at best.

This item is being also discussed at the CAB Forum, for which I hope a policy requirement will be defined shortly.
JP, intranet is fine. But you should use "intranet.tbs.com" instead of just "intranet". Bookmarks help. You can get a cert for "intranet.tbs.com", but not for "intranet".

What's internal to A may also be internal to B.
What's the use of getting an SSL cert, when everybody else can get a cert as well? Eddy can describe the hazard (in fact, he already did, while I was typing this).
Another way is set up a HTTP host "http://internal", which simply redirects to "https://intranet.tbs.com".

"https://intranet.tbs.com" can offer the SSL guarantees. Just "intranet" can not.
I just found this certificate (exalg01.chess.int), could you please check because it's not in the current crl.

webmail.chess.nl (chess.nl on: nl) - chess - NL
  DNS:webmail.chess.nl,DNS:exalg01.chess.int,DNS:webmail.exchange.chess-it.com
  webmail.chess.nl
  exalg01.chess.int [dns error]
  webmail.exchange.chess-it.com [other domain]

Serial: B3EA62E9256A4317FB3C28DF90007978

Not in crl version 1141 from Nov  5 02:04:18 2009 GMT

>>>>>>>>>>>>>>>>>>>> WHOIS <<<<<<<<<<<<<<<<<<<<

Registry:  whois.iana.org
Results:

Domain chess.int not found.

This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.

>>>>>>>>>>>>>>>>>>>> THE CERTIFICATE <<<<<<<<<<<<<<<<<<<<

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b3:ea:62:e9:25:6a:43:17:fb:3c:28:df:90:00:79:78
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
        Validity
            Not Before: Jun 24 00:00:00 2008 GMT
            Not After : Jun 24 23:59:59 2011 GMT
        Subject: C=NL/postalCode=2011 NJ, ST=Noord-Holland, L=Haarlem/streetAddress=Nieuwe Gracht 78/2.5.4.18=5021, 2900CA, Haarlem, O=chess, OU=Chess Beheer, OU=Comodo Unified Communications, CN=webmail.chess.nl
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c7:85:13:23:70:31:c6:45:53:d0:45:cb:9e:4a:
                    d6:92:0f:a9:07:c1:6c:17:c7:5c:45:b3:31:ac:3d:
                    69:d3:1a:97:9c:33:ee:96:a7:34:ca:74:94:f1:dc:
                    ec:fb:59:aa:8b:0b:a2:8d:c0:93:28:64:db:8f:d2:
                    07:9e:a4:d5:7e:63:76:3e:a4:55:78:cb:8c:7e:be:
                    9d:2a:94:2d:8b:32:05:aa:88:b3:a3:f3:c9:41:e9:
                    41:68:53:60:cd:78:fe:bd:d9:82:59:0c:7f:90:8f:
                    e0:00:5f:eb:9d:db:2d:b3:8b:7a:cc:45:4b:ba:16:
                    4d:85:9a:e0:42:cf:70:27:5f:fd:81:5e:aa:9f:ea:
                    3e:48:8b:22:60:e7:83:88:d7:7e:2d:ad:6d:3d:00:
                    c8:ed:11:c9:2e:69:aa:cf:50:03:b9:99:b4:65:dc:
                    b0:74:37:61:26:7e:74:09:03:26:ae:a4:a0:e3:b0:
                    0a:2c:ac:98:23:dd:17:ab:04:69:b0:a4:11:42:04:
                    7e:7d:00:33:65:ec:6f:34:23:68:b1:a8:9a:96:af:
                    2c:55:2b:1f:17:f8:2a:02:20:c7:bc:87:70:62:49:
                    cf:90:3a:75:17:8d:31:69:c0:61:a2:b3:bb:3f:4e:
                    aa:2d:63:9c:23:a5:40:77:0b:f0:5b:cb:9e:1d:13:
                    f0:97
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:30:43:DC:64:CD:19:5C:A9:F3:19:D2:37:09:96:91:9E:0C:E8:D6:3D

            X509v3 Subject Key Identifier:
                91:24:F6:E0:5D:2B:7C:40:6A:C5:B1:EF:A9:75:BB:05:2D:F6:F1:2D
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            Netscape Cert Type:
                SSL Client, SSL Server
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
                  CPS: https://secure.comodo.net/CPS

            X509v3 CRL Distribution Points:
                URI:http://crl.comodoca.com/AAACertificateServices_2.crl
                URI:http://crl.comodo.net/AAACertificateServices_2.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name:
                DNS:webmail.chess.nl, DNS:exalg01.chess.int, DNS:webmail.exchange.chess-it.com
    Signature Algorithm: sha1WithRSAEncryption
        52:ec:5f:40:21:c6:e2:87:7e:06:fb:cb:f7:87:6b:76:1b:e6:
        8d:6f:9b:2d:0b:05:36:ac:5c:b8:40:50:cf:8d:33:95:f0:0f:
        e9:0e:62:2f:d4:2e:1a:84:73:87:63:e0:96:cf:16:e8:a1:8b:
        86:49:f6:64:13:8a:c0:d8:29:30:4b:40:03:f4:e1:0c:ae:6e:
        4c:d5:6f:40:93:a4:29:c6:5a:ba:ae:bb:ec:8d:0c:75:30:17:
        25:de:bf:71:74:34:dc:47:16:38:ca:59:33:b8:31:66:5f:f1:
        79:cf:24:66:66:38:f6:2b:f3:23:89:1a:11:ee:bb:9e:0b:5f:
        29:bd:eb:85:05:6f:81:ff:c5:f9:ab:f3:88:f6:26:fe:0f:9d:
        8b:36:c2:11:b9:98:90:74:15:b3:d6:cf:37:86:42:bd:92:27:
        d8:41:b1:5a:e9:37:8b:c1:4e:28:41:74:18:83:d9:ed:a6:c9:
        31:db:28:34:5d:43:6c:22:b5:23:ae:6d:f0:c3:fc:de:d5:7e:
        f2:45:ff:80:df:b2:f9:48:c6:ce:64:92:e4:76:ed:c3:73:82:
        5a:5b:71:6e:78:0e:18:1f:07:fa:ef:16:df:c6:f3:ea:67:b2:
        78:0c:c5:71:0e:24:9d:ea:e5:e0:03:c5:7d:2f:7c:10:e2:eb:
        ad:8f:1d:a2
-----BEGIN CERTIFICATE-----
MIIF2TCCBMGgAwIBAgIRALPqYuklakMX+zwo35AAeXgwDQYJKoZIhvcNAQEFBQAw
ezELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNV
BAMTGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wODA2MjQwMDAwMDBaFw0x
MTA2MjQyMzU5NTlaMIHuMQswCQYDVQQGEwJOTDEQMA4GA1UEERMHMjAxMSBOSjEW
MBQGA1UECBMNTm9vcmQtSG9sbGFuZDEQMA4GA1UEBxMHSGFhcmxlbTEZMBcGA1UE
CRMQTmlldXdlIEdyYWNodCA3ODEeMBwGA1UEEhMVNTAyMSwgMjkwMENBLCBIYWFy
bGVtMQ4wDAYDVQQKEwVjaGVzczEVMBMGA1UECxMMQ2hlc3MgQmVoZWVyMSYwJAYD
VQQLEx1Db21vZG8gVW5pZmllZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQd2Vi
bWFpbC5jaGVzcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMeF
EyNwMcZFU9BFy55K1pIPqQfBbBfHXEWzMaw9adMal5wz7panNMp0lPHc7PtZqosL
oo3Akyhk24/SB56k1X5jdj6kVXjLjH6+nSqULYsyBaqIs6PzyUHpQWhTYM14/r3Z
glkMf5CP4ABf653bLbOLesxFS7oWTYWa4ELPcCdf/YFeqp/qPkiLImDng4jXfi2t
bT0AyO0RyS5pqs9QA7mZtGXcsHQ3YSZ+dAkDJq6koOOwCiysmCPdF6sEabCkEUIE
fn0AM2XsbzQjaLGompavLFUrHxf4KgIgx7yHcGJJz5A6dReNMWnAYaKzuz9Oqi1j
nCOlQHcL8FvLnh0T8JcCAwEAAaOCAeIwggHeMB8GA1UdIwQYMBaAFDBD3GTNGVyp
8xnSNwmWkZ4M6NY9MB0GA1UdDgQWBBSRJPbgXSt8QGrFse+pdbsFLfbxLTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwEQYJYIZIAYb4QgEBBAQDAgbAMEYGA1UdIAQ/MD0wOwYMKwYBBAGy
MQECAQMEMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv
Q1BTMH8GA1UdHwR4MHYwOqA4oDaGNGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FB
QUNlcnRpZmljYXRlU2VydmljZXNfMi5jcmwwOKA2oDSGMmh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzXzIuY3JsMDQGCCsGAQUFBwEB
BCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tME0GA1Ud
EQRGMESCEHdlYm1haWwuY2hlc3MubmyCEWV4YWxnMDEuY2hlc3MuaW50gh13ZWJt
YWlsLmV4Y2hhbmdlLmNoZXNzLWl0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAUuxf
QCHG4od+BvvL94drdhvmjW+bLQsFNqxcuEBQz40zlfAP6Q5iL9QuGoRzh2Pgls8W
6KGLhkn2ZBOKwNgpMEtAA/ThDK5uTNVvQJOkKcZauq677I0MdTAXJd6/cXQ03EcW
OMpZM7gxZl/xec8kZmY49ivzI4kaEe67ngtfKb3rhQVvgf/F+avziPYm/g+dizbC
EbmYkHQVs9bPN4ZCvZIn2EGxWuk3i8FOKEF0GIPZ7abJMdsoNF1DbCK1I65t8MP8
3tV+8kX/gN+y+UjGzmSS5Hbtw3OCWltxbngOGB8H+u8W38bz6meyeAzFcQ4knerl
4APFfS98EOLrrY8dog==
-----END CERTIFICATE-----
For bonus points use split horizon DNS to seamlessly support internal and external users and then let your resolvers append your domain (no need for HTTP-based resolvers).

[re: exalg01.chess.int /facepalm]
Eddy: I do understand your points related to security, and I second that.

What I'm talking about is the real world. People have massively deployed Active Directory with spurious TLDs and this generated a surge in demand for "intranet certs". 

Say it's bad a much as you want, but this is real world!
Sam: sure, please go educate the windows system administrators which named their network joedoe.int and now have hundreds of systems! And go train them to use bind and split dns. Good luck.
(In reply to comment #17)
> Say it's bad a much as you want, but this is real world!

The real world (and that of Microsoft) suggests to use that ONLY in conjunction with MSCA and locally trusted roots which are not trusted elsewhere. Otherwise which protection should it provide? They were NEVER meant to be issued by public CAs.

A public authority MUST issue only to something which is uniquely verifiable. Those public CAs which haven't changed their practices yet will have to change them.
There's no help for a company without a competent admin, that's true. But that doesn't give a right to demands.

You can at least make give hosts a proper hostname which need SSL.
That, as explained, even gives you an advantage: SSL does something meaningful then. SSL for "intranet" is snakeoil.

> then let your resolvers append your domain

FWIW, I don't think that will work. If you type "intranet" in Mozilla's URLbar, DNS might resolve that, but Mozilla will still demand an SSL cert for "intranet", not "intranet.tbs.com". That's why I proposed the HTTP redirect.

JP, you don't need split DNS either (Sam explicitly said "bonus points"). No problem with publishing "intranet.tbs.com A 10.10.10.10" to the Internet. Won't hurt anybody. There *is* a problem for us when *you* hold a cert for "intranet", though.
> You can at least make give hosts a proper hostname which need SSL.

This makes does is no sentence here that. I'll try again:
You can at least give a proper hostname to (only) those hosts which need SSL.
What do you think of this certificate with the CN "owa.b3cables.co.uk\ ", again issued by Comodo.

Serial: D2D0DAD5A1C3E785844AA3C72CA2B191

Not in CRL number 2361 Last Update Nov  5 12:35:19 2009 GMT

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d2:d0:da:d5:a1:c3:e7:85:84:4a:a3:c7:2c:a2:b1:91
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
        Validity
            Not Before: May 30 00:00:00 2008 GMT
            Not After : May 30 23:59:59 2009 GMT
        Subject: C=GB/postalCode=M9 8FP, ST=Lancashire, L=Manchester/streetAddress=Blackley/streetAddress=Delaunays Road, O=Manchester Cables Ltd (T/A) B3 Cable Solutions, OU=Information Systems, OU=Comodo InstantSSL Pro, CN=owa.b3cables.co.uk
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (512 bit)
                Modulus (512 bit):
                    00:b5:1f:fd:37:d1:1e:db:cc:d5:0a:ac:cc:37:14:
                    2c:90:b5:d4:23:b7:2c:b0:0d:07:5d:81:e2:18:10:
                    6b:0e:79:3b:99:d0:78:ab:bf:9a:49:df:07:82:7f:
                    fa:d5:32:d3:5c:70:d5:9b:55:2b:06:31:28:41:eb:
                    b1:7f:04:55:99
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

            X509v3 Subject Key Identifier:
                72:A2:F6:65:6E:A5:6F:8C:C4:6C:E6:A9:FF:BD:BF:42:A2:F4:A4:D4
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            Netscape Cert Type:
                SSL Client, SSL Server
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
                  CPS: https://secure.comodo.net/CPS

            X509v3 CRL Distribution Points:
                URI:http://crl.comodoca.com/UTN-USERFirst-Hardware.crl
                URI:http://crl.comodo.net/UTN-USERFirst-Hardware.crl

            Authority Information Access:
                CA Issuers - URI:http://crt.comodoca.com/UTNAddTrustServerCA.crt
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name:
                DNS:owa.b3cables.co.uk , DNS:www.owa.b3cables.co.uk
    Signature Algorithm: sha1WithRSAEncryption
        ad:a1:3f:88:10:6e:3f:9a:77:f6:de:c3:56:63:64:70:2b:7f:
        e1:e0:16:71:d9:b5:9c:83:e2:d2:f2:09:62:bb:dd:3c:06:db:
        8f:5c:6d:a1:98:24:ad:9b:67:f0:39:33:76:03:58:20:83:92:
        f7:ad:06:e4:2b:e2:20:0d:29:f2:83:55:5d:c0:d6:d7:44:6c:
        9d:9d:1e:00:ae:ac:62:81:45:51:06:ba:02:10:4b:ea:58:a6:
        84:78:74:25:59:10:9c:51:06:5e:46:7f:07:91:86:31:76:51:
        6a:93:f7:fe:02:27:00:d9:60:f5:1e:72:91:f5:81:6f:9a:a9:
        55:ae:80:b7:50:63:d6:4f:47:b4:f0:43:f8:ff:64:dd:56:6b:
        0f:e2:42:e4:77:c7:89:65:dd:c9:bb:fc:8e:3b:db:24:e7:33:
        cd:c3:75:77:94:39:00:ca:c8:3e:c0:53:db:af:c8:3a:41:86:
        45:be:cd:c9:68:a9:2c:3c:41:de:7c:95:18:e7:ec:39:d1:da:
        9f:fc:c2:6e:81:3b:86:fe:c4:55:a8:31:ab:6c:d1:e4:d6:39:
        aa:bd:48:77:c8:96:1e:3b:b9:d2:45:7f:29:59:8c:27:1f:5c:
        c8:15:44:86:51:8e:3e:5f:ad:3f:c3:e6:54:e8:dd:8a:e3:61:
        c6:3c:81:6a
-----BEGIN CERTIFICATE-----
MIIFbTCCBFWgAwIBAgIRANLQ2tWhw+eFhEqjxyyisZEwDQYJKoZIhvcNAQEFBQAw
gZcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY
aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMR8wHQYDVQQDExZVVE4tVVNFUkZpcnN0
LUhhcmR3YXJlMB4XDTA4MDUzMDAwMDAwMFoXDTA5MDUzMDIzNTk1OVowggEJMQsw
CQYDVQQGEwJHQjEPMA0GA1UEERMGTTkgOEZQMRMwEQYDVQQIEwpMYW5jYXNoaXJl
MRMwEQYDVQQHEwpNYW5jaGVzdGVyMREwDwYDVQQJEwhCbGFja2xleTEXMBUGA1UE
CRMORGVsYXVuYXlzIFJvYWQxNzA1BgNVBAoTLk1hbmNoZXN0ZXIgQ2FibGVzIEx0
ZCAoVC9BKSBCMyBDYWJsZSBTb2x1dGlvbnMxHDAaBgNVBAsTE0luZm9ybWF0aW9u
IFN5c3RlbXMxHjAcBgNVBAsTFUNvbW9kbyBJbnN0YW50U1NMIFBybzEcMBoGA1UE
AxMTb3dhLmIzY2FibGVzLmNvLnVrIDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC1
H/030R7bzNUKrMw3FCyQtdQjtyywDQddgeIYEGsOeTuZ0Hirv5pJ3weCf/rVMtNc
cNWbVSsGMShB67F/BFWZAgMBAAGjggIFMIICATAfBgNVHSMEGDAWgBShcl8mGyiY
Q5VdBzfVhZadS9LDRTAdBgNVHQ4EFgQUcqL2ZW6lb4zEbOap/72/QqL0pNQwDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIGwDBGBgNVHSAEPzA9MDsGDCsGAQQB
sjEBAgEDBDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9V
VE4tVVNFUkZpcnN0LUhhcmR3YXJlLmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21v
ZG8ubmV0L1VUTi1VU0VSRmlyc3QtSGFyZHdhcmUuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQWRkVHJ1
c3RTZXJ2ZXJDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTA3BgNVHREEMDAughNvd2EuYjNjYWJsZXMuY28udWsgghd3d3cub3dhLmIz
Y2FibGVzLmNvLnVrIDANBgkqhkiG9w0BAQUFAAOCAQEAraE/iBBuP5p39t7DVmNk
cCt/4eAWcdm1nIPi0vIJYrvdPAbbj1xtoZgkrZtn8DkzdgNYIIOS960G5CviIA0p
8oNVXcDW10RsnZ0eAK6sYoFFUQa6AhBL6limhHh0JVkQnFEGXkZ/B5GGMXZRapP3
/gInANlg9R5ykfWBb5qpVa6At1Bj1k9HtPBD+P9k3VZrD+JC5HfHiWXdybv8jjvb
JOczzcN1d5Q5AMrIPsBT26/IOkGGRb7NyWipLDxB3nyVGOfsOdHan/zCboE7hv7E
Vagxq2zR5NY5qr1Id8iWHju50kV/KVmMJx9cyBVEhlGOPl+tP8PmVOjdiuNhxjyB
ag==
-----END CERTIFICATE-----
Hi Paul,

>What do you think of this certificate with the CN "owa.b3cables.co.uk\ ", again
>issued by Comodo.
>
>Serial: D2D0DAD5A1C3E785844AA3C72CA2B191
>
>Not in CRL number 2361 Last Update Nov  5 12:35:19 2009 GMT

It can't be in the CRL as it is expired ;)
Sorry, you are right, but it's foolish that this cert could be requested in the first place. 

Should this not be automatically detected, the same for a non existing domain.
(In reply to comment #23)
> Hi Paul,
> 
> >What do you think of this certificate with the CN "owa.b3cables.co.uk\ ", again
> >issued by Comodo.
> >
> >Serial: D2D0DAD5A1C3E785844AA3C72CA2B191
> >
> >Not in CRL number 2361 Last Update Nov  5 12:35:19 2009 GMT
> 
> It can't be in the CRL as it is expired ;)

Another good reason to keep revoked certs in the CRL (despite what the RFC says).

The funny thing is, this certificate is still used, haven't they realized that their cert doesn't work and produces an error?
I reiterate and objection from bug #470897 to Mozilla's support for CAs delegating trust to their resellers. The trust Mozilla establishes in the CA should not be transferrable to third parties that Mozilla has not itself verified.
Dear Paul (van Brouwershaven),

You know we had this discussion recently about how good or bad were various CAs, based on our various experiences. That's of course not the topic of this thread... but this .int finding puzzled me and I started checking into my trash bin.

It will not surprise you that I claim that other CAs have done the same human error as the one you reported, probably because it is easy to confuse .int with "intranet". Sorry for those likely to bash on CAs using RAs, but some CAs which do not rely on RAs (as long as I know) have done similar errors.

So let's all review our files are check the .int we have issued..., revoke what needs to be, and add some automated dns checks into our systems to prevent humans making such errors.


As a proof of my claims only, see below a non-expired, non-revoked, invalid .int cert. If you browse the web carefully, you will find more, issued by various CAs.


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0d:aa:09:fc:ff:46:47:86:9c:c2:1d:54:47:66:42:c4
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3
        Validity
            Not Before: Apr  8 00:00:00 2009 GMT
            Not After : Jun 11 23:59:59 2011 GMT
        Subject: C=US, ST=MO, L=Kansas City, O=Walton Construction Company, Inc., OU=MIS, CN=CorpEx01
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:99:2a:eb:1b:22:98:72:b1:9e:ea:3c:02:1e:ad:
                    02:fc:d2:74:9d:2c:56:51:25:b8:01:38:52:00:2e:
                    0a:01:49:85:d1:59:51:87:bb:47:64:76:75:b6:c0:
                    44:89:56:d0:c4:a7:d4:d2:98:3c:82:a1:09:5c:4c:
                    d0:8b:dd:a4:32:b9:7d:93:dd:ce:1b:d9:eb:8f:4e:
                    51:95:c1:60:69:68:16:85:49:26:83:f8:93:79:bc:
                    e6:c7:cd:a4:01:4f:4d:1a:64:7d:cf:53:8e:42:d1:
                    85:f9:b3:26:10:77:74:bc:8c:d0:35:5b:ed:59:bc:
                    e3:3c:63:eb:68:27:a6:b6:ba:29:b2:86:06:c6:22:
                    32:2e:10:ce:e3:14:19:cb:30:95:0d:34:c5:b4:21:
                    02:72:ff:69:98:f9:87:59:75:3d:94:02:f0:ab:3d:
                    51:bc:50:68:83:aa:56:af:58:3a:54:77:e2:0d:c9:
                    14:f6:e6:f5:d7:50:20:f3:90:14:55:b1:f2:b5:8b:
                    fc:4b:f3:cb:f3:50:f7:f8:76:4d:1b:04:51:b1:71:
                    39:09:86:2c:c3:25:57:19:1b:4a:bd:fb:df:9e:81:
                    f9:ae:7d:d3:16:52:6d:7b:ad:68:b5:4d:aa:15:3f:
                    72:18:34:42:11:ed:9b:77:d2:18:93:b4:8a:29:24:
                    9e:73
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:50:EA:73:89:DB:29:FB:10:8F:9E:E5:01:20:D4:DE:79:99:48:83:F7

            X509v3 Subject Key Identifier:
                31:3E:EC:11:D3:FC:40:FB:C9:E3:91:C2:77:78:15:A4:B7:EF:5E:61
            X509v3 Subject Alternative Name:
                DNS:CorpEx01, DNS:webmail.waltonbuilt.com, DNS:corpex01.waltonbuilt.int, DNS:webmail.waltonbuilt.int
            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://www.digicert.com/CACerts/DigiCertHighAssuranceCA-3.crt

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 CRL Distribution Points:
                URI:http://crl3.digicert.com/ca3-2009b.crl
                URI:http://crl4.digicert.com/ca3-2009b.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.1.3.0.1
                  CPS: http://www.digicert.com/ssl-cps-repository.htm
                  User Notice:
                    Explicit Text:

            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption
        a6:75:1b:7e:49:4f:5d:08:ab:db:a4:f1:5c:5c:f7:cb:0a:2c:
        62:d4:22:8d:af:6f:8a:87:c4:67:51:d7:b2:61:57:37:90:9f:
        03:fd:72:2b:15:21:f1:3c:91:98:fc:ee:80:fd:1e:ca:ee:12:
        d6:c6:78:7c:36:d0:b9:e9:15:b2:6c:1a:f6:60:3c:0d:e3:02:
        72:79:b7:ec:fc:14:a9:77:de:40:58:49:45:65:a7:0e:4e:53:
        bf:17:3b:07:aa:58:d7:a0:9d:2d:9b:d4:28:9c:03:ff:39:8d:
        c1:5f:57:b7:31:ac:00:e5:d9:f7:54:b4:8d:51:56:95:3b:a4:
        f1:42:9e:e1:0b:f0:48:a8:d7:16:e4:24:7a:75:69:6a:72:af:
        fe:67:e9:52:2f:ea:e8:85:4b:89:b0:c7:0e:46:2a:ae:2f:4b:
        a2:38:32:96:d4:87:1a:10:2f:d6:37:24:d3:26:12:27:0e:01:
        96:1e:8a:47:df:21:a4:0b:ca:83:75:79:49:29:6c:14:57:d6:
        87:93:95:6e:8c:95:a3:77:00:c7:61:2e:22:94:28:10:be:15:
        7e:09:de:64:f0:37:11:8b:a5:ab:44:9d:72:d8:ec:e9:b7:5e:
        77:f0:f3:f2:4e:ce:68:9a:92:89:1d:5c:61:f0:6b:c1:1c:a0:
        87:85:7e:43
-----BEGIN CERTIFICATE-----
MIIHAzCCBeugAwIBAgIQDaoJ/P9GR4acwh1UR2ZCxDANBgkqhkiG9w0BAQUFADBm
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSUwIwYDVQQDExxEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBDQS0zMB4XDTA5MDQwODAwMDAwMFoXDTExMDYxMTIzNTk1OVowfTELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAk1PMRQwEgYDVQQHEwtLYW5zYXMgQ2l0eTEqMCgGA1UE
ChMhV2FsdG9uIENvbnN0cnVjdGlvbiBDb21wYW55LCBJbmMuMQwwCgYDVQQLEwNN
SVMxETAPBgNVBAMTCENvcnBFeDAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAmSrrGyKYcrGe6jwCHq0C/NJ0nSxWUSW4AThSAC4KAUmF0VlRh7tHZHZ1
tsBEiVbQxKfU0pg8gqEJXEzQi92kMrl9k93OG9nrj05RlcFgaWgWhUkmg/iTebzm
x82kAU9NGmR9z1OOQtGF+bMmEHd0vIzQNVvtWbzjPGPraCemtropsoYGxiIyLhDO
4xQZyzCVDTTFtCECcv9pmPmHWXU9lALwqz1RvFBog6pWr1g6VHfiDckU9ub111Ag
85AUVbHytYv8S/PL81D3+HZNGwRRsXE5CYYswyVXGRtKvfvfnoH5rn3TFlJte61o
tU2qFT9yGDRCEe2bd9IYk7SKKSSecwIDAQABo4IDlDCCA5AwHwYDVR0jBBgwFoAU
UOpzidsp+xCPnuUBINTeeZlIg/cwHQYDVR0OBBYEFDE+7BHT/ED7yeORwnd4FaS3
715hMF8GA1UdEQRYMFaCCENvcnBFeDAxghd3ZWJtYWlsLndhbHRvbmJ1aWx0LmNv
bYIYY29ycGV4MDEud2FsdG9uYnVpbHQuaW50ghd3ZWJtYWlsLndhbHRvbmJ1aWx0
LmludDB/BggrBgEFBQcBAQRzMHEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRp
Z2ljZXJ0LmNvbTBJBggrBgEFBQcwAoY9aHR0cDovL3d3dy5kaWdpY2VydC5jb20v
Q0FDZXJ0cy9EaWdpQ2VydEhpZ2hBc3N1cmFuY2VDQS0zLmNydDAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADBlBgNVHR8EXjBcMCygKqAohiZodHRwOi8vY3Js
My5kaWdpY2VydC5jb20vY2EzLTIwMDliLmNybDAsoCqgKIYmaHR0cDovL2NybDQu
ZGlnaWNlcnQuY29tL2NhMy0yMDA5Yi5jcmwwggHGBgNVHSAEggG9MIIBuTCCAbUG
C2CGSAGG/WwBAwABMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2Vy
dC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6C
AVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp
AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABh
AG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD
AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs
AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABv
AHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBj
AGUALjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQEF
BQADggEBAKZ1G35JT10Iq9uk8Vxc98sKLGLUIo2vb4qHxGdR17JhVzeQnwP9cisV
IfE8kZj87oD9HsruEtbGeHw20LnpFbJsGvZgPA3jAnJ5t+z8FKl33kBYSUVlpw5O
U78XOweqWNegnS2b1CicA/85jcFfV7cxrADl2fdUtI1RVpU7pPFCnuEL8Eio1xbk
JHp1aWpyr/5n6VIv6uiFS4mwxw5GKq4vS6I4MpbUhxoQL9Y3JNMmEicOAZYeikff
IaQLyoN1eUkpbBRX1oeTlW6MlaN3AMdhLiKUKBC+FX4J3mTwNxGLpatEnXLY7Om3
Xnfw8/JOzmiakokdXGHwa8EcoIeFfkM=
-----END CERTIFICATE-----


$ dnsqr NS waltonbuilt.int
33 bytes, 1+0+0+0 records, response, authoritative, nxdomain

$ awhois waltonbuilt.int
[whois.iana.org]

Domain waltonbuilt.int not found.


$ date
Fri Nov  6 21:38:44 GMT 2009

$ openssl ocsp -issuer DigiCertHighAssuranceCA-3.crt -cert waltonbuilt.int.crt  -no_nonce -url http://ocsp.digicert.com -VAfile DigiCertHighAssuranceCA-3.crt
Response verify OK
waltonbuilt.int.crt: good
        This Update: Nov  6 20:54:24 2009 GMT
        Next Update: Nov 13 20:54:24 2009 GMT
Thanks for this update. I suggest to open a new bug for this incident. Perhaps Johnath can create an tracking bug for all those .int certificates.
Jonathan,

    I have a few follow-up points I am obliged to answer/make.

1) Paul, our erstwhile reseller and RA, pointed out a certificate for exalg01.chess.int which had not been revoked.
He is correct, and this was due to a miscommunication within Comodo.  The first part of our check through our historic data had only been for certificates using .int domain names in the Common Name.  I thought we had a complete list when I first responded to this bug but the rest of the list - including 
.int domain names appearing as DNS Names in the subjectAlternativeName - dropped shortly after that. Now a total of 35 certificates have been revoked because of this issue.  Some of the certificates were issued with the involvement of RAs, some direct by Comodo.  

2) A certificate was found with a common name of "owa.b3cables.co.uk\ " - i.e. with <Backslash> <Space> as the last two characters.

This certificate was issued in May 2008 and has now expired. 

We were not ever vulnerable to the NULL character problem in certificate subjects and, although this looks like one of Moxies experiments, I think that Manchester Cables Ltd beat him to it by accident.  It would be quite possible to set up an internal server with this name, and in this case I think the customer set their server this way and then put it on the internet.  I doubt it ever worked as they hoped.

3) We use RAs (Registration Authorities). 

4) We still issue certificates with “internal” domain names in.  By that I mean names that aren’t resolvable in the public DNS system.

We have been following the discussion in the CAB Forum around the minimum standards for SSL and the permitting or forbidding of these internal domain names with interest.  We haven’t so far expressed strong views for or against their being allowed in the minimum guidelines, and we will be happy to abide by the minimum guidelines which ever way the forum finalizes them - happy too that, on past performance at least, we may expect all the other CA members of the forum to abide by the same rules.

At the moment certificates including internal domain names are issued by a number of the larger commercial CAs.  I have current examples to hand issued by DigiCert, Entrust, GeoTrust, GlobalSign, and GoDaddy, who are all fine fellows and who are all present in your root store, I think.

A major consumption of this type of certificates is for UCC certificates (Unified Communications Certificates) for use with Microsoft Exchange servers.

There is undeniably still a considerable demand for certificates with internal domain names in.  It is also undeniable that there are discussions on several forums about the potential risks of such certificates.

I acknowledge that Mozilla CA policy (section 7) discusses the matter of the checking of the registration of registered domain names, but it is not completely clear to me that it also discusses the other possibilities, e.g. where an internal domain name which cannot be registered is used, or where a hostname is used, or where an internet routable IP address is used instead of a domain name, or where a non-internet routable IP address is used instead of a domain name.
I acknowledge that the "Problematic Practices" page is much clearer on the matter.

I am reluctant to cease issuing certificates with "internal" domain names in on a unilateral basis as I feel it would unfairly disadvantage Comodo in the market place.
That does not mean that I would fail to respond to a clear edict from Mozilla that "This practice must stop, or else.." - especially if it were equally applied to all CAs.

Regards
Robin Alden

Comodo
"A major consumption of this type of certificates is for UCC certificates
(Unified Communications Certificates) for use with Microsoft Exchange servers."

Yes.  And on the mailing list, I posted links to the Microsoft whitepaper related to UCCs.  It recommends including the netbios name, but it should not unless the server is ever accessed, via https, via the netbios-looked-up name.

This is the same problem as .local as part of zeroconf/Bonjour.
We at DigiCert had a similar issue to Comodo's: due to a miscommunication (basically, not everyone was aware that .int was a TLD), we issued five certificates with .int names in them (many months ago).  One has expired.  Two others are up for expiration in the next three months or so.  The last two have a year or two left before expiration.  We did an internal audit a few days ago and spotted these (along with the dozens of certificates we had refused to issue due to the presence of .int names), and we are working with these few customers to get those certificates revoked.  They will be revoked within two weeks (hopefully sooner, but we need to allow our customers time to make the necessary changes to their systems).

We have updated our training procedures to ensure that all validation staff are aware of this situation.  We have also implemented systems that will throw a red flag for this particular situation (.int names).

Thank you for the heads-up.

Jeff J. Snider
DigiCert VP of Development
Seems as though recognition of known TLDs should be automated and not left 
up to human memories, no?
Especially with the plethora of country-code TLDs, and lesser-known TLDs like .info, .pro, and experimental new ones coming...
You are absolutely correct, Nelson.  DigiCert does not rely on human memories
for the recognition of known TLDs.  We made the fixes long ago to stop issuing
these certs; unfortunately, we dropped the ball a little bit on getting
previously issued certificates revoked.  It wasn't until the issue came up this
week in the CA/B Forum mailing lists that we checked our database and realized
that there were some unrevoked certificates to deal with, and we immediately
began dealing with them.
(In reply to comment #27)
> You know we had this discussion recently about how good or bad were various
> CAs, based on our various experiences. That's of course not the topic of this
> thread... but this .int finding puzzled me and I started checking into my trash
> bin.

I remember me that nice discussion in Munich of cource, it was about Comodo letting there RAs issue certificates without a proper vetting and that we have seen various false (or highly probably false) issued certificates. 

> It will not surprise you that I claim that other CAs have done the same human
> error as the one you reported, probably because it is easy to confuse .int with
> "intranet". Sorry for those likely to bash on CAs using RAs, but some CAs which
> do not rely on RAs (as long as I know) have done similar errors.

I could not found any certificates from the major CAs till know. And unfortunately have not seen this DigiCert cert, if I found more (also from other CAs) I will let you know!

Normally I prefer to discuss this internally with the CA directly but in the case for Comodo we don't get a proper report/response nor they are willing to change there procedures so we have to do this publicly.
(In reply to comment #29)
> 1) Paul, our erstwhile reseller and RA, pointed out a certificate for
> exalg01.chess.int which had not been revoked.

It's nice that you point that out, though most of you would already know. This whole thing with proper validation has is started as a former Comodo RA and we had lots of discussions about this with Comodo. Thats also the reason I have doubts about there procedures!

- As a former Comodo CA we experienced that there was no training, examination or supervision for a RA.
- Afther the mozilla.com issue we raised questions about their trustworthiness.
- I think Comodo is bringen other CAs in danger by not controlling the validation of there issued certificates and so damaging the trustworthiness of SSL in general.
- I'm always open for a discussion, Comodo is not willing to talk about this unless I keep quiet (remove the notice in our site check and my publiction at: https://www.networking4all.com/en/support/tools/site+check/comodo/).

> He is correct, and this was due to a miscommunication within Comodo.  The first
> part of our check through our historic data had only been for certificates
> using .int domain names in the Common Name.  I thought we had a complete list
> when I first responded to this bug but the rest of the list - including 
> .int domain names appearing as DNS Names in the subjectAlternativeName -
> dropped shortly after that. Now a total of 35 certificates have been revoked
> because of this issue.  Some of the certificates were issued with the
> involvement of RAs, some direct by Comodo.  

Thanks, I'm glad this certificates are revoked now.

> 2) A certificate was found with a common name of "owa.b3cables.co.uk\ " - i.e.
> with <Backslash> <Space> as the last two characters.
> 
> This certificate was issued in May 2008 and has now expired. 
> 
> We were not ever vulnerable to the NULL character problem in certificate
> subjects and, although this looks like one of Moxies experiments, I think that
> Manchester Cables Ltd beat him to it by accident.  It would be quite possible
> to set up an internal server with this name, and in this case I think the
> customer set their server this way and then put it on the internet.  I doubt it
> ever worked as they hoped.

- Was this certificate been revoked before the expiration date or have you never heard from it?
- Is this certificate issued by Comodo or by a RA?
Comodo and DigiCert are not the only CA's that issue certificates for the .int TLD. Below are certificates from GeoTrust and VeriSign (the CA's that Paul uses himself) which are issued to non existent .int domainnames. I would guess that this problem is endemic through all CA's - simply because the .int domain happens to be easily confused with internal domain names, and relatively few people are aware of its status as TLD - and as such we need to concentrate on finding a structural solution to this problem rather than trashing one's competitors. Human errors unfortunately happen, to CA's with or without RA's.


GeoTrust Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 753632 (0xb7fe0)
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
       Validity
           Not Before: Jun 14 16:26:03 2009 GMT
           Not After : Jun 17 00:51:50 2010 GMT
       Subject: C=GB, ST=Lancashire, L=Preston, O=The Life Channel, CN=mail.tplg.co.uk
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (2048 bit)
               Modulus (2048 bit):
                   00:9b:15:40:87:57:9e:b2:3a:d5:d4:57:88:a6:e8:
                   b5:9f:6a:a2:5b:79:68:3f:e7:ea:3c:48:9d:8d:45:
                   25:ad:28:87:cf:f4:a6:d3:75:8c:00:90:1c:0d:9d:
                   54:e1:cd:36:5f:c1:d4:20:b9:06:98:55:78:90:c7:
                   86:85:a9:eb:80:29:0b:dc:5f:fa:f5:87:d7:39:d0:
                   b0:84:0c:19:36:62:50:94:be:7f:8c:0f:3b:4f:66:
                   a9:37:44:f4:a0:34:19:4e:a4:cf:7b:fe:50:13:e7:
                   05:64:de:7b:69:a7:fa:42:ba:47:14:9c:57:6f:11:
                   1c:4f:8b:60:4c:fc:c4:03:ef:8f:db:45:29:9e:1a:
                   ca:1b:41:a8:ba:84:63:b9:a3:a9:c6:bc:8f:fb:03:
                   59:74:8b:7e:05:e1:4f:89:76:92:24:81:6d:5d:30:
                   18:b7:03:1e:f0:3e:75:8f:51:2a:d9:86:5d:48:ad:
                   80:4a:46:f4:01:5a:37:48:0b:9b:32:1b:30:f6:5c:
                   2a:f1:27:93:63:74:31:5d:4f:f5:4a:5e:11:e7:80:
                   b5:b4:89:a7:1e:42:71:ee:e2:62:80:d6:e6:60:5b:
                   50:c9:cd:bf:fb:8c:08:7b:52:9c:9a:96:6c:ec:cc:
                   5c:8f:0e:77:e1:15:1a:65:5b:a7:fa:53:6b:34:ca:
                   55:13
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Key Usage: critical
               Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
           X509v3 Subject Key Identifier:
               09:12:C7:3A:1A:13:5D:26:47:92:84:5D:5B:7F:35:8B:63:FA:5D:B8
           X509v3 CRL Distribution Points:
               URI:http://crl.geotrust.com/crls/secureca.crl

           X509v3 Subject Alternative Name:
               DNS:autodiscover.tplg.co.uk, DNS:tlcexch01, DNS:tlcexch01.ross-comm.int, DNS:mail.tplg.co.uk
           X509v3 Authority Key Identifier:
keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4

           X509v3 Extended Key Usage:
               TLS Web Server Authentication, TLS Web Client Authentication
   Signature Algorithm: sha1WithRSAEncryption
       81:5c:64:5f:64:6e:c1:9b:87:10:cc:66:05:98:2f:f1:e1:de:
       90:ec:18:1a:4b:89:09:aa:08:ac:4f:85:2f:91:3b:6d:3e:7c:
       03:e1:fc:83:1b:34:62:a9:46:70:45:d8:d5:66:5c:93:5b:79:
       d2:ca:d5:fe:01:24:20:15:23:4c:4c:b1:fa:13:07:17:ce:0c:
       3c:ce:b5:7a:cf:1c:29:4d:61:68:85:6f:a4:47:82:a0:c7:da:
       04:d9:b9:7d:52:9a:72:2c:3a:e5:59:cd:7a:ca:11:3f:94:a3:
       d4:ab:f9:bb:3a:ac:73:c8:9a:f0:23:25:d7:d2:1c:24:95:95:
       e3:74
-----BEGIN CERTIFICATE-----
MIIDvTCCAyagAwIBAgIDC3/gMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNjE0MTYyNjAzWhcNMTAwNjE3MDA1MTUw
WjBpMQswCQYDVQQGEwJHQjETMBEGA1UECBMKTGFuY2FzaGlyZTEQMA4GA1UEBxMH
UHJlc3RvbjEZMBcGA1UEChMQVGhlIExpZmUgQ2hhbm5lbDEYMBYGA1UEAxMPbWFp
bC50cGxnLmNvLnVrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmxVA
h1eesjrV1FeIpui1n2qiW3loP+fqPEidjUUlrSiHz/Sm03WMAJAcDZ1U4c02X8HU
ILkGmFV4kMeGhanrgCkL3F/69YfXOdCwhAwZNmJQlL5/jA87T2apN0T0oDQZTqTP
e/5QE+cFZN57aaf6QrpHFJxXbxEcT4tgTPzEA++P20UpnhrKG0GouoRjuaOpxryP
+wNZdIt+BeFPiXaSJIFtXTAYtwMe8D51j1Eq2YZdSK2ASkb0AVo3SAubMhsw9lwq
8SeTY3QxXU/1Sl4R54C1tImnHkJx7uJigNbmYFtQyc2/+4wIe1KcmpZs7Mxcjw53
4RUaZVun+lNrNMpVEwIDAQABo4IBCDCCAQQwDgYDVR0PAQH/BAQDAgTwMB0GA1Ud
DgQWBBQJEsc6GhNdJkeShF1bfzWLY/pduDA6BgNVHR8EMzAxMC+gLaArhilodHRw
Oi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBXBgNVHREEUDBO
ghdhdXRvZGlzY292ZXIudHBsZy5jby51a4IJdGxjZXhjaDAxghd0bGNleGNoMDEu
cm9zcy1jb21tLmludIIPbWFpbC50cGxnLmNvLnVrMB8GA1UdIwQYMBaAFEjmaPkr
0rKV10fYIyAQTzOYkJ/UMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAN
BgkqhkiG9w0BAQUFAAOBgQCBXGRfZG7Bm4cQzGYFmC/x4d6Q7BgaS4kJqgisT4Uv
kTttPnwD4fyDGzRiqUZwRdjVZlyTW3nSytX+ASQgFSNMTLH6EwcXzgw8zrV6zxwp
TWFohW+kR4Kgx9oE2bl9UppyLDrlWc16yhE/lKPUq/m7OqxzyJrwIyXX0hwklZXj
dA==
-----END CERTIFICATE-----

[Querying whois.iana.org]
[whois.iana.org]

Domain ross-comm.int not found.


Verisign Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           4b:0a:a4:8c:90:ca:95:1e:dd:cd:73:01:ce:2a:2e:c0
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)05, CN=VeriSign Class 3 Secure Server CA
       Validity
           Not Before: Nov 11 00:00:00 2008 GMT
           Not After : Nov 11 23:59:59 2009 GMT
       Subject: C=DK, ST=Koebenhavn, L=K\xC3\xB8ebenhavn Oe., O=Dansk Roede Kors, OU=Dansk Roede Kors, CN=mail.drk.dk
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (2048 bit)
               Modulus (2048 bit):
                   00:9e:21:8e:d6:dc:cc:d4:4e:0e:ee:ae:c0:f5:7f:
                   b0:59:1b:ac:87:d3:e9:61:41:f7:b0:1e:cb:4d:83:
                   9f:4f:f1:af:e8:01:f0:5e:72:69:b5:97:69:46:ff:
                   93:15:35:be:dd:f7:9e:f4:7c:a7:e0:d9:13:ca:b1:
                   6e:a9:e2:a0:85:9c:e2:fe:48:06:ce:c4:32:ee:99:
                   a2:b6:7d:49:70:55:e8:cd:a5:3c:f5:d7:06:93:d7:
                   03:19:1a:69:71:ab:e8:d4:26:ed:9f:ef:5c:c6:3e:
                   91:46:4f:32:dd:69:d9:a6:b7:5b:6d:e1:d7:fc:50:
                   71:24:48:2f:6d:5f:45:d0:2b:f5:7f:e6:0e:e4:08:
                   41:f5:e2:f2:4f:c5:e5:20:96:f1:66:45:a9:d7:21:
                   63:0c:f4:36:f2:03:60:24:70:37:1b:fc:9d:78:da:
                   9b:e2:7b:0b:07:d6:ae:4b:2b:a2:40:20:90:8e:c4:
                   24:88:d8:48:46:63:c1:d1:8b:be:2f:4d:27:1c:4b:
                   fd:d7:d9:f3:5b:40:76:11:27:4d:ea:c3:20:dd:cd:
                   09:2c:2e:10:72:b1:ce:da:7d:da:6c:d4:11:83:5c:
                   eb:1a:b2:e2:8c:99:f1:25:e6:72:38:da:1a:1d:ee:
                   8b:b8:8f:21:f2:a6:ae:6d:42:6c:3c:27:2c:b7:5f:
                   8e:a7
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Key Usage: critical
               Digital Signature, Key Encipherment
           X509v3 Subject Alternative Name:
               DNS:mail.drk.dk, DNS:autodiscover.drk.dk, DNS:webmail.drk.dk, DNS:folke.drk.int
           X509v3 Basic Constraints:
               CA:FALSE
           X509v3 CRL Distribution Points:
               URI:http://SVRSecure-crl.verisign.com/SVRSecure2005.crl

           X509v3 Certificate Policies:
               Policy: 2.16.840.1.113733.1.7.23.3
                 CPS: https://www.verisign.com/rpa

           X509v3 Extended Key Usage:
               TLS Web Server Authentication, TLS Web Client Authentication
           X509v3 Authority Key Identifier:
keyid:6F:EC:AF:A0:DD:8A:A4:EF:F5:2A:10:67:2D:3F:55:82:BC:D7:EF:25

           Authority Information Access:
               OCSP - URI:http://ocsp.verisign.com
               CA Issuers - URI:http://SVRSecure-aia.verisign.com/SVRSecure2005-aia.cer

           1.3.6.1.5.5.7.1.12:
0`.^.\0Z0X0V..image/gif0!0.0...+......Kk.(.....R8.).K..!..0&.$http://logo.verisign.com/vslogo1.gif
   Signature Algorithm: sha1WithRSAEncryption
       8e:15:ca:85:97:8b:3b:34:c5:9f:7e:17:54:2d:4c:8c:20:1e:
       55:19:9d:30:58:26:e5:74:05:89:32:9a:0e:41:16:57:ae:70:
       fa:2c:e8:1a:16:a0:57:47:a3:4d:97:07:78:ef:91:4b:7e:ed:
       34:07:8b:d0:1d:96:ff:2f:5a:0c:b5:33:ba:9c:44:48:1b:3b:
       d2:78:f8:a5:c4:b3:54:fe:db:80:e0:78:51:9f:92:a5:c3:3d:
       c9:fb:80:6e:f2:99:ce:b8:46:ac:7d:0f:91:23:7e:f6:65:44:
       24:00:2b:c5:6a:3a:32:b1:8c:db:e0:83:c3:a5:ee:cd:e4:5c:
       69:7c:71:a8:c4:d1:00:7e:61:b4:5e:4b:98:d2:37:97:1e:99:
       ba:6a:57:a3:d3:df:64:64:89:2c:64:58:7b:90:e7:ae:d7:0b:
       dd:f6:d7:c9:f5:e7:6c:54:32:e7:13:09:87:95:7a:d9:36:60:
       54:10:0d:15:c6:4b:b7:e9:62:eb:35:fb:6d:8b:dd:85:d4:39:
       39:13:5d:fb:c9:c3:9a:6e:52:99:a9:f4:3f:75:0c:26:25:05:
       aa:79:48:b9:78:66:b6:28:13:28:de:d4:bb:27:32:18:b0:03:
       8b:c9:f3:3d:6b:8d:d7:a9:dd:5c:c0:6a:dd:0a:0c:a6:25:41:
       2e:31:e9:09
-----BEGIN CERTIFICATE-----
MIIF6DCCBNCgAwIBAgIQSwqkjJDKlR7dzXMBziouwDANBgkqhkiG9w0BAQUFADCB
sDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMh
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBMB4XDTA4MTExMTAwMDAw
MFoXDTA5MTExMTIzNTk1OVowgYgxCzAJBgNVBAYTAkRLMRMwEQYDVQQIEwpLb2Vi
ZW5oYXZuMRgwFgYDVQQHFA9Lw7hlYmVuaGF2biBPZS4xGTAXBgNVBAoUEERhbnNr
IFJvZWRlIEtvcnMxGTAXBgNVBAsUEERhbnNrIFJvZWRlIEtvcnMxFDASBgNVBAMU
C21haWwuZHJrLmRrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAniGO
1tzM1E4O7q7A9X+wWRush9PpYUH3sB7LTYOfT/Gv6AHwXnJptZdpRv+TFTW+3fee
9Hyn4NkTyrFuqeKghZzi/kgGzsQy7pmitn1JcFXozaU89dcGk9cDGRppcavo1Cbt
n+9cxj6RRk8y3WnZprdbbeHX/FBxJEgvbV9F0Cv1f+YO5AhB9eLyT8XlIJbxZkWp
1yFjDPQ28gNgJHA3G/ydeNqb4nsLB9auSyuiQCCQjsQkiNhIRmPB0Yu+L00nHEv9
19nzW0B2ESdN6sMg3c0JLC4QcrHO2n3abNQRg1zrGrLijJnxJeZyONoaHe6LuI8h
8qaubUJsPCcst1+OpwIDAQABo4ICIjCCAh4wDgYDVR0PAQH/BAQDAgWgMEoGA1Ud
EQRDMEGCC21haWwuZHJrLmRrghNhdXRvZGlzY292ZXIuZHJrLmRrgg53ZWJtYWls
LmRyay5ka4INZm9sa2UuZHJrLmludDAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3
oDWGM2h0dHA6Ly9TVlJTZWN1cmUtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1cmUy
MDA1LmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFG/sr6DdiqTv9SoQZy0/VYK81+8lMHkG
CCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24u
Y29tMEMGCCsGAQUFBzAChjdodHRwOi8vU1ZSU2VjdXJlLWFpYS52ZXJpc2lnbi5j
b20vU1ZSU2VjdXJlMjAwNS1haWEuY2VyMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBY
MFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY
MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjANBgkqhkiG
9w0BAQUFAAOCAQEAjhXKhZeLOzTFn34XVC1MjCAeVRmdMFgm5XQFiTKaDkEWV65w
+izoGhagV0ejTZcHeO+RS37tNAeL0B2W/y9aDLUzupxESBs70nj4pcSzVP7bgOB4
UZ+SpcM9yfuAbvKZzrhGrH0PkSN+9mVEJAArxWo6MrGM2+CDw6XuzeRcaXxxqMTR
AH5htF5LmNI3lx6ZumpXo9PfZGSJLGRYe5DnrtcL3fbXyfXnbFQy5xMJh5V62TZg
VBANFcZLt+li6zX7bYvdhdQ5ORNd+8nDmm5Sman0P3UMJiUFqnlIuXhmtigTKN7U
uycyGLADi8nzPWuN16ndXMBq3QoMpiVBLjHpCQ==
-----END CERTIFICATE-----

[Querying whois.iana.org]
[whois.iana.org]

Domain drk.int not found.
The solution should be, not search for false positives, but to allow only approved TLDs. That means, CAs should perform a WHOIS lookup for each and every hostname listed in the certificate and positively confirm that the domain in question exists and was verified.

All the .int hostnames found recently in all those certificates are not a disaster - mostly because the likelihood of an attack on users is rather low, but it confirms an incorrect approach when dealing with certificates issued by the public certification authorities. This should be corrected by the CAs and Mozilla should follow through with its own policies.
Agreed re: whitelisting, however the claim that "the likelihood of an attack on users is rather low" is completely without basis SFAICT. If I can get onto your network and convince your machines to talk to me instead of mail.acme.int by spoofing DNS or similar then I'm home and hosed... (or should I say, you're hosed). This is trivially easy compared to circumventing SSL/TLS. Or have I missed something?
I meant, the likelihood of an attack on a public web site is rather low - those aren't paypal.com certificates. However you are right, the enterprise networks are at risk, but it's a different discussion.

As long as public CAs continue to issue certificates with so-called internal domains, NetBIOS names and Class C IPs, they remain at risk - with and without the .int certificates recently discovered.

Mozilla has a clear policy requiring CAs to validate the *registered* domains. Mozilla's CA policy has no criteria for hostnames, fake TLDs and such. The affected CAs must change their procedures in order to conform to the Mozilla CA policy.
One could also argue that said enterprises should know better than to rely on such things, but better to remove dangerous items from sale than rely on sanity of end-users to avoid self harm.
(In reply to comment #37)
> Comodo and DigiCert are not the only CA's that issue certificates for the .int
> TLD. Below are certificates from GeoTrust and VeriSign (the CA's that Paul uses
> himself) which are issued to non existent .int domainnames. I would guess that
> this problem is endemic through all CA's - simply because the .int domain
> happens to be easily confused with internal domain names, and relatively few
> people are aware of its status as TLD - and as such we need to concentrate on
> finding a structural solution to this problem rather than trashing one's
> competitors. Human errors unfortunately happen, to CA's with or without RA's.
> GeoTrust Certificate:
>    Data:
>        Version: 3 (0x2)
>        Serial Number: 753632 (0xb7fe0)
>        Signature Algorithm: sha1WithRSAEncryption
>        Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
>        Validity
>            Not Before: Jun 14 16:26:03 2009 GMT
>            Not After : Jun 17 00:51:50 2010 GMT
>        Subject: C=GB, ST=Lancashire, L=Preston, O=The Life Channel,
> CN=mail.tplg.co.uk
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (2048 bit)
>                Modulus (2048 bit):
>                    00:9b:15:40:87:57:9e:b2:3a:d5:d4:57:88:a6:e8:
>                    b5:9f:6a:a2:5b:79:68:3f:e7:ea:3c:48:9d:8d:45:
>                    25:ad:28:87:cf:f4:a6:d3:75:8c:00:90:1c:0d:9d:
>                    54:e1:cd:36:5f:c1:d4:20:b9:06:98:55:78:90:c7:
>                    86:85:a9:eb:80:29:0b:dc:5f:fa:f5:87:d7:39:d0:
>                    b0:84:0c:19:36:62:50:94:be:7f:8c:0f:3b:4f:66:
>                    a9:37:44:f4:a0:34:19:4e:a4:cf:7b:fe:50:13:e7:
>                    05:64:de:7b:69:a7:fa:42:ba:47:14:9c:57:6f:11:
>                    1c:4f:8b:60:4c:fc:c4:03:ef:8f:db:45:29:9e:1a:
>                    ca:1b:41:a8:ba:84:63:b9:a3:a9:c6:bc:8f:fb:03:
>                    59:74:8b:7e:05:e1:4f:89:76:92:24:81:6d:5d:30:
>                    18:b7:03:1e:f0:3e:75:8f:51:2a:d9:86:5d:48:ad:
>                    80:4a:46:f4:01:5a:37:48:0b:9b:32:1b:30:f6:5c:
>                    2a:f1:27:93:63:74:31:5d:4f:f5:4a:5e:11:e7:80:
>                    b5:b4:89:a7:1e:42:71:ee:e2:62:80:d6:e6:60:5b:
>                    50:c9:cd:bf:fb:8c:08:7b:52:9c:9a:96:6c:ec:cc:
>                    5c:8f:0e:77:e1:15:1a:65:5b:a7:fa:53:6b:34:ca:
>                    55:13
>                Exponent: 65537 (0x10001)
>        X509v3 extensions:
>            X509v3 Key Usage: critical
>                Digital Signature, Non Repudiation, Key Encipherment, Data
> Encipherment
>            X509v3 Subject Key Identifier:
>                09:12:C7:3A:1A:13:5D:26:47:92:84:5D:5B:7F:35:8B:63:FA:5D:B8
>            X509v3 CRL Distribution Points:
>                URI:http://crl.geotrust.com/crls/secureca.crl
>            X509v3 Subject Alternative Name:
>                DNS:autodiscover.tplg.co.uk, DNS:tlcexch01,
> DNS:tlcexch01.ross-comm.int, DNS:mail.tplg.co.uk
>            X509v3 Authority Key Identifier:
> keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
>            X509v3 Extended Key Usage:
>                TLS Web Server Authentication, TLS Web Client Authentication
>    Signature Algorithm: sha1WithRSAEncryption
>        81:5c:64:5f:64:6e:c1:9b:87:10:cc:66:05:98:2f:f1:e1:de:
>        90:ec:18:1a:4b:89:09:aa:08:ac:4f:85:2f:91:3b:6d:3e:7c:
>        03:e1:fc:83:1b:34:62:a9:46:70:45:d8:d5:66:5c:93:5b:79:
>        d2:ca:d5:fe:01:24:20:15:23:4c:4c:b1:fa:13:07:17:ce:0c:
>        3c:ce:b5:7a:cf:1c:29:4d:61:68:85:6f:a4:47:82:a0:c7:da:
>        04:d9:b9:7d:52:9a:72:2c:3a:e5:59:cd:7a:ca:11:3f:94:a3:
>        d4:ab:f9:bb:3a:ac:73:c8:9a:f0:23:25:d7:d2:1c:24:95:95:
>        e3:74
> -----BEGIN CERTIFICATE-----
> MIIDvTCCAyagAwIBAgIDC3/gMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
> MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
> aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNjE0MTYyNjAzWhcNMTAwNjE3MDA1MTUw
> WjBpMQswCQYDVQQGEwJHQjETMBEGA1UECBMKTGFuY2FzaGlyZTEQMA4GA1UEBxMH
> UHJlc3RvbjEZMBcGA1UEChMQVGhlIExpZmUgQ2hhbm5lbDEYMBYGA1UEAxMPbWFp
> bC50cGxnLmNvLnVrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmxVA
> h1eesjrV1FeIpui1n2qiW3loP+fqPEidjUUlrSiHz/Sm03WMAJAcDZ1U4c02X8HU
> ILkGmFV4kMeGhanrgCkL3F/69YfXOdCwhAwZNmJQlL5/jA87T2apN0T0oDQZTqTP
> e/5QE+cFZN57aaf6QrpHFJxXbxEcT4tgTPzEA++P20UpnhrKG0GouoRjuaOpxryP
> +wNZdIt+BeFPiXaSJIFtXTAYtwMe8D51j1Eq2YZdSK2ASkb0AVo3SAubMhsw9lwq
> 8SeTY3QxXU/1Sl4R54C1tImnHkJx7uJigNbmYFtQyc2/+4wIe1KcmpZs7Mxcjw53
> 4RUaZVun+lNrNMpVEwIDAQABo4IBCDCCAQQwDgYDVR0PAQH/BAQDAgTwMB0GA1Ud
> DgQWBBQJEsc6GhNdJkeShF1bfzWLY/pduDA6BgNVHR8EMzAxMC+gLaArhilodHRw
> Oi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBXBgNVHREEUDBO
> ghdhdXRvZGlzY292ZXIudHBsZy5jby51a4IJdGxjZXhjaDAxghd0bGNleGNoMDEu
> cm9zcy1jb21tLmludIIPbWFpbC50cGxnLmNvLnVrMB8GA1UdIwQYMBaAFEjmaPkr
> 0rKV10fYIyAQTzOYkJ/UMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAN
> BgkqhkiG9w0BAQUFAAOBgQCBXGRfZG7Bm4cQzGYFmC/x4d6Q7BgaS4kJqgisT4Uv
> kTttPnwD4fyDGzRiqUZwRdjVZlyTW3nSytX+ASQgFSNMTLH6EwcXzgw8zrV6zxwp
> TWFohW+kR4Kgx9oE2bl9UppyLDrlWc16yhE/lKPUq/m7OqxzyJrwIyXX0hwklZXj
> dA==
> -----END CERTIFICATE-----
> [Querying whois.iana.org]
> [whois.iana.org]
> Domain ross-comm.int not found.
> Verisign Certificate:
>    Data:
>        Version: 3 (0x2)
>        Serial Number:
>            4b:0a:a4:8c:90:ca:95:1e:dd:cd:73:01:ce:2a:2e:c0
>        Signature Algorithm: sha1WithRSAEncryption
>        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of
> use at https://www.verisign.com/rpa (c)05, CN=VeriSign Class 3 Secure Server CA
>        Validity
>            Not Before: Nov 11 00:00:00 2008 GMT
>            Not After : Nov 11 23:59:59 2009 GMT
>        Subject: C=DK, ST=Koebenhavn, L=K\xC3\xB8ebenhavn Oe., O=Dansk Roede
> Kors, OU=Dansk Roede Kors, CN=mail.drk.dk
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (2048 bit)
>                Modulus (2048 bit):
>                    00:9e:21:8e:d6:dc:cc:d4:4e:0e:ee:ae:c0:f5:7f:
>                    b0:59:1b:ac:87:d3:e9:61:41:f7:b0:1e:cb:4d:83:
>                    9f:4f:f1:af:e8:01:f0:5e:72:69:b5:97:69:46:ff:
>                    93:15:35:be:dd:f7:9e:f4:7c:a7:e0:d9:13:ca:b1:
>                    6e:a9:e2:a0:85:9c:e2:fe:48:06:ce:c4:32:ee:99:
>                    a2:b6:7d:49:70:55:e8:cd:a5:3c:f5:d7:06:93:d7:
>                    03:19:1a:69:71:ab:e8:d4:26:ed:9f:ef:5c:c6:3e:
>                    91:46:4f:32:dd:69:d9:a6:b7:5b:6d:e1:d7:fc:50:
>                    71:24:48:2f:6d:5f:45:d0:2b:f5:7f:e6:0e:e4:08:
>                    41:f5:e2:f2:4f:c5:e5:20:96:f1:66:45:a9:d7:21:
>                    63:0c:f4:36:f2:03:60:24:70:37:1b:fc:9d:78:da:
>                    9b:e2:7b:0b:07:d6:ae:4b:2b:a2:40:20:90:8e:c4:
>                    24:88:d8:48:46:63:c1:d1:8b:be:2f:4d:27:1c:4b:
>                    fd:d7:d9:f3:5b:40:76:11:27:4d:ea:c3:20:dd:cd:
>                    09:2c:2e:10:72:b1:ce:da:7d:da:6c:d4:11:83:5c:
>                    eb:1a:b2:e2:8c:99:f1:25:e6:72:38:da:1a:1d:ee:
>                    8b:b8:8f:21:f2:a6:ae:6d:42:6c:3c:27:2c:b7:5f:
>                    8e:a7
>                Exponent: 65537 (0x10001)
>        X509v3 extensions:
>            X509v3 Key Usage: critical
>                Digital Signature, Key Encipherment
>            X509v3 Subject Alternative Name:
>                DNS:mail.drk.dk, DNS:autodiscover.drk.dk, DNS:webmail.drk.dk,
> DNS:folke.drk.int
>            X509v3 Basic Constraints:
>                CA:FALSE
>            X509v3 CRL Distribution Points:
>                URI:http://SVRSecure-crl.verisign.com/SVRSecure2005.crl
>            X509v3 Certificate Policies:
>                Policy: 2.16.840.1.113733.1.7.23.3
>                  CPS: https://www.verisign.com/rpa
>            X509v3 Extended Key Usage:
>                TLS Web Server Authentication, TLS Web Client Authentication
>            X509v3 Authority Key Identifier:
> keyid:6F:EC:AF:A0:DD:8A:A4:EF:F5:2A:10:67:2D:3F:55:82:BC:D7:EF:25
>            Authority Information Access:
>                OCSP - URI:http://ocsp.verisign.com
>                CA Issuers -
> URI:http://SVRSecure-aia.verisign.com/SVRSecure2005-aia.cer
>            1.3.6.1.5.5.7.1.12:
> 0`.^.\0Z0X0V..image/gif0!0.0...+......Kk.(.....R8.).K..!..0&.$http://logo.verisign.com/vslogo1.gif
>    Signature Algorithm: sha1WithRSAEncryption
>        8e:15:ca:85:97:8b:3b:34:c5:9f:7e:17:54:2d:4c:8c:20:1e:
>        55:19:9d:30:58:26:e5:74:05:89:32:9a:0e:41:16:57:ae:70:
>        fa:2c:e8:1a:16:a0:57:47:a3:4d:97:07:78:ef:91:4b:7e:ed:
>        34:07:8b:d0:1d:96:ff:2f:5a:0c:b5:33:ba:9c:44:48:1b:3b:
>        d2:78:f8:a5:c4:b3:54:fe:db:80:e0:78:51:9f:92:a5:c3:3d:
>        c9:fb:80:6e:f2:99:ce:b8:46:ac:7d:0f:91:23:7e:f6:65:44:
>        24:00:2b:c5:6a:3a:32:b1:8c:db:e0:83:c3:a5:ee:cd:e4:5c:
>        69:7c:71:a8:c4:d1:00:7e:61:b4:5e:4b:98:d2:37:97:1e:99:
>        ba:6a:57:a3:d3:df:64:64:89:2c:64:58:7b:90:e7:ae:d7:0b:
>        dd:f6:d7:c9:f5:e7:6c:54:32:e7:13:09:87:95:7a:d9:36:60:
>        54:10:0d:15:c6:4b:b7:e9:62:eb:35:fb:6d:8b:dd:85:d4:39:
>        39:13:5d:fb:c9:c3:9a:6e:52:99:a9:f4:3f:75:0c:26:25:05:
>        aa:79:48:b9:78:66:b6:28:13:28:de:d4:bb:27:32:18:b0:03:
>        8b:c9:f3:3d:6b:8d:d7:a9:dd:5c:c0:6a:dd:0a:0c:a6:25:41:
>        2e:31:e9:09
> -----BEGIN CERTIFICATE-----
> MIIF6DCCBNCgAwIBAgIQSwqkjJDKlR7dzXMBziouwDANBgkqhkiG9w0BAQUFADCB
> sDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMh
> VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBMB4XDTA4MTExMTAwMDAw
> MFoXDTA5MTExMTIzNTk1OVowgYgxCzAJBgNVBAYTAkRLMRMwEQYDVQQIEwpLb2Vi
> ZW5oYXZuMRgwFgYDVQQHFA9Lw7hlYmVuaGF2biBPZS4xGTAXBgNVBAoUEERhbnNr
> IFJvZWRlIEtvcnMxGTAXBgNVBAsUEERhbnNrIFJvZWRlIEtvcnMxFDASBgNVBAMU
> C21haWwuZHJrLmRrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAniGO
> 1tzM1E4O7q7A9X+wWRush9PpYUH3sB7LTYOfT/Gv6AHwXnJptZdpRv+TFTW+3fee
> 9Hyn4NkTyrFuqeKghZzi/kgGzsQy7pmitn1JcFXozaU89dcGk9cDGRppcavo1Cbt
> n+9cxj6RRk8y3WnZprdbbeHX/FBxJEgvbV9F0Cv1f+YO5AhB9eLyT8XlIJbxZkWp
> 1yFjDPQ28gNgJHA3G/ydeNqb4nsLB9auSyuiQCCQjsQkiNhIRmPB0Yu+L00nHEv9
> 19nzW0B2ESdN6sMg3c0JLC4QcrHO2n3abNQRg1zrGrLijJnxJeZyONoaHe6LuI8h
> 8qaubUJsPCcst1+OpwIDAQABo4ICIjCCAh4wDgYDVR0PAQH/BAQDAgWgMEoGA1Ud
> EQRDMEGCC21haWwuZHJrLmRrghNhdXRvZGlzY292ZXIuZHJrLmRrgg53ZWJtYWls
> LmRyay5ka4INZm9sa2UuZHJrLmludDAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3
> oDWGM2h0dHA6Ly9TVlJTZWN1cmUtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1cmUy
> MDA1LmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEW
> HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYBBQUH
> AwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFG/sr6DdiqTv9SoQZy0/VYK81+8lMHkG
> CCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24u
> Y29tMEMGCCsGAQUFBzAChjdodHRwOi8vU1ZSU2VjdXJlLWFpYS52ZXJpc2lnbi5j
> b20vU1ZSU2VjdXJlMjAwNS1haWEuY2VyMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBY
> MFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY
> MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjANBgkqhkiG
> 9w0BAQUFAAOCAQEAjhXKhZeLOzTFn34XVC1MjCAeVRmdMFgm5XQFiTKaDkEWV65w
> +izoGhagV0ejTZcHeO+RS37tNAeL0B2W/y9aDLUzupxESBs70nj4pcSzVP7bgOB4
> UZ+SpcM9yfuAbvKZzrhGrH0PkSN+9mVEJAArxWo6MrGM2+CDw6XuzeRcaXxxqMTR
> AH5htF5LmNI3lx6ZumpXo9PfZGSJLGRYe5DnrtcL3fbXyfXnbFQy5xMJh5V62TZg
> VBANFcZLt+li6zX7bYvdhdQ5ORNd+8nDmm5Sman0P3UMJiUFqnlIuXhmtigTKN7U
> uycyGLADi8nzPWuN16ndXMBq3QoMpiVBLjHpCQ==
> -----END CERTIFICATE-----
> [Querying whois.iana.org]
> [whois.iana.org]
> Domain drk.int not found.

We at VeriSign worked with the affected customers to revoke the two certificates listed on this thread and are doing an internal audit to see if there are any other certificates we need to revoke. Appropriate steps are being taken to ensure this will not occur in the future.
(In reply to comment #42)
> We at VeriSign worked with the affected customers to revoke the two
> certificates listed on this thread and are doing an internal audit to see if
> there are any other certificates we need to revoke. Appropriate steps are being
> taken to ensure this will not occur in the future.

Out of curiousity, would you be prepared to deal with enforcement of Mozilla's existing policy?  (Certificates for non-existing/internal domains are arguably not allowed under it.)
The proper place for this discussion should be at the dev.security.policy mailing list of Mozilla. Just a short statement here:

Recently Verisign requested to have a few new roots included with NSS. During the discussion for inclusion, this particular issue has been raised by me and Verisign recognized the problem. Jay himself took this issue to the CAB Forum in order to incorporate this language into the proposed Basic SSL guidelines. Without speaking for Verisign, it's my understanding that if this requirement is applied evenly onto all participating CAs, Verisign would also commit to it. A similar statement was made by other CAs as well (including Comodo IIRC).

The solution is in my opinion to deal with this in cooperation with the CAB Forum, affected CAs and Mozilla in order to allow for an organized change of policies. This effort should be accelerated now.
Eddy, that's great to hear!

I would prefer to have such important discussions in the open, though, not in a closed group. I would personally probably qualify to join the group, but it's something fundamental to security architecture and should be discussed in the open, with participation by anybody qualified and willing, and with archive.
Partly agreed. Lets accept that different groups may consult before going public. I prefer public discussions as well and Mozilla's mailing list is public thankfully. I believe eventually decisions will be made in cooperation with the parties involved.
In November there was a discussion in mozilla.dev.security.policy called "Communication to CAs about .int TLD". On 11/23/2009 I sent the communication to all of the CAs with root certificates included in NSS. I received response back from many of the CAs who performed the requested testing and incorporated the recommended process changes. The communication was also forwarded to CABFReq (requirements@cabforum.org) and further discussed.

Does any further action need to be taken for this bug?
Were any of the responses from Comodo?  If so, did any specificly address this issue?
> Were any of the responses from Comodo?  
> If so, did any specificly address this issue?

Yes. I have received email from Comodo in reply to the communication. The email response said that Comodo performed the recommended internal audit, and is working with affected customers to revoke and replace the relevant certs. The Comodo representative also said that they have reviewed and updated their controls, procedures, and training as per the recommendations in the communication.
(In reply to comment #49)
> > Were any of the responses from Comodo?  
> > If so, did any specificly address this issue?
> 
> Yes. I have received email from Comodo in reply to the communication. The email
> response said that Comodo performed the recommended internal audit, and is
> working with affected customers to revoke and replace the relevant certs. The
> Comodo representative also said that they have reviewed and updated their
> controls, procedures, and training as per the recommendations in the
> communication.

Until we get more information on Comodo's system's ability to allow for "human error", I believe that enough time has passed and more than enough incidents have occurred to suspend their roots from NSS until a full, thorough audit is performed and attested.
This particular bug was in regards to CAs making mistakes when issuing SSL certificates to .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may have been aware that .int is an ICANN approved TLD. 

It turned out that several CAs had made similar mistakes. This resulted in a communication to all of the CAs with root certificates included in NSS. There was a significant amount of follow-up email with CAs who performed the requested actions. In addition, the following section was added to Mozilla's wiki pages:  https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains


Comodo, and several other CAs, did follow-up with me to confirm that the actions had been completed in a timely manner. 

My opinion is that the issues raised in this bug have been properly addressed, and that this bug may be closed as Resolved/Fixed.
Status: NEW → ASSIGNED
Agreed. However I suggest to follow up on the practice of issuing certificates for non-registered host names, e.g. so-called internal hostnames, Class C/B IP addresses and fake TLDs. The Mozilla CA policy calls for "registered the domain(s) referenced in the certificate" and this is not enforced today.

Issuing to non-registered hostnames by public CAs does not provide any security if the same hostname may be issued by the same or another CA. MITM attacks are possible for such hostnames.
Eddy raises a good point - this is a more general problem. There is no need for public CAs to issue certificates to [unverifiable] private addresses/hostnames as [verifiable] public hostnames and/or split horizon DNS can be used.

CAs who nonetheless wish to deliver this [mis]service can do so with untrusted roots, which has the useful side effect of limiting the utility of a dangerous practice.
I'm not really satisfied with the new recommendations in problematic practices, as well as with the idea of tackling this through problematic practices and not actual policy.

RFC 2606 defines exactly 4 values that can be used as top level TLD with the guarantee they will never become a valid public TLD in the future.

*Any* other value is *not* reserved and can become a valid TLD at any point in time. Any configuration that uses a value outside of those 4 (.test, .example, .invalid, .localhost) for private usage is *breaking* DNS conformance.

So, outside of the question of whether public CA should be allowed to deliver certificates for private hostnames, a CA should never issue a certificate for a hostname that breaks this rule and is therefore *not* a valid private hostname.
Yes, there are still concerns about issuing certificates for internal domain names such as non-valid TLDs, hostnames, and IP addresses. This applies to many CAs, and not just Comodo. To resolve these general concerns, there may be need to update the Mozilla CA Certificate Policy and related wiki pages, and to send a communication to all CAs with root certificates included in NSS.

I propose to create a new bug to track the general issue, and to close this bug which was specifically in regards to Comodo's issuance of certificates for .int domains.
Filed bug 567193 and this bug should be closed.
Thanks!
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.