What ended for good on 6 August 2025
The Online Certificate Status Protocol is specified in RFC 6960 (IETF, RFC 6960). The idea was elegant: instead of downloading a full revocation list, the client asks about exactly one certificate — "is this serial number revoked?" — and receives a signed answer from the certificate authority. In practice the model carries three weaknesses it barely shook off over two decades: it costs an extra network round trip during connection setup, it typically falls back to "soft-fail" when the responder is unreachable — meaning the client connects anyway — and it tells the CA which site a user is visiting right now.
Let's Encrypt announced the exit on 5 December 2024 and executed it in three steps (Let's Encrypt, "Ending OCSP Support in 2025"): from 30 January 2025, requests carrying the OCSP Must-Staple extension failed for accounts that had not previously issued such a certificate. On 7 May 2025, OCSP URLs disappeared from newly issued certificates. On 6 August 2025, the responders went dark. The service ran for roughly ten years; towards the end a CDN carried 140,000 requests per second, while 15,000 requests per second reached the origin (Let's Encrypt, "OCSP Service Has Reached End of Life").
Anyone opening a page over HTTPS and triggering an OCSP query tells the certificate authority which website is being visited from which IP address. Let's Encrypt names exactly this as the main reason for the shutdown: even when a CA deliberately does not retain that data, it could be legally compelled to collect it (Let's Encrypt, "Ending OCSP Support in 2025"). For operators in the EU that is more than a footnote — it is a data flow to a third party that can arise on every connection setup.
Let's Encrypt has additionally published revocation information as a CRL since September 2022, and since 6 August 2025 exclusively that way (Let's Encrypt, "OCSP Service Has Reached End of Life"). The key point: the revocation information has not disappeared. It changed channels. Anyone running SSL monitoring as an ongoing task therefore has to reassess which checks still carry any meaning.
CRLs: the mandatory publication path for CAs
The groundwork was laid long before the shutdown. With Ballot SC-063, the CA/Browser Forum decided in July 2023 to make OCSP optional and CRLs mandatory. The vote passed among certificate issuers with 28 yes to 1 no, and unanimously among browser vendors at 3 to 0 (CA/Browser Forum, Ballot SC-063). The requirements took effect on 15 March 2024 (CA/Browser Forum, Ballot SC-063). Since then the rule is: a CA may offer OCSP — but it must maintain CRLs.
- A new CRL within 24 hours: after recording a revocation, the CA must publish an updated CRL within 24 hours (CA/Browser Forum, Ballot SC-063).
- Regular refresh: at least every seven days if the certificates carry an AIA extension with an OCSP pointer — otherwise at least every four days (CA/Browser Forum, Ballot SC-063).
- A defined profile: the CRL must conform to the prescribed profile, which builds on the CRL profile in RFC 5280 (IETF, RFC 5280).
- Completeness: the published lists must cover the entire population — either as one list or as partitioned lists that together add up to the full set (CA/Browser Forum, Ballot SC-063).
- OCSP stays permitted: anyone who keeps running OCSP remains subject to the existing requirements unchanged (CA/Browser Forum, Ballot SC-063).
That solves one side of the equation cleanly: revocation information is published reliably and within defined deadlines. Mozilla counts roughly 3,000 active CRLs disclosed by certificate authorities in its own root programme (Mozilla Security Blog, CRLite). If you want to know which certificates exist for your domains in the first place, pair this with Certificate Transparency monitoring — CT shows issuance, the CRL shows revocation.
The CRL mandate governs what the certificate authority must do. It does not govern what the browser does with it. This is exactly where most assumptions break: a correctly and punctually published revocation is no proof that a visitor can no longer reach your revoked site.
What the browser really checks: CRLSets and CRLite
No mainstream browser downloads a roughly 300 MB collection of revocation lists on every connection — that is the order of magnitude of all CRLs in Mozilla's root programme (Mozilla Security Blog, CRLite). Instead, vendors aggregate. Chrome uses CRLSets: lists compiled by Google and shipped with the browser. Online lookups via OCSP or CRL do not happen by default (Chromium Project, Chrome Root Store FAQ).
"Timeouts … Local-network attackers can block 'online' lookups … OCSP leaks browsing history to third-parties … CRLs can be quite large."
— Chromium Project, Chrome Root Store FAQ — on the systematic weaknesses of revocation lookups
Scope is the decisive point. A recent CRLSet measures about 600 kB and covers roughly 1 percent of all revocations — around 35,000 out of four million (Mozilla Security Blog, CRLite). Firefox has taken a different route since version 137: CRLite distributes the complete revocation set of the Web PKI to clients in compressed form, which then check locally and without any network lookup (Mozilla Security Blog, CRLite).
| Client | Mechanism | Coverage | What that means for your revocation |
|---|---|---|---|
| Chrome / Chromium | CRLSet, shipped with the browser | roughly 1 % of revocations (Mozilla Security Blog, CRLite) | Bites mainly for revocation reason keyCompromise or privilegeWithdrawn (Chromium Project, Chrome Root Store FAQ) |
| Firefox from version 137 | CRLite, full set held locally | Web PKI largely complete (Mozilla Security Blog, CRLite) | Revocation typically takes effect promptly, with no lookup to the CA |
| Older Firefox versions | live OCSP lookup | depends on the responder | Without a reachable responder, typically only soft-fail remains |
| Clients outside the browser | OCSP or CRL depending on the library | highly variable | This is where the OCSP shutdown bites hardest (Let's Encrypt, "Ending OCSP Support in 2025") |
The numbers behind it are the real reason for the switch: CRLite users download an average of 300 kB of revocation data per day — a 4 MB snapshot every 45 days plus delta updates in between — making them roughly one thousand times more bandwidth-efficient than downloading all CRLs daily (Mozilla Security Blog, CRLite). The side effect is measurable: OCSP lookups blocked the TLS handshake by 100 milliseconds at the median; as CRLite adoption reached 80 percent, median handshake time fell from 56.4 to 39.9 milliseconds (Mozilla Security Blog, CRLite). From Firefox 142, OCSP is disabled entirely for domain-validated certificates (Mozilla Security Blog, CRLite). So hardening and watching your TLS cipher suites pays off twice here.
Between "I revoked the certificate" and "the browser rejects it" there is no automatism in 2026. With Firefox from version 137 the gap is small, because CRLite distributes the complete set (Mozilla Security Blog, CRLite). With Chrome it depends on whether your revocation lands in a CRLSet at all — which applies to roughly one percent of all revocations (Mozilla Security Blog, CRLite). So plan as though revocation alone will not save you.
The revocation reason decides: keyCompromise is no detail
This holds the most practically important lever of the whole topic — and it gets overlooked routinely. Chrome's default behaviour blocks, via CRLSet, revoked CA certificates as well as server certificates whose revocation reason is keyCompromise or privilegeWithdrawn (Chromium Project, Chrome Root Store FAQ). Put differently: the revocation reason co-decides whether a revocation stands any chance of taking effect in the most-used browser.
The catch: revocation reasons are optional, and they are frequently left out. According to Mozilla's analysis, roughly half of all revocations carry no reason code (Mozilla Security Blog, CRLite). Anyone acting fast during a compromise and leaving the reason at its default gives away exactly the property that makes the difference.
- Set
keyCompromise(code 1) whenever the private key may have leaked — after a server breach, an accidentally published key or a compromised backup. This reason andprivilegeWithdrawnare the values relevant to Chrome's CRLSet (Chromium Project, Chrome Root Store FAQ). superseded(code 4) is the right value for harmless cases: the certificate was reissued and the old one is being cleaned up. It correctly signals that no security incident occurred.- No reason given is the default in many tools — and the weakest choice during a real incident, because the revocation then becomes hard to use for browser-side aggregation (Chromium Project, Chrome Root Store FAQ).
- Settle it before the incident: the ACME standard provides for supplying a revocation reason on revoke. Whether your client offers that, and what the parameter is called, belongs in the runbook — not in a search at three in the morning (project experience).
A compromised key gets revoked — without a reason code, because that was the shortest command. The CA publishes the revocation in its CRL on time (CA/Browser Forum, Ballot SC-063), Firefox enforces it through CRLite (Mozilla Security Blog, CRLite), and Chrome leaves it aside, because without keyCompromise no CRLSet entry is typically created (Chromium Project, Chrome Root Store FAQ). The certificate counts as revoked on paper and keeps being accepted across a large part of the market. Anyone automating certificates via ACME should therefore pin the revocation reason into the procedure.
Short lifetimes as the real solution: 200, 100, 47 and 7 days
The CA/Browser Forum drew a strategic conclusion from the weakness of revocation mechanisms: if revocation works poorly at web scale, shorten the time a certificate can do damage at all. Ballot SC-081v3 was adopted in April 2025 and sets a phased schedule that lowers the maximum lifetime from 398 days to 47 days (CA/Browser Forum, Ballot SC-081v3).
| From | Maximum lifetime | Practical consequence |
|---|---|---|
| until 14 Mar 2026 | 398 days | Manual renewal was still manageable |
| 15 Mar 2026 | 200 days | Already in force — roughly two renewals per year |
| 15 Mar 2027 | 100 days | Automation effectively without alternative |
| 15 Mar 2029 | 47 days | Fully automated operation as the norm |
The schedule comes from CA/Browser Forum, Ballot SC-081v3. In parallel, the reuse period for domain control validation drops from 398 days to 10 days by 2029 (CA/Browser Forum, Ballot SC-081v3) — so proving domain control becomes continuous work as well. The 47 days, by the way, are no arbitrary figure: they add up from one maximal month (31 days), half a 30-day month (15 days) and one day of wiggle room (CA/Browser Forum, Ballot SC-081v3). The 200-day limit has applied since 15 March 2026 — what that means day to day is covered in the piece on the 200-day limit and the road to 47 days.
Alongside it sits a second category that sidesteps the revocation problem elegantly: short-lived certificates. For certificates issued from 15 March 2026, a short-lived certificate is defined as one with a validity period of at most seven days (604,800 seconds); previously the bar sat at ten days (CA/Browser Forum, Ballot SC-063). The trick: such certificates need neither CRL distribution points nor OCSP pointers, and they are not subject to any revocation requirement (CA/Browser Forum, Ballot SC-063). The reasoning is plain — a certificate that expires in seven days anyway does not need a revocation that barely reaches the browser.
Short-lived certificates have been generally available since 15 January 2026 and are valid for 160 hours, just over six days (Let's Encrypt, six-day and IP certificates).
They are obtained by selecting the shortlived certificate profile in the ACME client. It is explicitly not a default, and is not planned to become one for now (Let's Encrypt, six-day and IP certificates).
Certificates for IP addresses — IPv4 as well as IPv6 — are available too, and must be short-lived (Let's Encrypt, six-day and IP certificates).
Anyone who has fully automated renewal can usually switch without much effort; without dependable ACME automation the step is risky (Let's Encrypt, six-day and IP certificates).
You could call this approach "revocation by expiry": rather than hoping a revocation reaches the browser, you make sure the window stays small to begin with. The price is a renewal chain that has to run dependably — though its failure is then an operations problem, not a security problem.
OCSP stapling: configurations pointing into the void
OCSP stapling inverts the privacy problem: instead of the browser asking the CA, the server fetches the signed status response itself and delivers it along with the TLS handshake. That was the recommended configuration for years — which is exactly why many server configurations still carry a stapling directive pointing at a responder that no longer exists.
For certificates issued by Let's Encrypt after 7 May 2025, the OCSP URL is missing from the certificate entirely (Let's Encrypt, "Ending OCSP Support in 2025"). A server with stapling enabled then finds no responder left to ask. Usually this is inconsequential, because the configuration tolerates a missing status. But it is needless ballast that produces error messages on restart and generates noise in operations — and noise is why real warnings get missed (project experience).
- Review and remove stapling directives: if the certificate no longer carries an OCSP URL, stapling has nothing left to deliver. The directive can go.
- Remove references to responder files: pre-loaded response files and local caches pointing at a decommissioned responder are stale and belong in the bin.
- Retire OCSP Must-Staple from your inventory: a certificate carrying the Must-Staple extension for which no response exists can actively break connections. Let's Encrypt began rejecting such requests from 30 January 2025 (Let's Encrypt, "Ending OCSP Support in 2025").
- Inventory clients outside the browser: libraries, load balancers, mail servers, mobile apps and payment integrations partly still check via OCSP. Let's Encrypt explicitly notes that websites and their visitors are typically unaffected by the change, while some non-browser software is (Let's Encrypt, "Ending OCSP Support in 2025").
- Document the outcome: after the cleanup, record which revocation path is still relevant for which service — otherwise the dead configuration simply travels along to the next server migration (project experience).
Check whether the certificates you serve still carry an OCSP URL in the AIA extension at all. If it is missing, every stapling configuration on that host is moot. Sensibly, check the chain, the remaining lifetime and the delivered HTTP security headers in the same pass — all of it hangs off the same connection and can be assessed together.
Key compromise in 2026: reissuing beats revoking
When the private key is compromised, the classic answer was: revoke. In 2026 that is only the second step — and not the most effective one. Revocation stays correct and necessary, it is mandatory towards the CA and it creates the CRL entry (CA/Browser Forum, Ballot SC-063). But it reaches the browser only through the aggregates described above, and with Chrome only with a fitting revocation reason (Chromium Project, Chrome Root Store FAQ). Real protection comes from the compromised key material no longer existing on your systems.
- Generate a new key pair — do not reuse the old one. Reissuing a certificate without rotating the key does not solve the problem.
- Issue and roll out the new certificate before revoking. Revoking first and rolling out afterwards risks a window in which nothing valid is served at all.
- Request revocation with reason
keyCompromise— that is the reason able to reach Chrome's CRLSet at all (Chromium Project, Chrome Root Store FAQ). - Remove the old key everywhere: load balancers, backup hosts, container images, CI secrets, CDN termination points. A key still sitting somewhere is a key still being served somewhere.
- Watch the rollout: the incident closes only once every endpoint serves the new certificate. Across several locations and load balancers that is hard to prove without measuring from outside (project experience).
- Check reporting duties: depending on your role and exposure, an incident may need documenting or reporting; in service provider chains especially so — see NIS2 in the supply chain.
"Revoke and hope" was a weak strategy even before 2025 — with responders switched off (Let's Encrypt, "OCSP Service Has Reached End of Life") and CRLSets covering roughly one percent of revocations (Mozilla Security Blog, CRLite), it is more so now. "Reissue, roll out fast, revoke cleanly" moves protection to where you actually control it: your own systems. Revocation stays mandatory — but it is the backstop, not the plan.
What monitoring has to check now
When the revocation mechanism barely bites in the browser, the burden of proof shifts: you have to know what your servers deliver. These are four checks that belong together — and that are sensibly collected in one pass rather than across four separate tools.
Is the full chain delivered, does it match the hostname, and does it come from the CA you expect? An incomplete chain often goes unnoticed in browsers, while other clients trip over it immediately.
With a 200-day maximum since 15 March 2026 and 100 days from 2027 (CA/Browser Forum, Ballot SC-081v3), the question is no longer "will it expire" but "did the automation fire".
Does the server deliver a status response — and if so, a valid one? A stapling configuration pointing at a decommissioned responder should be spotted and dismantled (Let's Encrypt, "OCSP Service Has Reached End of Life").
Protocol versions, cipher suites and the delivered security headers hang off the same connection and can be assessed together.
This is precisely the shift this article describes: away from "is the revocation published" — the CA answers that reliably and to deadline (CA/Browser Forum, Ballot SC-063) — towards "what does my server actually serve". The XICTRAQ security scan checks the TLS configuration including chain, remaining lifetime, stapling status and headers, rather than relying on a mechanism that barely carries in the browser any more. Anomalies travel through alerting and notifications, while plain reachability of the endpoints is covered by uptime monitoring.
- Measure from outside, not from inside: a local call on the host says little about what a load balancer or a CDN node in another region actually delivers (project experience).
- Every endpoint, not just the homepage: API hosts, mail endpoints, redirect domains and status pages have their own certificates and their own renewal chains.
- Think issuance and revocation together: CT logs show what was issued, CRLs show what was revoked. Both belong in the same view.
- Do not forget vulnerabilities around it: the TLS stack is software like any other; which flaws are reported for your components belongs in the same process — see EUVD and CVE feeds 2026.
Keeping revocation under control without relying on it
The 2026 picture fits into three sentences. First: revocation information is published more reliably than before — CRLs are mandatory, with clear deadlines of 24 hours after a revocation and four to seven days for the routine refresh (CA/Browser Forum, Ballot SC-063). Second: the path from revocation into the browser has become markedly more indirect — Chrome covers roughly one percent of revocations via CRLSets, Firefox the complete set via CRLite since version 137 (Mozilla Security Blog, CRLite). Third: the industry's answer is not a better revocation mechanism but shorter lifetimes — 200 days since March 2026 and 47 days from 2029 (CA/Browser Forum, Ballot SC-081v3), plus seven days for short-lived certificates with no revocation requirement at all (CA/Browser Forum, Ballot SC-063).
For operations that means four things: clear out dead OCSP stapling configurations, pin the revocation reason into the incident runbook, move renewal onto automation you would trust at a 100-day lifetime, and measure from outside what your endpoints deliver. If you want to think further ahead: the next big rebuild of the TLS layer is already under way — post-quantum TLS with ML-KEM changes the handshake once more. And if you want to weigh effort against benefit, the scope of each plan is laid out on the pricing overview.
This article draws on: Let's Encrypt — "Ending OCSP Support in 2025" (5 Dec 2024; announcement and shutdown schedule, privacy rationale, notes on non-browser software); Let's Encrypt — "OCSP Service Has Reached End of Life" (6 Aug 2025; shutdown, request volume, move to CRLs); Let's Encrypt — six-day and IP certificates (general availability of short-lived certificates from 15 Jan 2026, shortlived profile, 160-hour validity); CA/Browser Forum — Baseline Requirements, Ballot SC-063 ("Make OCSP Optional, Require CRLs, and Incentivize Automation"; vote July 2023, effective 15 Mar 2024, CRL deadlines, definition of short-lived certificates); CA/Browser Forum — Ballot SC-081v3 ("Introduce Schedule of Reducing Validity and Data Reuse Periods"; 200/100/47-day schedule, DCV reuse); Mozilla Security Blog — CRLite (rollout in Firefox 137, coverage, size and handshake figures, CRLSet comparison); Chromium Project — Chrome Root Store FAQ (CRLSets, no live lookups, relevant revocation reasons, enterprise policies); IETF — RFC 6960 (OCSP) and IETF — RFC 5280 (CRL profile). Supplemented by experience from live operations (project experience).
Frequently asked questions on certificate revocation in 2026
Does the browser even notice when I revoke a certificate?
keyCompromise or privilegeWithdrawn (Chromium Project, Chrome Root Store FAQ). Experience suggests you should not rely on revocation alone, but additionally issue and roll out a new certificate.