Sustaining Digital Certificate Security

Posted by Ryan Sleevi, Software Engineer

This post updates our previous notification of a misissued certificate for google.com.

Following our notification, Symantec published a report in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.

However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.

Symantec performed another audit and, on October 12th, announced that they had found an additional 164 certificates over 76 domains and 2,458 certificates issued for domains that were never registered.

It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.

After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.

More immediately, we are requesting of Symantec that they further update their public incident report with:

1. A post-mortem analysis that details why they did not detect the additional certificates that we found.
2. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.

We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.

Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:

• WebTrust Principles and Criteria for Certification Authorities
• WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
• WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL

The third-party security audit must assess: 

• The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
• That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
• That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.

We may take further action as additional information becomes available to us.