In an increasingly digital world, SSL/TLS certificates become the identity of a particular enterprise. Who trusts this digital identity? Almost every entity that is connected to the internet, including browsers and their underlying operating systems. Basically, SSL/TLS certificates are like our passports; they are widely accepted as proof of identity.
Now, what if someone forges your passport or worse, what if the issuing authority mistakenly issues a passport in your name to someone else? This is where regulations and standards play an important role. According to Google Chrome’s Root Certificate Program, a certificate authority can only be trusted when it can properly verify the identity of the requestor, maintain unalterable logs of all its X.509 certificates, audit these logs for suspicious activity, fortify its PKI infrastructure and quickly identify and react to a compromise/mis-issuance. When these principles are not followed stringently, the certificate authority loses its place in the trust store. But, how can one actually identify the bad actors? Using Google’s Certificate Transparency Program.
The Certificate Transparency Program maintains a log of all SSL/TLS certificates ever issued and opens it to public scrutiny by domain owners, certificate authorities and domain users. Domain Owners can make use of this program to identify mis-issued certificates for its domain. As per information shared in a Google Group, the Chrome team was able to identify mis-issuance of over 30,000 certificates by Symantec through the transparency log, for which the certificate authority responsible may lose its place in the trusted Certificate Authority Program.
How did the issue unfold?
The issue first started in 2015 when Google, through its Certificate Transparency Program, identified Symantec issuing test extended validity certificates for domains it did not own (especially Google domains). Following this discovery, Google ordered an independent audit of Symantec’s infrastructure and required the company to comply with Certificate Transparency for all its certificates, not just the extended validation ones.
In 2017, as more and more certificates were included in the transparency program, Google identified as many as 30,000 faulty certificates issued or validated by Symantec over the past several years. This was followed by a move to gradually distrust all Symantec certificates by reducing their validity to nine months and requiring the certificate authority to revalidate and replace all its certificates.
After Google’s aggressive actions against Symantec, Mozilla followed suit. The company identified a list of 17 issues on its blog, including the issuance of SHA1 certificates post deprecation, and sought an immediate explanation from Symantec. In response, Symantec notified the termination of its Registration Authority program primarily responsible for these issues.
By the end of April 2017, Google, backed by Mozilla, proposed an alternative approach to the troubles at-hand. According to the proposed approach, Symantec needed to outsource its operations to one or more independent CAs to remain trusted in its trust stores. Symantec instantly rejected this proposal and promised remediation through increased audits and process improvements, citing possible ramifications for its existing customers. As the discussions between Symantec and other browsers progressed through 2017, the browser community solidified their decision to distrust Symantec’s website security and PKI-related solutions. Due to this decision, Symantec chose to sell off its web certificate business to DigiCert for $950 million in August of 2017.
A timeline of the Symantec-DigiCert transition
DigiCert completed the acquisition of Symantec’s Web Security and PKI-related solutions by the end of October 2017 and will start issuing Symantec certificates from December 2017. Meanwhile, any domain owner looking to renew Symantec certificates could procure a new certificate from the Symantec PKI, but with reduced validity (9 months) to support deprecation. When new Symantec certificates are issued by the new DigiCert infrastructure, they will be fully supported by future versions of Chrome (version 62 onward) and Firefox. However, Symantec certificates issued by the old Symantec infrastructure will be completely distrusted by Chrome starting in October 2018.
Let’s take a look at the timeline published by the Google Chrome team:
- From Chrome 62 onward (October 2017), domain owners can identify the list of SSL/TLS certificates that will be distrusted in the form of a warning under the “Developer Tools” console when they load a website. The warnings will include all Symantec certificates issued before June 2016.
- Chrome 66 (April 2018) will go a step further and start displaying warnings on the browser page itself thereby revoking trust of all Symantec certificates issued before June 2016.
- Finally, Chrome 70 (October 2018) will extend the distrust to all Symantec certificates issued with the old Symantec PKI. This will not affect any Symantec certificates chained to the new managed partner infrastructure (DigiCert).
What next? By October 2018, you must replace all Symantec certificates chained to old root certificates. There are two ways you can approach this migration. The first is to wait until December to have new Symantec certificates signed by the new root certificate authority. Or, you may choose to approach a different certificate authority for the migration. Though either method is acceptable, you must evaluate your specific business needs before choosing one. No matter what approach you take, how do you plan on completing this massive project or any such projects in future with minimum business impact? Is it time we relooked at traditional SSL certificate management and started investing in PKI automation tools?