On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote: > On 10/13/15 18:46, Kathleen Wilson wrote: > > In September of this year, the CA Symantec revealed[0] that they had > > mis-issued > > a number of certificates for domains that they did not own or control, for > > testing purposes. After an "exhaustive review", they issued a Final > > Report[1] > > which documented 23 such certificates. > > > > Yesterday, Symantec updated their final report[2] to indicate that the > > problem > > was more extensive than they had at first believed. They said, in part: > > > > "While our current investigation is ongoing, so far we have found 164 > > additional > > instances where test certificates were inappropriately issued. All of these > > test > > certificates have been revoked. These test certificates were spread over 76 > > domain owners whom we are in the process of contacting." > > > > In addition, they have identified 3073 test certificates which were issued > > for > > domains which were (at the time) unregistered, since the practice was banned > > (which happened at different times for EV certs and other certs). They have > > provided two lists[3][4], one of the 164 certs and another of the 3073. > > This list of test certs for owned domains contains an entry for > a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013 > 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF). > This appears to be this certificate https://crt.sh/?id=1990400 which has: > > X509v3 Subject Alternative Name: > DNS:*.icns.com.au > DNS:icns.com.au > > As of this writing, there appears to be a functional server at that > www.icns.com.au which presents that (expired and revoked) cert and to which > openssl s_client can successfully connect. > > Is this entry an error? > > In Symantec's initial incident report, they indicated 'the private keys > associated with the test certificates were all destroyed as part of the > testing > tool that was used to enroll for the test certificates'. Are they still making > this claim for the test certificates found subsequently? > > - Charles > > > > > > They are continuing to search, and will update the Final Report again when > > their > > investigations are complete. > > > > The 164 certificates will be added to Mozilla's OneCRL system[5]. (We do not > > think the risk from the 3073 is significant enough to warrant this step.) > > > > This message has been posted to begin a discussion in the Mozilla community > > as > > to what additional action, if any, Mozilla should take in response to these > > events. > > > > Kathleen, Gerv and Richard > > > > [0]http://www.symantec.com/connect/blogs/tough-day-leaders > > [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf > > > > [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf > > > > [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf > > > > [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf > > > > [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321
Thanks for your post. Symantec does not own the icns.com.au domain, but we had authorization by the domain owner to use the domain for testing. This icns.com.au test certificate was properly authenticated, and was installed and used externally by the domain owner. We included this certificate on our list of certificates associated with domains that we do not own, which is accurate. However, because we had authorization from the domain owner to issue the certificate, this certificate did not need to be on this list but was included for completeness. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
