Back in March of this year, Google took the unprecedented move to distrust certificates from a major certificate authority: namely Symantec. This was a wakeup call for organizations everywhere when they quickly realized that they would soon have to find and replace any certificates issued by a certificate provider that uses the Symantec CA in order to avoid business disruption. However, the distrust of Symantec certificates was also a reminder that anything can happen to change the trust of certificates and many organizations began to wonder if they were prepared to move quickly, when they needed to.
Google’s move to distrust Symantec certificates was driven by a series of significant security errors that Google felt compromised the trust of all Symantec certificates. Over the months, we have seen a back-and-forth series of negotiations to determine the extent of that distrust as well as the ultimate timeframe. As we outlined in an earlier blog, the goal was to balance between ensuring security and avoiding industry disruption.
Finally, on September 11, Google announced a formal timeline for the distrust of Symantec certificates. Chrome 66 will begin distrusting Symantec certificates when its Beta is released on March 15, and fully distrust when Chrome is released to stable on April 17, 2018. As Symantec certificates represent over 20% of the market, this may leave many companies scrambling to find and replace all certificates issued by a provider that uses the Symantec CA before the deadline of distrust.
But a certificate authority error is not the only reason that your organization should be prepared to swap out certificates quickly. Ever since the now-infamous DigiNotar compromise of 2011, we have been on high alert for certificate authority compromises that would result in the immediate distrust of a large pool of certificates. In the event of such an event, organizations would need to swap out potentially compromised certificates at the drop of a dime.
Distributed Denial of Service (DDoS) Attacks
Just as outages can inadvertently cause business disruption in your organization, the same can happen at your certificate authority and the services they provide as well. And during that downtime, you may not be able to effectively issue, manage, and revoke your certificates. That gap in coverage could also result in gaps within certificate transparency logs, which would flag your certificates as questionable. Even worse, a cyber criminal could intentionally trigger that outage with a distributed denial of service (DDoS) attack at your internal certificate authority to take advantage of the downtime to manipulate certificates and logs without validation. To minimize damage in the aftermath of a certificate authority outage, you’ll need to quickly find and replace any certificates issued within that timeframe.
Compromised Certificate Revocation List
Certificate revocation lists (CRL) help protect your organization from trusting certificates that have been revoked due to error or compromise. But if that list is even temporarily unavailable to you, you could end up trusting a malicious certificate. This could happen through an outage at your certificate authority, a certificate authority compromise where the list is changed to facilitate malicious activity, or within your own PKI. If a cyber criminal infiltrates your organization and removes a revoked certificate from your local CRL, they can then use that certificate to perform all kinds of malicious functions—totally trusted. And this all happens behind the scenes, so it’s invisible to most. And that makes it even more difficult for you to find and replace any compromised certificates.
Compromised administrator passwords
When your PKI administrators or others within your organization request certificates, they must authenticate themselves with the certificate authority. Generally, that is done with a password. But if cyber criminals can access those credentials, you’re in trouble. They can behave as if they belong to your organization and request certificates on your behalf, that they can then use against you. Once you discover these anomalous certificates on your systems, you’ll need to quickly identify where they have been used and replace them pronto.
Google’s distrust of Symantec certificates is a rather unfriendly reminder of how much agility we need to architect into our PKIs. Security architects and network architects always design edge to core with redundancy as top of mind; but they rarely ever apply it to certificate authorities. Speed and agility in managing machines identities – being able to issue, replace, and recover from a security incident involving keys and certificates, including CA compromise, is required now more than ever. This is an alarm that can no longer be ignored.
Are you prepared to quickly find and replace certificates impacted for any reason?