What Entrust certificate distrust means for developers

Public key infrastructure (PKI) — first introduced by Whitfield Diffie and Martin Hellman in an IEEE paper in 1976 — has secured web communications like clockwork for decades. For every site visit, PKI brokers trust between web browsers and websites, proving the identity of the website owner and encrypting the connection to avoid eavesdropping or man-in-the-middle (MITM) traffic interception.

In what’s commonly referred to as the “public trust chain,” server authentication or HTTPS certificates are overseen by certificate authorities (CAs), which certify the identities of websites and keys, using certificate chains and signature algorithms. Overall, these public trust chains have been so effective in securely brokering site traffic, they have become more or less taken for granted and boring in their predictability, which is the highest praise for any system of trust.

Except when, as sometimes happens, a leading browser maker loses faith in a CA.

In June, Google’s Chrome Security Team announced that Chrome would no longer trust new server authentication certificates by CA provider Entrust by default. The change will take effect in Chrome 131 and higher, and will apply to “TLS server authentication certificates validating to the following Entrust roots [see list] whose earliest signed certificate timestamp (SCT) is dated after November 11, 2024 (11:59:59 PM UTC).”

The Chrome Security Team explained their decision in the announcement:

Over the past six years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports. When these factors are considered in aggregate and considered against the inherent risk each publicly-trusted CA poses to the Internet ecosystem, it is our opinion that Chrome’s continued trust in Entrust is no longer justified.

The kerfuffle has brought new attention to the PKI community, and led many developers who maintain certificates to wonder if they need new contingency planning for certificates to reduce any future exposure.

To learn more, InfoWorld’s Travis Van spoke with Arvid Vermote, CISO and head of security and compliance at certificate authority GlobalSign. 

Travis Van: What should developers understand about this world of PKI, what’s at stake, and why Chrome blocking Entrust certificates is so important.

Arvid Vermote: A lot of people think of certificate authorities as cryptography, algorithms, and encryption. But PKI is more about identities, trust, audits, and risk management. 

When a TLS handshake is established, there’s a negotiation of shared keys and encryption. As part of that negotiation the website presents a certificate it obtained from a certificate authority, and then the browser builds a validation chain to make sure it is ultimately signed by a root CA key that it trusts. It’s called chain building, and that’s done basically by the certificate provided on the website, up through the root CA included in the browser.

What’s unique about PKI is not so much the attack type, but the impact it could have. Any CA that’s been around has ubiquity in all of the browsers and operating systems with their embedded root CA keys. So, if an attacker can compromise such a root key or its certificate issuance mechanism, they could impersonate pretty much anything on the internet and, hence, combined with man-in-the-middle, intercept any exchanged information. That’s why this security domain is taken so seriously.

Van: What does the community governance look like for PKI, in terms of how the integrity of the certificates is policed?

Vermote: Obviously, all of the world’s most popular browsers — Chrome, Edge, Safari, and Firefox — along with the companies behind them and the user (security) community, supervise the CAs. Notably Mozilla performs all discussions and supervision of CAs publicly and transparently, and a lot of the discussion and information disclosed in the Mozilla discussion forum (Mozilla Dev Security Policy) affects the opinion of the user community and possibly other browser root programs. 

In addition to the browser community and the public Mozilla open community conversations, there is a consortium of the browsers and certificate authorities that’s called the CA Browser Forum. Collaboration is constant including three face-to-face meetings a year to discuss standards, identity on the internet, and publish baseline requirements that every CA needs to adhere to. CAs are audited against those baseline requirements on an annual basis in order to demonstrate the latest best practices in validating identities and protecting CA keys. Basically, it’s a series of checks and balances for demonstrating continuous trust.

Van: What was the significance of Google citing Entrust’s pattern of behavior and announcing that it will no longer trust Entrust roots whose earliest signed certificate timestamp is dated after November 11, 2024?

Vermote: Within the community, the most common perception was that it wasn’t so much the incidents that Entrust had as a CA, but more their unwillingness to disclose those incidents in the expected transparency and to take the required response and mitigative actions. From a trust perspective, they made contradictory statements, they had to be compelled by the community to disclose information, and Chrome basically revoked its trust with one of the main drivers the lack of transparency and cooperation on their incident response.

Google’s action was strong, it didn’t include much warning, and there was no clear way for Entrust to appeal it. But it gave a very clear signal to the community that this type of lack of disclosure and incident response by CAs will not be tolerated. 

I think while it’s obviously scary to CA providers that a single browser could make a decision that could make millions of dollars in revenue go away for any CA, the importance of systems of trust and transparency on the internet are such that it was a necessary action. 

Van: What are the implications for developers who were maintaining Entrust certificates? And beyond that, what are the broader implications for any developers who are overseeing certificates?

Vermote: The browsers announced their plan to end support for those Entrust certificates in June, whereas the actual distrust is happening in November. So, I think website operators were given sufficient time to make adjustments.

What’s really demonstrated by this situation is that a CA that is trusted today may not be trusted tomorrow. That’s bringing a lot of contingency planning into play for how to best handle any scenario where a certificate may suddenly no longer be trusted, and where the CA itself may even be hacked, down, or distrusted, and not be able to provide a new certificate.

If a CA were compromised in terms of a serious breach compromising its root or issuing CA, it would only take a matter of a couple of hours for browsers to start distrusting the CA, and as a consequence a significant number of internet websites. 

That’s why developers need to have backup plans for their certificates. Websites that are carrying a lot of traffic and revenue already typically have two certificate authorities, so they can immediately switch from one to the other, so it is recommended you have a business continuity plan in place that includes automation. This is similar to high availability in data services and other replication and redundancy strategies in enterprises.

Van: Where does automation come into play, and what does the future look like for certificates?

Vermote: Beyond this Entrust case, there is a trend in the public trust chain to shorten the validity of certificates. Previously certificates would be good for five years, but they are moving toward 90 days in the foreseeable future. That’s bringing automation into the discussion. 

In the last few years we saw the introduction of the automated certificate management environment (ACME) protocol for automating issuance and updating of certificates. ACME allows you, through tooling, to automatically manage and renew certificates. In this case you just need a link with a CA and it will issue, renew, and/or re-issue the certificate. If you want or need to switch the CA, you just change the config, and automation gets you another certificate from another CA.

But where things are much more complicated is when you have a need for certificates with higher levels of identity assurance. The higher-level certificates rely on manual processes like presenting identity documents, signing agreements, providing company documents, etc. In those cases, if something happens with the CA you need multiple people involved, and often a notary. So, it’s smart to always validate with two certificate authorities to create redundancy.

One of the most interesting arenas for this PKI automation is with static site generation. CAs have invested a lot into devops tooling for containerized websites, so you can deploy certificates at the same time you spin up containers for a new React service, for example. CAs today are shipping new utilities to make it easy to deploy certificates to containerized environments.

Apart from automation and reduced certificate lifetimes, the other big thing going on in the industry today is preparing certificates for something that hasn’t even arrived yet. It’s a movement referred to as post-quantum cryptography (PQC). Even though quantum computers are still very early, we know they will be advancing within a few years. The concern is that anything high value that is intercepted today might be kept around, and then once quantum computers are more advanced they will be able to decrypt it (harvest now, decrypt later). This quantum-resistant cryptography movement is driving a lot of standards bodies work among the CAs and browsers for how to issue quantum resistant certificates.