Let's Encrypt turned off OCSP: what certificate revocation actually looks like now

The OCSP responder you've quietly leaned on for a decade is going dark, and most teams won't notice until a monitoring check trips. Let's Encrypt served its last OCSP responses in 2025. It won't be the last CA to pull the plug — the incentives point every one of them at the same exit. If your mental model of revocation still involves a client asking a CA "is this cert still good?" in real time, that model is mostly fiction now. So let's walk through what actually happens when a certificate gets revoked in 2026, and what you can and can't see from your own infrastructure.

The timeline: how OCSP got deprecated

The Online Certificate Status Protocol was always a compromise. RFC 6960's idea was sound enough: instead of downloading a giant list of every revoked certificate, a client asks the CA about the one cert it cares about, right now, and gets back a signed good, revoked, or unknown. Real-time, targeted, small.

The trouble is what that request leaks. Every OCSP query tells the CA — and anyone sitting on the network path — exactly which site a user is about to load, stamped with the client's IP. Run responders at scale and you're sitting on a firehose of browsing metadata whether you wanted it or not. Let's Encrypt said as much when it announced the end of OCSP in 2024: the privacy cost of logging per-request client data, plus the operational grind of keeping high-availability responders alive for hundreds of millions of certificates, didn't earn its keep. They set the plan in motion, stripped OCSP URLs out of new certificates through early 2025, and switched the responders off.

The CA/Browser Forum leaned the same way. Ballot SC-063 made OCSP optional for CAs and, in the same breath, made CRLs mandatory again. Sit with that one for a second: the default flipped back to the exact thing OCSP was built to replace. If you run a CA today you don't have to operate a responder, but you do have to publish a certificate revocation list. The OCSP-versus-CRL argument that felt decided against CRLs a decade ago just quietly reversed itself.

Other CAs are copying Let's Encrypt because the math is identical. Responders are expensive to run well, they're a privacy liability, and browsers were barely enforcing them to begin with.

Why OCSP never worked as designed

Here's the part nobody likes to say out loud: OCSP dying doesn't make revocation worse, because OCSP wasn't doing the job in the first place.

The rot starts with soft-fail. When a browser can't reach a responder — a timeout, a network blip, a captive portal, an overloaded server — it doesn't block the connection. It shrugs and carries on. It has to. Hard-fail would turn every responder hiccup into a global outage for every site under that CA. But soft-fail means anyone who can block the OCSP request also kills the revocation check, and if they're already man-in-the-middling the connection, blocking one request is trivial. A revocation mechanism any attacker can suppress isn't security, it's a polite suggestion. Adam Langley was hammering on this at Google years ago, which is why Chrome never bothered with live OCSP lookups for most certificates.

OCSP stapling was supposed to fix the privacy and reliability mess by having the server fetch its own signed status and staple it into the TLS handshake. Good idea, spotty reality. Coverage across the web is a patchwork. Loads of servers don't staple at all, or serve stale responses, or fumble the config, and Must-Staple — the extension that would have made stapling enforceable — went essentially nowhere. I've written before about how brittle that path is in practice; the short of it is that stapling never reached the coverage you'd need to actually trust it.

Then short lifetimes knocked out the last leg the argument was standing on. The whole case for real-time revocation rests on certificates living long enough that "revoke it now" means something. A cert valid for 398 days that gets revoked is a year-long liability. Under SC-081v3's schedule — 200 days now, 100 days come March 2027, 47 days by March 2029 — the window where a revoked cert is still usable collapses toward nothing. If a compromised cert ages out in a couple of weeks no matter what you do, checking its revocation status in real time buys you almost nothing.

What actually replaces it

Revocation didn't vanish. It moved out-of-band, and it got good at the one thing OCSP was bad at: pushing state to clients without making them phone home for every handshake.

CRLs, done properly

This is not your 2010 CRL. The old gripe was that lists ballooned without limit and clients had to pull down megabytes to check a single cert. The modern approach shards them — a CA splits its revocation data across many smaller, versioned, individually cacheable CRLs, so a client or an aggregator fetches only the shard it needs and caches it behind a CDN. That's what SC-063 forced CAs to publish, and it's the raw material for everything downstream.

Browser-side aggregators

Here's the clever bit: your browser mostly doesn't read those CRLs directly either. The big clients slurp them up centrally, compress the revocation state, and push it down to you.

Mozilla's CRLite is the sharpest version of this. It ingests every CRL across the WebPKI, encodes the whole "is this revoked?" question into a cascade of Bloom filters, and ships a few-megabyte structure that answers for tens of millions of certificates with zero network requests at check time and zero per-lookup privacy leak. Firefox pulls updates on a schedule and answers locally.

Apple keeps its own on-device valid/revoked lists, compiled from CRLs and pushed through system updates. Chrome ships CRLSets — a curated, aggregated revocation list baked into the browser and refreshed out-of-band. It's smaller and far more selective than CRLite, aimed at high-value revocations rather than blanket coverage. Three implementations, one architecture: the client learns revocation state from a bundle it updates on a timer, not by pinging a CA mid-handshake.

The honest tradeoff is latency. Out-of-band push means a lag — minutes to a day — between a CA revoking and every client finding out. OCSP promised near-instant, and then failed to deliver it anyway thanks to soft-fail and caching. The ecosystem picked slow-but-dependable over instant-but-defeatable. I think that's the right call. But it is a call, and you should know which side of it your infrastructure is standing on.

The operational reality

All of this changes what you can observe, and a few things break without making any noise.

You can't point a monitoring check at an OCSP responder to confirm a cert is good anymore. If you've got synthetic checks querying OCSP as a health signal — and plenty of TLS monitoring setups still do — those checks are now hitting dead or dying endpoints. Best case, they test nothing. Worst case, they page your on-call about a responder that disappeared on purpose.

Must-Staple certificates flip from feature to liability. A cert carrying the Must-Staple extension tells clients to reject the connection if there's no stapled OCSP response. Turn off the CA's responder and your server has nothing to fetch and staple, so a strict client hard-fails the handshake. If you issued Must-Staple certs back when it looked like good hygiene, go find them now. Every one is a time bomb wired to its CA's responder shutdown date.

And the big one: revocation is now something you largely cannot see from your own infrastructure. The authoritative answer lives inside Firefox's CRLite build, Apple's system lists, and Chrome's CRLSets, and not one of them hands you a clean API to curl from a health check. You can pull your CA's CRL shards and parse them yourself — you should know how — but the client-side truth is out of reach. For anyone who built certificate monitoring around "ask the responder," that's a genuine shift.

What to actually do

Stop treating OCSP as a signal. Rip responder reachability out of your health checks and synthetic monitors. If a check's only job was confirming a responder answered, delete it — it's testing infrastructure that's being decommissioned on purpose.

Make short lifetimes your revocation story. Under the 47-day regime, your real answer to "this cert is compromised" becomes "it expires soon and we rotate fast." That only holds if renewal is fully automated and you can force an early rotation on demand. If revoking and reissuing today still means a human editing a runbook, fix that before 2027. The safety net of leisurely long-lived certs is being cut down.

Know where your CA publishes CRLs. Find the distribution points in the certs you actually issue, learn the sharding scheme, and know how to fetch and read a shard when you need to confirm something got revoked. It won't tell you what clients believe. But it's the authoritative source, and it's the one revocation artifact you can still query directly.

Then monitor the things that are still yours: issuance and expiry. You can't watch a revocation propagate through Firefox, but you can watch every certificate in your estate — what it's valid for, when it expires, whether the last renewal succeeded, whether something you never authorized showed up in a CT log. That's the visibility that actually keeps the 2am pages away. A live inventory across ACM, Key Vault, GCP, and your external endpoints, with expiry thresholds and renewal-failure alerts wired up, is exactly what CertPulse handles, and it's the slice of the revocation-and-renewal picture that sits firmly on your side of the line.

OCSP is ending because it never really worked, and the thing replacing it works better at the price of being invisible to you. Adjust your monitoring for the world we're actually in: revocation is the CA's problem and the browser's problem, and expiry is yours.