Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

Everybody is talking about OCSP now because, just last month, at the end of 2024, Let’s Encrypt announced it was going to stop supporting online certificate revocation checking. Beginning in early May 2025, there will no longer be any OCSP revocation information in Let’s Encrypt’s certificates. Once all its earlier certificates expire, Let’s Encrypt will shut down its OCSP servers.

Let’s Encrypt’s reasoning is sound. As it stands today, OCSP is not making anyone more secure. Browsers are either not checking it or are implementing it in a way that provides no security benefits. As a result, OCSP is just costing Let’s Encrypt good money in personnel and infrastructure costs. How much money? Let’s Encrypt hasn’t disclosed the actual costs, but its executive director did share with Scott Helme that Let’s Encrypt was servicing about twelve billion OCSP requests daily (about 140,000 every second).

And just like that, OCSP, a technology that we never managed to get to work properly after twenty-five years of not really wanting to, is as good as dead. Not all is lost, though. If you want better security, switch to short-lived certificates of only six days (!), which Let’s Encrypt will start to offer later in 2025.

We Gave Up on OCSP Together

But this wasn’t actually just Let’s Encrypt’s decision to make. Like every other CA, Let’s Encrypt has to follow the ecosystem and root program rules, which are the same for everyone. And it’s the ecosystem that decided to put an end to a long struggle with revocation checking, sidestepping the problem by implementing short-lived certificates.

First, in August 2023, the CA/Browser Forum voted to make OCSP optional, CRL mandatory, and short-lived certificates possible. That decision became effective in March 2024. Then, in October 2024, Microsoft updated its root program requirements with the same decisions and opened the door for individual CAs to do with OCSP as they pleased.

As it stands, it looks like we will replace revocation checking with a two-tier system of certificates: standard certificates, valid for up to forty-seven days, for most people; and short-lived certificates, valid for up to seven days, for those who wish to opt into better security.

History

To understand why OCSP is being killed off, we have to go back in history to the very beginnings of public certificates.

When we issue certificates that are valid for a longer period of time, we need to have a way to deal with the inevitable: What happens when the certificate is no longer considered secure or valid? In this situation, the certificate itself is not sufficient to establish a secure connection; we also need a revocation mechanism in place.

From the very beginning, we had Certificate Revocation Lists, or CRLs. The idea behind these lists was simple: every certificate issuer would also track and continuously publish a complete list of all revoked certificates. Certificate consumers would periodically download the CRLs from the CAs they cared about and verify that the certificates they were using were still valid.

That sounds great, but it doesn’t work at world scale. A typical user might encounter certificates from many CAs in a single day and thus need to track many CRLs. For some reasonable level of safety, every user would need to download every CRL on a daily basis. In the early days of the internet, bandwidth was at a premium for everybody. Later, it wasn’t, but by then most of the world had switched to mobile devices, and so bandwidth became a problem again. Add in the fact that everyone is now using HTTPS and the number of revoked certificates (and the CRL size) has exploded.

This problem became apparent early on, which is why we came up with Online Certificate Status Protocol (OCSP). As the name suggests, OCSP is intended to support real-time certificate revocation checking. That’s great! Now, instead of downloading bulky CRLs all the time, we only need to check the specific certificates we need, as we need them.

Unfortunately, it wasn’t to be. Although OCSP was standardized in 1999, implementing it wasn’t a high priority for then-leading browsers. Internet Explorer enabled it by default in 2006, Firefox in 2008, and Apple in 2011. Chrome had OCSP from its first release in 2008.

Because browsers were not implementing OCSP, CAs got used to receiving no traffic to their OCSP servers and didn’t spend a lot of time supporting that infrastructure. By the time the usage eventually grew, OCSP performance problems were common and frequent. It took a while for CAs to adopt CDNs for reliable and performant revocation checking.

It was too late by then. So-called soft-fail OCSP revocation checking became the norm. Faced with unreliable OCSP servers, browsers decided to support OCSP revocation checking, but basically ignore any networking problems they encountered. That is, unfortunately, pointless. If you’re under an active network attack with someone attempting to attack you using a revoked certificate, you need a hard fail. You need browsers to protect you by not proceeding unless they can prove the certificate is still valid. In the absence of a hard-fail response, attackers can simply block your OCSP attempts and carry on.

There were other problems too—for example, the fact that OCSP revocation checking doesn’t work without public internet access (so called captive portals), or the fact that it took some CAs ages to propagate information about new certificates to their OCSP servers. (CA/Browser Forum updated Baseline Requirements only this month to require this to happen within fifteen minutes.)

Realising this, Chrome disabled OCSP in version 19, released in 2012. And it has been a better browser for it: There’s no point in implementing OCSP using the soft-fail approach. It’s not helping anyone in an adversarial, active-attack situation.

There’s More to the OCSP Story

The history of OCSP is long and includes some nuances, which I omitted from the previous discussion in favor of telling a reasonably concise story. But there are a couple of additional details you should be aware of:

• OCSP responses are cached. Although it sounds like OCSP checking happens in real time, it actually doesn’t. To improve performance and save on costs, CAs pregenerate OCSP responses and distribute them via CDNs with caching enabled. In preparing to write this article, I surveyed several popular CAs, and all of them produced OCSP responses that were valid for about seven days. Baseline Requirements currently (in version 2.1.2) allows OCSP response lifetimes from as little as eight hours up to as long as ten days.
• There is a vulnerability to replay attacks. Because OCSP responses are cached, an attacker who obtains a valid certificate and key can continue to abuse them for as long as the corresponding OCSP response remains valid. OCSP does support a mode of operation that’s not vulnerable to replay attacks, but this mode is seldom supported or used.
• OCSP leaks your personal information on the network. OCSP requests, by design, reveal to the CA which website you’re visiting. This is information that CAs can potentially abuse. In addition, all such traffic is unencrypted, meaning that intercepting the OCSP traffic of only a couple of main CAs can give a powerful adversary a very good idea of what websites are visited by which IP address on the internet. (To be fair, TLS leaks this information as well via the SNI extension, but it would be more difficult for a government agency to collect.)
• OCSP stapling solves OCSP performance issues. RFC 4366, from April 2006, standardizes a way of attaching (stapling) OCSP responses preemptively to TLS handshakes. This solves both the performance problems and the privacy issues.
• Must-Staple solves the remaining problems, but Chrome and Safari didn’t care for it. RFC 7633, from October 2015, introduces an X.509 extension that can be used to indicate that a certificate can be considered to be valid only if a fresh OCSP response is stapled to it. On the surface, this resolves all problems: Website operators can improve their security and browsers can ignore OCSP in all other situations. Sadly, even though Firefox added support for it, the other browsers quietly refused to implement it. One possible reason for their refusal was the generally bad state of OCSP stapling in popular web servers such as Apache and Nginx. Microsoft’s IIS Web Server always had a robust OCSP stapling implementation. Among open source servers, Caddy came later and also implemented robust stapling.

Back to CRLs

With OCSP virtually over, we’re back to CRLs for revocation checking, but the approach has changed. Instead of user agents consuming the CRLs directly, major browser vendors (and, presumably, operating systems) maintain their proprietary revocation checking built on continuous processing of all known CRLs. It remains to be seen if this is a feasible solution for every single revocation, especially when it comes to mass-revocation. At the very least, we can expect that intermediate certificates will be covered.

It’s the End of the Road for OCSP

Can OCSP recover? Not likely, because no one seems to care about it. Browsers never liked the performance penalties, the privacy leakage, and generally having another way to trigger certificate warnings. Open-source software—with exception of Caddy—never bothered to implement OCSP stapling properly. CAs never liked the costs of having to support OCSP at high volumes.

Customers never pushed for a better revocation story, anyway. In truth, we don’t really hear about attacks using stolen keys and certificates, do we?

It is possible that OCSP will remain in use for specialist use cases—for example, in private environments where both sides of a communication are under the control of the same party. It is conceivable that it could be used robustly in such situations, and even with enforced real-time validation for maximum security.

At the end of the day, with short-lived certificates, we—finally—have a plausible revocation checking story, even if it doesn’t actually involve any revocation.