OCSP stapling in 2026: what changed and what to do now

Most OCSP stapling tutorials still open with the same pitch: fetch the revocation status yourself, staple it into the handshake, save the browser a round trip. That advice was accurate for years. It is now describing a mechanism that the browsers reading your staple mostly stopped relying on, and that the internet's largest certificate authority stopped supporting at the source entirely.

What actually changed

Let's Encrypt stated the removal plainly: certificates it issues no longer carry an OCSP responder URL at all, and the service that used to answer OCSP queries for its certificates has been shut down. Let's Encrypt's own end-of-life announcement confirms the date and the reasoning: OCSP requires the CA to see which certificate a specific visitor is checking, in real time, which is a real privacy leak the CA itself has to operate, and running that infrastructure reliably at Let's Encrypt's scale was a significant ongoing cost for a mechanism the browsers were already moving away from.

The privacy concern is concrete, not abstract: every OCSP lookup tells the CA the exact certificate a specific visitor, at a specific IP address, is checking at a specific moment, which for a CA operating at Let's Encrypt's scale means visibility into a meaningful slice of web browsing activity across the internet, tied to nothing more than running the revocation check the browser used to depend on. Removing the OCSP responder removes that visibility entirely, at the cost of the browser needing another way to check revocation, which CRLSets and CRLite both exist to provide.

Why the browsers moved first

A live, per-connection OCSP fetch has a real cost: if the OCSP responder is slow or unreachable, the browser either blocks the page load waiting for it, or silently ignores the check and connects anyway (soft-fail), which defeats the point of checking at all. Both major engines solved this the same way in spirit, by moving revocation data off the live connection path entirely, and differently in mechanism.

Chrome uses CRLSets, a compact, Chrome-curated snapshot of revocations pushed to the browser ahead of time, covering the revocations Google considers most consequential rather than every revocation industry-wide. Firefox's newer CRLite takes a broader approach: it compresses the full set of WebPKI revocations into a dataset small enough to update continuously, roughly 300KB per day, and reached production in Firefox 142. Neither approach asks the browser to contact anyone during the handshake to check a single certificate's status, which is the actual point: the trade a decade of OCSP tuning was chasing, checking revocation without slowing down or compromising every connection, turned out to be solved by not checking live at all, and pre-distributing the answer instead.

What this actually means for a server operator

• Stapling a Let's Encrypt certificate issued after mid-2025 does nothing: there is no OCSP URL in the certificate for the server to query in the first place, so an nginx or Apache config still fetching and stapling will have nothing to staple
• OCSP Must-Staple on a Let's Encrypt certificate is now a real risk, not a hardening measure: Must-Staple tells a strict client to hard-fail if no staple is present; combined with a CA that no longer issues an OCSP URL to staple, this can break connections for clients that still enforce it
• Other CAs still issuing OCSP URLs are a different story: stapling still has a real purpose there, this shift is specific to Let's Encrypt's own infrastructure decision, not an industry-wide OCSP shutdown
• Legacy config auditing is the actual task now: search existing nginx/Apache configs for stapling directives and Must-Staple flags tied to Let's Encrypt certificates specifically, and remove what no longer does anything rather than leaving dead configuration in place. In practice that means nginx's ssl_stapling, ssl_stapling_verify, and any resolver line kept only for stapling, or Apache's SSLUseStapling and SSLStaplingCache
• A mixed certificate fleet needs per-CA handling, not a blanket policy: a server serving certificates from multiple CAs may have some with live OCSP URLs and some without, so an automation script that assumes uniform OCSP behavior across every certificate on the fleet will get some of them wrong

Checking what a live certificate actually carries

A quick way to see whether a given certificate still has an OCSP responder URL at all:

openssl x509 -in cert.pem -noout -ocsp_uri

An empty result means there is nothing to staple, regardless of what the web server config says. This is worth checking directly rather than assuming based on the issuing CA, since certificates issued before the mid-2025 cutoff may still carry an OCSP URL even from a CA that has since stopped issuing new ones.

This is not "OCSP is dead"

CRLSets and CRLite replace OCSP for the specific case of a browser checking a public web certificate during a TLS handshake. OCSP itself is still used elsewhere, code-signing validation, some enterprise and internal PKI setups, and CAs other than Let's Encrypt still issue and answer OCSP queries. The accurate framing is narrower: for a public website's certificate, issued by Let's Encrypt, checked by a mainstream browser, the live OCSP round trip that stapling used to save is a round trip that mostly does not happen anymore, on either side.

The CRLSets coverage gap is a real, documented one, not a rounding error: Google curates it for the revocations it judges most consequential (key compromise, CA mis-issuance), so a certificate revoked for a routine reason may not make the list, and Chrome won't know it was revoked. In practice this matters most if revocation checking is your last line of defense; catching a compromise or misconfiguration through your own certificate monitoring before revocation is even necessary does more than any revocation-checking mechanism ever will.

WebPixie's SSL monitoring surfaces the OCSP and CRL endpoints it finds on every certificate during its daily check, and flags a certificate with no published OCSP endpoint as worth attention. That surfaced data is exactly what answers the practical question here: whether a specific certificate still has anything for a stapling config to work with, without needing to check manually.