Certificate revocation has always been the weakest link in the public-key system. We can issue certificates and we can expire them, but telling the world that a still-valid certificate should no longer be trusted has never worked cleanly. In 2025, Let's Encrypt began shutting down its OCSP service, and that decision marks the end of a model the web leaned on for fifteen years.
The Problem Revocation Tries to Solve
A certificate has an expiry date, but sometimes you need to kill one before then. The private key leaks, a server is compromised, or a certificate was issued in error. Revocation is how a CA says: ignore this certificate even though the dates still look valid.
The hard part is delivery. Every client that sees the certificate needs to learn it was revoked, in near real time, without a usable mechanism turning into a privacy leak or a performance tax. Two approaches tried to do this, and both have aged badly.
CRLs and OCSP, and Why Both Struggled
The first approach was the Certificate Revocation List, a signed file the CA publishes listing every revoked serial number. Clients download it and check. The problem is size: a busy CA's CRL can be enormous, and a client cannot refetch a huge list on every connection, so it caches, and a cache means stale data.
The second approach was the Online Certificate Status Protocol. Instead of downloading the whole list, the client asks the CA about one specific certificate: is this serial still good? OCSP fixed the size problem and created two new ones. It was slow, adding a network round trip to a CA server during the handshake, and it was a privacy hole, because the CA now saw which sites every user visited. Worse, most clients failed open: if the OCSP responder was unreachable, they accepted the certificate rather than break the connection, which made the check easy to bypass and arguably pointless.
OCSP stapling tried to patch this by having the server fetch its own status and staple it to the handshake, removing the round trip and the privacy leak. It helped, but stapling was inconsistently deployed and never became universal.
Why Let's Encrypt Pulled the Plug
Running OCSP at the scale of the largest CA on the web is expensive, and the privacy cost is real. Let's Encrypt concluded the service was not worth those costs given how little protection failing-open revocation actually provided. So it announced an end to OCSP and a shift toward CRLs delivered through the browser, plus the lever that increasingly matters most: short lifetimes.
The reasoning connects directly to why certificate lifetimes are getting shorter. If a certificate only lives 47 days, the window in which a compromised certificate can be abused shrinks to weeks, and revocation matters less because expiry does the job soon enough. A short lifetime is a crude form of revocation that always works.
How Browsers Handle It Now
The modern model moved revocation out of the handshake and into the browser vendor. Chrome uses CRLSets and Firefox uses CRLite, both of which aggregate revocation data from CAs, compress it aggressively, and push it to browsers out of band. The client checks a local data structure instead of phoning a CA mid-connection. No round trip, no privacy leak, no fail-open.
For most public web certificates, this means revocation is now something the browser handles and you do not configure. The practical shift for operators is that you should not rely on OCSP being there, and you should not build tooling that assumes a live responder.
What This Changes for You
If you run standard public certificates, the day-to-day impact is small, but a few things are worth checking. Confirm nothing in your stack hard-depends on an OCSP responder that may disappear, including monitoring scripts that query OCSP to judge certificate health. If you use OCSP stapling, know that its value is fading and a stapling misconfiguration is no longer worth an outage. And lean into the real direction of travel: automate renewal so short lifetimes carry the revocation load for you.
The signal that actually protects you now is freshness. A certificate that rotates every few weeks limits exposure better than a revocation check that fails open ever did. SSL certificate monitoring keeps that rotation honest by watching what your endpoints serve, and Generator Labs certificate monitoring alerts you when a certificate is drifting toward expiry instead of renewing on schedule. To inspect what a given host is serving right now, the SSL certificate checker shows the live certificate and chain. Start monitoring.