Public Key Infrastructure (PKI) supports a number of security-related services, including data confidentiality, data integrity and end-entity authentication. Fundamentally, these machine identities are based on the proper use of public/private key pairs. The public component of this key pair is issued in the form of a public key certificate and, in association with the appropriate algorithm(s), it may be used to verify a digital signature, encrypt data, or both.
A public key certificate is a signed statement that is used to establish an association between an identity and a public key. In order to associate the identity and the public key, a chain of trust is used. A chain of trust is a list of certificates, usually starting with an end-entity certificate, followed by one or more intermediate certificates, with the last certificate in the list, called root certificate, to serve as a trust anchor: a certificate that you trust because it was delivered to you by some trustworthy procedure. The root certificate, also called a trusted root, is at the center of the trust model that secures PKI.
Root certificates are being issued by Certification Authorities (CA), which are companies or government agencies that have been authorized by browsers to issue TLS/SSL and code signing certificates. In order to enforce the trustworthiness of CAs and their root certificates, these organizations undergo annual audits by third parties in order to insure they are following rules regarding the proper vetting, issuance and revocation of certificates in accordance with the in-place guidelines issued by the CA/Browser Forum (CA/B Forum for short).
The CA/B Forum Baseline Requirements
The CA/B Forum was established to standardize the requirements for issuing publicly-trusted certificates. Members include browser “manufacturers” and public CAs. “Publicly-trusted” means that certificates issued by a CA are trusted by browsers and other systems that use certificates.
The widespread use of the Internet for online transactions, the need to secure them, the proliferation of CAs, and the varying criteria used by browsers to determine whether to embed CAs as trust anchors in software has driven the critical need for a standard baseline on TLS/SSL business operations and authentication processes to ensure the continued success and viability of the trust model. The Baseline Requirements were designed to strengthen the security around authentication processes and TLS/SSL issuance operations. The requirements include identity vetting, certificate content and profiles, CA security, certificate revocation mechanisms, use of algorithms and key sizes, audit requirements, liability, privacy and confidentiality, and delegation of authority.
The Baseline Requirements require that all CAs and their representative are audited for compliance with the requirements each year and that they publicly publish the results of their audits.
Despite all the compliance and auditing mechanisms put in place by the CA/B Forum, there are cases when things go wrong. Current cryptographic mechanisms cannot detect malicious websites if they’re provisioned with mistakenly issued certificates or certificates that have been issued by a CA that has been compromised or gone rogue. In these cases, browsers see nothing wrong with the certificates because the CA appears to be in good position, giving users the impression that the website they are visiting is authentic and their connection is secure.
One of the problems is that there is currently no easy or effective way to audit or monitor TLS/SSL certificates in real time, so when these missteps happen (malicious or otherwise), the suspect certificates aren’t usually detected and revoked for weeks or even months. What’s more, these types of TLS/SSL missteps are occurring with increasing frequency. Over the past few years there have been numerous instances of mis-issued certificates being used to spoof legitimate sites, and, in some case, install malicious software or spy on unsuspecting users.
Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of TLS/SSL certificates open to scrutiny by domain owners, CAs, and domain users. In order to achieve this, an open framework for monitoring the TLS/SSL certificate system and auditing specific TLS/SSL certificates has been created. This open framework consists of public certificate logs, public log monitoring and public certificate auditing.
What Can Go Wrong?
The above frameworks makes it very difficult to eliminate root certificate trust. But there are cases when things go wrong.
DigiNotar, a prominent Dutch CA was compromised and the hackers were able to use the CA’s system to issue fake TLS/SSL certificates. The certificates were used to impersonate numerous sites in Iran, such as Gmail and Facebook, which enabled the operators of the fake sites to spy on unsuspecting site users.
In 2011 one of Comodo’s registration authorities was compromised. While initially a single Iranian claimed credit for hacking into the digital certificate provider, resulting in obtaining fraudulent certificates for websites operated by Google, Yahoo, Microsoft, Skype and Mozilla, other experts have suggested that it may have been orchestrated by Iran's government to track and shut down dissidents.
In another case, the Malaysian subordinate certificate authority DigiCert Sdn. Bhd., mistakenly issued 22 weak TLS/SSL certificates, which could be used to impersonate websites and sign malicious software. As a result, major browsers had to revoke their trust in all certificates issued by DigiCert Sdn. Bhd.
In 2012, TrustWave, a large U.S.-based CA, admitted that it issued subordinate root certificates to one of its customers so the customer could monitor traffic on their internal network. Subordinate root certificates can be used to create TLS/SSL certificates for nearly any domain on the Internet. Although Trustwave has revoked the certificate and stated that it will no longer issue subordinate root certificates to customers, it illustrates just how easy it is for CAs to make missteps and just how severe the consequences of those missteps might be.
Lack of Baseline Requirements’ Compliance
The case that went “viral” with mistaken certificate issuance procedures was the Symantec one. Back in 2015 Symantec ran afoul of Google for the first time after issuing some bad test certificates. Google found that Symantec had been issuing unauthorized TLS/SSL certificates domains owned by Google, Opera and three other organizations. The scandal caused Symantec to fire a number of employees and Google required Symantec to begin adding all the certificates it issued to Certificate Transparency logs. At that point in time only EV certificates were required to be logged.
A year later, Symantec got in trouble for mis-issuing a new batch of test certificates. While Symantec claimed it was just 33 certificates Google estimated it was more like 30,000. When Google investigated further it unearthed lax oversight over validation in some regions, too. From the browsers’ perspective (not just Google, but Mozilla, Apple and Microsoft, too) these mistakes undermined faith in Symantec’s CA. How could any Symantec TLS/SSL certificate be trusted knowing that there was such lax oversight over the validation required for issuance? Symantec had to be distrusted and removed from the browsers’ trust stores.
Less known is the case with the Venezuelan CA PROCERT, when “PROCERT have not been, and continue not to be, adequately aware of the requirements placed upon them by various RFCs, the CA/Browser Forum’s Baseline Requirements, and Mozilla Root Store Policy. They have not demonstrated sufficient control of their issuance pipeline or sufficient checking of the results to avoid regularly creating certificates which violate the requirements of one or more of those documents,” reads Mozilla’s decision to distrust this CA.
Finally, in 2019, Mozilla distrusted the French CA Certinomis due to repeated violations of certificate validation rules.
Impact of a Root Trust Gone Wrong
Although the impact of the last two incidents was within the borders of respective countries and affected mostly government sites, that was not the case with Symantec. Even in May 2018, almost a month after phase 1 of the Symantec distrust plan, over a million websites were still using distrusted Symantec certificates. Can you imagine one million websites going down?
CA errors or compromise can result in forged or fraudulent certificates that allow attackers to perform man-in-the-middle traffic attacks to impersonate legitimate properties or can result in mis-issued intermediate certificates that allow attackers to act as their own certification authority and issue fraudulent certificates for virtually any site. In many cases, mistakenly issued certificates have been used by hackers for malicious attacks that have dire consequences, but the fallout after mitigation can be far ranging and harmful. The use of distrusted certificates and their revocation may cause a ripple effect as people will be denied access to government and private sites that were provisioned with the distrusted certificates.
For these reasons, organizations need to adopt agile CA management that allows for managing actively all your certificates from a CA-agnostic platform, automate the rotation, revocation and replacement of keys and certificates, and enforce consistent security policies across all CAs.