On August 6, 2025, Let’s Encrypt turned off its OCSP responders for good. This is the certificate authority that issues for a few hundred million domains — the biggest one on the internet by a wide margin — switching off the mechanism browsers were supposedly using to check whether its certificates had been revoked.
If your site kept working through August, and it almost certainly did, that’s the whole story right there. The machinery for asking “is this certificate still valid?” got unplugged at the largest source of certificates on the web, and the web didn’t notice. That should tell you something about how much the machinery was ever doing.
What OCSP Was Supposed to Do
A certificate is a signed claim with an expiry date. The problem is that sometimes you need to invalidate one before it expires — the private key leaked, the domain changed hands, the CA discovered it mis-issued. Revocation is the “undo” button for a certificate, and it has never really worked.
The first answer was the Certificate Revocation List: the CA publishes a big signed file of every serial number it has revoked, and clients download it. CRLs got large and stale, so in 1999 the Online Certificate Status Protocol (RFC 2560, later RFC 6960) offered a smaller-scoped alternative. Instead of pulling the whole list, the browser asks the CA one question in real time: is the certificate with this serial number still good? The CA’s responder signs back “good,” “revoked,” or “unknown.”
On paper it’s tidier than a CRL. In practice it created two problems that were worse than the one it solved.
The Two Problems
The first is privacy, and it’s the reason Let’s Encrypt gave for pulling the plug. Every time your browser does a live OCSP lookup, it tells the certificate authority — a third party you never chose to talk to — which site you’re about to visit, tied to your IP address, in real time. The CA gets a running log of a slice of your browsing. For a CA the size of Let’s Encrypt, running that surveillance apparatus was both a privacy liability and an enormous operational cost: billions of lookups to answer, for a check that mostly didn’t do anything.
Which is the second problem, and it’s fatal. What is a browser supposed to do when the OCSP responder doesn’t answer? The responder might be down, slow, or blocked by the very network attacker you’re worried about. If the browser refuses to load the page every time a lookup fails (“hard-fail”), then any OCSP outage takes down every HTTPS site that CA issued for — an unacceptable single point of failure. So browsers “soft-fail”: if the lookup times out or errors, they shrug and load the page anyway.
Adam Langley of Chrome’s security team put it best back in 2012: soft-fail revocation checks are “like a seat-belt that snaps when you crash.” An attacker who can intercept your connection to serve a revoked certificate can also block your connection to the OCSP responder. The lookup fails, the browser soft-fails, and the check you were relying on evaporates at the exact moment you needed it. Revocation checking works fine right up until it matters.
Chrome Already Left, Years Ago
This is the part that makes the 2025 shutdown feel less like an event and more like a formality: the browser with the most users had already stopped doing live OCSP checks by default over a decade ago.
Chrome disabled online OCSP and CRL checking for most certificates back in 2012, for exactly the reasons above, and replaced it with CRLSets — a curated list of high-value revocations that Google compiles and pushes to the browser through its update channel. It’s not comprehensive; it’s a shortlist of the revocations Google decides are worth including. Microsoft Edge, built on the same engine, behaves the same way. So for years, the majority of browsers on the planet were not asking Let’s Encrypt’s responders anything at all. The responders were answering Firefox, some Safari traffic, and a long tail of server-side and enterprise clients.
Firefox held onto OCSP longer, then went its own way with CRLite: Mozilla aggregates the CRLs from across the CA ecosystem, compresses them with a clever cascade of Bloom filters into a few megabytes, and ships that to the browser so revocation can be checked locally, privately, and without a network round-trip that can be blocked. It’s the CRL idea reborn with modern compression — which is, not coincidentally, the direction Let’s Encrypt pointed everyone toward when it announced the OCSP shutdown. It kept publishing CRLs; it just stopped answering one-at-a-time questions.
So Was Any of It Real?
Here’s the uncomfortable conclusion. The revocation checking that browsers actually do today — CRLSets in Chrome, CRLite in Firefox — is aggregated, pushed out of band, and evaluated locally. None of it depends on your browser phoning the CA mid-handshake. The live OCSP lookup, the thing OCSP was invented to provide, had already been designed out of the browsers that matter. Turning off the responders in 2025 didn’t remove a working safety mechanism. It removed the appearance of one.
And the industry’s real answer to revocation was never a better protocol. It was making certificates expire faster. If a certificate is only valid for a few weeks, a leaked key is a problem for a few weeks, not a few years, and revocation matters proportionally less. That’s the actual logic behind the march toward shorter lifetimes — 200 days now, 47 by 2029. We couldn’t make “undo” work, so we made the window it applies to smaller and smaller until the failure stopped mattering.
The lesson isn’t that OCSP was uniquely bad. It’s that a security control everyone assumes is protecting them, but which fails silently and open, is worse than no control — because it buys the assurance without delivering it. OCSP spent twenty years as a checkbox that browsers had quietly stopped ticking. Its shutdown didn’t break the web. It just made the paperwork match reality.