Well, the writing has been on the wall for some years now, arguably over a decade, but the time has finally come where the largest CA in the World is going to drop support for the Online Certificate Status Protocol.

What is OCSP?

The Online Certificate Status Protocol is a mechanism that was created to check if an SSL (TLS) certificate is revoked. It is quite simple in operation, requiring a client that has been presented with a certificate from a server, to call back to the OCSP Responder hosted by the issuing Certificate Authority, and ask to see if the certificate has been revoked since issuance.

A certificate can be revoked for many reasons, but the most concerning one is that the private key associated with the certificate was compromised. That means it is possible that the server currently presenting the certificate to you may not actually be the site that you think you're connecting to, it could be an attacker or other hostile entity impersonating that site, and you'd have no way to tell. Knowing that the certificate was revoked would prevent you falling victim to this attack, and allow you to discard the certificate and close the connection safely.

What are the problems with OCSP?

The problems with OCSP are plenty, and Let's Encrypt point out their main concerns in their announcement to end support for OCSP, but here is my overview:

Privacy

If you visit a website, let's say adult-entertainment.com, then your browser is going to receive their certificate and then send a request to the issuing CA to say "Hey, is the certificate for adult-entertainment.com revoked?"... You're leaking your browsing activity to the CA who could now track the sites you visit in real-time!

Performance

The OCSP check is a HTTP request/response roundtrip on the network, on top of the necessary DNS and TCP roundtrips too. On top of that, we have any time spent waiting for an answer from the OCSP Responder. This is slowing us down!

Availability

What do we do if the OCSP Responder is down? Well, it turns out, clients don't really care and they just skip the check and accept the certificate anyway, making the whole thing pointless. OCSP checking add no security!

Depending on who you speak to, there are also other valid concerns with OCSP checking, but these would be my main points. The industry has tried to respond to these over the years, looking for ways to fix the inherent issues, but none have managed to quite make it over the line.

Can OCSP be saved?

Over a decade ago (yes, really, 10+ years ago!), I wrote about OCSP Stapling, which helped to mitigate the performance and privacy costs of OCSP checking. OCSP Stapling is awesome, and everyone should support it, even now, because it does help to protect the privacy and performance of visitors to your site, but sadly, it doesn't add any tangible benefit, it only removes the negatives.

A few years after that, around 2016-2017, the ideas of OCSP Expect-Staple and OCSP Must-Staple were floated. These were potentially the solution to the problem of soft-fail within OCSP, where clients don't care if the OCSP check fails, and they just continue on regardless. Sadly, staking the availability of your site against the availability of an OCSP Responder that you don't control didn't prove to be very popular.

Later in 2017, I published Revocation is broken, outlining all of the above, and more, in great detail, and it's well worth a read if you want to get to the bottom of understanding the issues.

Despite the evidence, despite another post in 2020 Demonstrating that revocation checking is pointless, despite OCSP causing major issues for Apple and MacOS users, OCSP lived on. But no more!

Let's Encrypt Ending OCSP Support in 2025

I know that Let's Encrypt are only one CA among many, but they are the largest out there in terms of their volume of issued certificates, and by quite a considerable margin. That's why them announcing this change is going to have such an impact, and I think it's going to surface a few issues in the wider ecosystem.

Let's Encrypt first announced their Intent to End OCSP Service in July 2024, and just recently, in December 2024, they announced that they will be Ending OCSP Support in 2025. Here's the current schedule:

January 30, 2025
OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension

May 7, 2025
Prior to this date we will have added CRL URLs to certificates
On this date we will drop OCSP URLs from certificates
On this date all requests including the OCSP Must Staple extension will fail

August 6, 2025
On this date we will turn off our OCSP responders

source: https://letsencrypt.org/2024/12/05/ending-ocsp/

In an ideal world, this would cause absolutely no problems whatsoever, but we don't live in an ideal world. For over a decade now, certificates have somewhat reliably always had an OCSP URL in them for clients to check against, if they wish, and the removal of that may break some expectations. Looking at my own internal traffic at home, I can use my DNS server running Pi-Hole to check just how popular OCSP traffic is, and it turns out, it's pretty darn popular with OCSP responder domains being some of the most frequently looked up, and blocked. (Side quest: I block all OCSP DNS lookups in my home network)

It's one thing to not be able to communicate with the OCSP Responder and then soft-fail through the error, but what if you're expecting an OCSP URL to be present in the certificate, and it isn't?

That's a lot of traffic!

Can you imagine, as the CA issuing certificates, that every TLS connection established where one of your certificates was served, could potentially result in an OCSP request being sent to you? Imagine being the CA that issued the certificate for google.com, how many OCSP requests do you think you'd receive in a single day?!

I was curious, and it seems that CAs are very secretive about their numbers and I couldn't find anything reliable at all, so I decided to reach out to Josh Aas, Executive Director of Let's Encrypt, and ask! He kindly provided some information and, the numbers are staggering!

83 billion CDN hits per week.
11 billion origin hits per week. 

or

~137,000 CDN hits per second.
~18,000 origin hits per second.

Given that OCSP checking is a simple HTTP request/response cycle, it is very suitable to caching, and that's how Let's Encrypt are achieving a ~87% CDN offload. The problem is that OCSP responses can't be valid for a long period of time, as that would defeat their purpose, so the cache will need to be replenished regularly. Either way, handling ~18,000 requests per-second that require database activity is still a pretty sizeable cost for a non-profit organisation like Let's Encrypt that runs entirely on sponsorships and donations. I'm sure they will be happy to see it go and spend that valuable money and effort elsewhere.

The future of revocation checking

Whilst I think that, ultimately, the solution for revocation checking is certificates that are so short that we don't need revocation checking, we need something else in the interim. We're a little way off having <= 7 day validity periods on certificates, so what's going to stem the gap between now and then?

CRLite

I've spoken about CRLite before, and it's a really awesome solution to the problem of revocation checking. You can read more in CRLite: Finally a fix for broken revocation?, but the TLDR is that it had to be a new mechanism that solved all of the existing problems:

  • ⚖️ The size issue of CRLs.
  • 🎭 The privacy issues of OCSP.
  • 📈 The performance costs of online checks.
  • ❌ The single point of failure.
  • 👎 The soft fail approach to revocation checking.

Using a probabilistic data structure called a Bloom Filter, with full details in the linked blog post, it looks like we finally have a solution for the problem of revocation. Mostly...

This is a concern for another blog post, but my gut feeling is that CRLite is really only viable for desktop platforms and powerful mobile devices, and probably unrealistic to consider for most other clients. Whilst that's a huge step forwards from where we are now, which is basically no revocation checking at all, it's still not an ideal scenario that will cater for all clients. That said, I do believe dropping OCSP is the right thing to do and that our efforts as an industry are better directed elsewhere. One thing I will be keeping an eye out for is any unexpected side-effects of removing those OCSP endpoints from certificates!