On Wed, 09 Nov 2011 12:28:57 +0100, Matthias Hunstock <[email protected]> wrote: > It's very simple. The domain whitelist was introduced some time ago > (about 1.5 years ago I think), the "bad" certs you have in your data > should be older than that.
I just looked into this deeper.
I should note that the dataset i'm using was gathered by the EFF nearly
1 year ago (2010-12 if you believe the date on the tin).
The most recent .local certificate issued by a subsidiary of DFN was on
2010-04-08, so it looks like you're right that something changed in
their policy round 2010-04.
However, all but one of these were 5-year certs. And all of them appear
to be still valid. So their change in policy doesn't protect relying
parties against certs that they have already issued. And the certs
gathered by the observatory are clearly not an exhaustive list.
Here's the .local domains issued by a subordinate of DFN along with
their start and end dates:
------------
mysql> SELECT name, children.startdate, children.enddate, children.certid FROM
names JOIN valid_certs AS children ON names.certid=children.certid JOIN
valid_certs AS parents ON children.`X509v3 extensions:X509v3 Authority Key
Identifier:keyid`=parents.`X509v3 extensions:X509v3 Subject Key Identifier`
WHERE LOCATE("dfn-verein",parents.issuer) AND name LIKE '%.local' ORDER BY
startdate;
+-----------------------------------+---------------------+---------------------+---------+
| name | startdate | enddate
| certid |
+-----------------------------------+---------------------+---------------------+---------+
| app1.cip.physik.local | 2009-01-20 13:09:09 | 2014-01-19 13:09:09
| 292782 |
| mercury.mpifg.local | 2009-04-28 14:41:08 | 2014-04-27 14:41:08
| 657314 |
| exchange.hds.local | 2009-06-16 09:26:07 | 2014-06-15 09:26:07
| 813391 |
| sharepoint.mpifg.local | 2009-06-17 12:22:08 | 2014-06-16 12:22:08
| 659281 |
| webconf02.rki.local | 2009-09-17 11:28:07 | 2014-09-16 11:28:07
| 710468 |
| webconf01.rki.local | 2009-09-18 07:34:13 | 2014-09-17 07:34:13
| 707557 |
| leibniz.local | 2009-11-24 16:37:09 | 2014-11-23 16:37:09
| 3653370 |
| de-be-lbz-exca1.leibniz.local | 2009-11-24 16:37:09 | 2014-11-23 16:37:09
| 3653370 |
| de-be-lbz-dcex1.leibniz.local | 2009-11-24 16:37:09 | 2014-11-23 16:37:09
| 3653370 |
| autodiscover.leibniz.local | 2009-11-24 16:37:09 | 2014-11-23 16:37:09
| 3653370 |
| webmail.rki.local | 2010-01-06 13:40:09 | 2015-01-05 13:40:09
| 671657 |
| mx1.zbi.local | 2010-02-02 14:16:09 | 2013-02-01 14:16:09
| 299472 |
| wettbewerb.leibniz.local | 2010-02-17 13:47:07 | 2015-02-16 13:47:07
| 3500635 |
| wettbewerb-training.leibniz.local | 2010-02-17 13:47:07 | 2015-02-16 13:47:07
| 3500635 |
| wettbewerb-test.leibniz.local | 2010-02-17 13:47:07 | 2015-02-16 13:47:07
| 3500635 |
| ars.rki.local | 2010-03-11 13:56:09 | 2015-03-10 13:56:09
| 688346 |
| hfk-cas2.hfk-bremen.local | 2010-03-23 15:49:07 | 2015-03-22 15:49:07
| 680864 |
| hfk-cas1.hfk-bremen.local | 2010-03-23 15:49:07 | 2015-03-22 15:49:07
| 680864 |
| nffex01.nff.local | 2010-04-06 12:54:07 | 2015-04-05 12:54:07
| 302968 |
| firewall.erpbilab.local | 2010-04-08 10:47:08 | 2015-04-07 10:47:08
| 340764 |
+-----------------------------------+---------------------+---------------------+---------+
20 rows in set (1 min 23.76 sec)
mysql>
------------
rather than pick on DFN itself, i note that the EFF found over 11K
certificates still valid today that have some .local name in them,
coming from 52 CAs:
------------
mysql> SELECT COUNT(distinct certid) FROM names JOIN valid_certs USING
(certid) WHERE name LIKE '%.local' AND enddate > now();
+------------------------+
| COUNT(distinct certid) |
+------------------------+
| 11499 |
+------------------------+
1 row in set (4.24 sec)
mysql> SELECT COUNT(distinct issuer) FROM names JOIN valid_certs USING
(certid) WHERE name LIKE '%.local' AND enddate > now() ORDER BY startdate;
+------------------------+
| COUNT(distinct issuer) |
+------------------------+
| 52 |
+------------------------+
1 row in set (4.23 sec)
mysql>
------------
here are the guilty parties, ordered by the most recent startdate of an
issued .local certificate:
SELECT max(startdate) AS mostrecent, issuer FROM
names JOIN valid_certs USING (certid)
WHERE name LIKE '%.local' AND enddate > now()
GROUP BY issuer
ORDER BY mostrecent;
2008-12-12 00:00:00 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert
Global CA
2009-01-20 13:09:09 C=DE, ST=Niedersachsen, L=Goettingen,
O=Georg-August-Universitaet Goettingen, CN=Universitaet-Goettingen
CA/[email protected]
2009-02-26 00:00:00 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert
Global CA (2048)
2009-03-31 00:24:00 DC=local, DC=experian, CN=Configuration, CN=Services,
CN=Public Key Services, CN=AIA, CN=Experian PrdSubCA1
2009-04-02 19:13:03 C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by
ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure
Server Certification Authority
2009-06-16 09:26:07 C=DE, ST=Hessen, L=Wiesbaden, O=Fachhochschule
Wiesbaden, OU=IT-Center, CN=FHW-CA/[email protected]
2009-06-17 12:22:08 C=DE, O=Max-Planck-Institut fuer
Gesellschaftsforschung, OU=MPIfG, CN=MPIfG-CA/[email protected]
2009-12-07 00:00:00 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=AAA Certificate Services
2009-12-07 22:38:26 C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS
GOVERNING USE AND RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES
AND LIABILITY, OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2008
Entrust, Inc., CN=Entrust Certification Authority - L1B
2010-01-26 00:00:00 C=US, O=Trusted Secure Certificate Authority,
CN=Trusted Secure Certificate Authority
2010-02-02 14:16:09 C=DE, ST=Saarland, L=Saarbruecken, O=Universitaet des
Saarlandes, CN=CA Universitaet des
Saarlandes/[email protected]
2010-02-05 00:00:00 C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
2010-02-12 00:00:00 C=AT, L=Wien, O=e-commerce monitoring GmbH, CN=A-CERT
SERVERCERT Class 3/[email protected]
2010-02-17 13:47:07 C=DE, O=DFN-Verein, OU=DFN-PKI, CN=DFN-Verein CA
Services
2010-02-19 11:33:15 C=FI, O=Sonera, CN=Sonera Class2 CA
2010-03-11 13:56:09 C=DE, O=Robert Koch-Institut, OU=RKI-PCA, CN=RKI
Certification Authority/[email protected]
2010-03-23 15:49:07 C=DE, ST=Bremen, L=Bremen, O=Hochschule fuer Kuenste
Bremen, CN=HFK-BREMEN-CA/[email protected]
2010-04-06 12:54:07 C=DE, ST=Niedersachsen, L=Braunschweig, O=Technische
Universitaet Braunschweig, CN=Technische Universitaet Braunschweig
CA/[email protected]
2010-04-08 10:47:08 C=DE, L=Stuttgart, O=Universitaet Stuttgart,
CN=Universitaet Stuttgart CA - G01/[email protected]
2010-04-14 13:44:39 C=ES, ST=MADRID, L=MADRID, O=ips Certification
Authority, OU=Certificaciones, CN=ipsCA Level 1
CA/[email protected]
2010-04-16 00:44:16 DC=edu, DC=gemini, C=US, OU=Information Systems Group,
O=AURA - Gemini Observatory, CN=GEMINI-CA
2010-04-22 00:00:00 C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA
Limited, CN=COMODO High Assurance Secure Server CA
2010-06-04 00:00:00 C=ZA, ST=Western Cape, L=Cape Town, O=Thawte
Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server
CA/[email protected]
2010-08-03 15:27:58 C=CH, O=SwissSign AG, CN=SwissSign Server Gold CA 2008
- G2
2010-08-26 00:00:00 C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA
Limited, CN=COMODO High-Assurance Secure Server CA
2010-09-13 08:43:53 C=GB, O=Coventry City Council, OU=CCC Standard Issuing
Authority
2010-09-14 12:10:17 C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr.
Datenverkehr GmbH, OU=a-sign-SSL-03, CN=a-sign-SSL-03
2010-09-17 00:00:00 O=VeriSign Trust Network, OU=VeriSign, Inc.,
OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS
Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
2010-09-28 00:00:00 C=US, O=Thawte, Inc., OU=Domain Validated SSL,
CN=Thawte DV SSL CA
2010-09-30 00:00:00 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
2010-10-04 00:00:00 C=NL, O=TERENA, CN=TERENA SSL CA
2010-10-08 00:00:00 C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)09, CN=VeriSign Class 3
Secure Server CA - G2
2010-11-10 10:26:29 C=IT, O=I.T. Telecom, OU=Servizi di certificazione,
CN=I.T. Telecom Global CA
2010-11-19 15:33:46 C=DE, O=TC TrustCenter GmbH, OU=TC TrustCenter Class 2
L1 CA, CN=TC TrustCenter Class 2 L1 CA XI
2010-12-01 00:00:00 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=PositiveSSL CA
2010-12-05 18:11:52 C=US, O=Equifax, OU=Equifax Secure Certificate
Authority
2010-12-13 00:00:00 C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3
Secure Server CA - T1
2010-12-13 07:38:20 C=US, O=GeoTrust Inc., OU=Domain Validated SSL,
CN=GeoTrust DV SSL CA
2010-12-14 00:00:00 C=US, ST=UT, L=Salt Lake City, O=The USERTRUST
Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
2010-12-14 00:00:00 C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3
Secure Server CA - G3
2010-12-15 23:55:25 C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA
2010-12-16 21:39:09 C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is
incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification
Authority - L1C
2010-12-17 00:00:00 C=US, O=Register.com, CN=Register.com CA SSL Services
(OV)
2010-12-17 00:00:00 C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3
International Server CA - G3
2010-12-17 00:00:00 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert
High Assurance CA-3
2010-12-17 00:00:00 C=US, O=Thawte, Inc., CN=Thawte SSL CA
2010-12-17 00:00:00 C=US, ST=UT, L=Salt Lake City, O=The USERTRUST
Network, CN=USERTrust Legacy Secure Server CA
2010-12-17 14:39:10 C=BM, O=QuoVadis Limited, OU=www.quovadisglobal.com,
CN=QuoVadis Global SSL ICA
2010-12-17 15:53:59 C=US, ST=Arizona, L=Scottsdale, O=Starfield
Technologies, Inc., OU=http://certificates.starfieldtech.com/repository,
CN=Starfield Secure Certification Authority/serialNumber=10688435
2010-12-17 16:05:08 OU=Organization Validation CA, O=GlobalSign,
CN=GlobalSign Organization Validation CA
2010-12-17 20:05:39 C=BE, OU=Domain Validation CA, O=GlobalSign nv-sa,
CN=GlobalSign Domain Validation CA
2010-12-18 20:12:12 C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc.,
OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification
Authority/serialNumber=07969287
I note that of the CAs who issued .local certs in the last month before
the dataset was gathered, we have:
* thawte
* verisign
* comodo
* godaddy
* register.com
* starfield
* geotrust
* globalsign
* usertrust
* digicert
It's a who's who of major CAs directly issuing these things, not
subordinate CAs.
Am i wrong in thinking that this makes the "please recount the number of
CAs" concern seem like a distraction from deeper issues?
Is there some reason that a legit CA should be certifying names in the
.local zone at all?
--dkg
pgpaovKA73pEZ.pgp
Description: PGP signature
