Let's Encrypt killed OCSP — now what?

Let's Encrypt announced in 2024 that they would stop providing OCSP responders, and finished the migration in 2025. As of April 2026, every fresh LE certificate ships without an Authority Information Access OCSP URI. The header you've been adding to nginx for years — ssl_stapling on; ssl_stapling_verify on; — is now a silent no-op for LE-protected sites.

And yet, most scanners still flag tls.ocsp_stapling_missing as a finding. Their checkers haven't caught up. We've adjusted ours to look at the AIA extension before flagging anything; here's the precise change and why it matters.

What is OCSP stapling, again?

Online Certificate Status Protocol (OCSP) was designed to fix CRLs. Instead of every TLS client downloading multi-megabyte revocation lists, the client could ask the CA "is this specific cert still valid?" via a small HTTPS request. OCSP stapling went further: the SERVER pre-fetches the OCSP response from the CA and includes it in the TLS handshake. The client gets a fresh validity proof for free, without any extra round trips.

Stapling is great. The reason LE killed it is that OCSP itself turned out to be a privacy and reliability nightmare:

• OCSP responders are a CA-level operational burden (LE was answering ~10 billion queries per day).
• Privacy: every OCSP query reveals a client's browsing history to the CA.
• Reliability: OCSP responders going down causes "soft-fail" states that defeat the purpose.
• Modern alternatives (CRLite, short-lived certs, MUST-STAPLE extension) cover the use case better.

LE's published successor strategy is short-lived certs (90 days currently, 7 days proposed for 2026+). Certs short enough that revocation becomes near-irrelevant — by the time the bad guy notices their stolen key works, it's expired.

The X.509 fingerprint of an OCSP-less cert

Every X.509 v3 cert can have an Authority Information Access (AIA) extension. AIA fields list URIs for two purposes:

• caIssuers — where to download the issuing CA cert (always present)
• OCSP — where to query OCSP (now absent on LE certs)

You can verify this on any cert with one openssl command:

$ openssl x509 -noout -text -in /etc/letsencrypt/live/example.com/cert.pem | grep -A 3 "Authority Information Access"
            Authority Information Access:
                CA Issuers - URI:http://e6.i.lencr.org/

# (no "OCSP - URI:" line — that's the new normal for LE)

Compare to a DigiCert cert from the same period:

            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt

DigiCert still publishes OCSP. Sectigo too. GoDaddy too. So scanners that flag "missing OCSP staple" are correct for those certs but wrong for LE. The fix is to gate the finding on AIA OCSP being present in the first place.

Our checker change

Pre-2025, our tls_extended checker emitted tls.ocsp_stapling_missing whenever the server failed to staple. That was correct then. As of UnveilScan v1.108 we gate on:

// Don't flag stapling missing if the cert has no OCSP responder URL —
// the server can't staple something the cert doesn't reference.
if len(leaf.OCSPServer) == 0 {
    return  // no finding emitted
}
if state.OCSPResponse == nil {
    // Real finding: cert says "OCSP at X" but server didn't fetch + include
    emitFinding("tls.ocsp_stapling_missing", ...)
}

Same change for SCTs (Signed Certificate Timestamps). LE embeds SCTs as an X.509 v3 extension (OID 1.3.6.1.4.1.11129.2.4.2) instead of delivering them in the TLS extension. Our checker now reads both channels before flagging tls.sct_missing. The relevant Go code peeks at leaf.Extensions for that OID.

What this means for you

If you run an LE-protected site, you can:

• Drop ssl_stapling on; from your nginx config — it was a no-op anyway and the warning it produces in error.log is just noise.
• Stop chasing the "OCSP stapling missing" finding from scanners that haven't updated. UnveilScan won't show it.
• Keep ssl_stapling on; if you also have a non-LE cert in the chain (DigiCert, Sectigo, etc.) — those still benefit.
• Don't worry about CRLite. Modern browsers handle revocation through CRLite or proprietary push mechanisms; you don't need to configure anything server-side.

The bigger picture

OCSP shutting down is the most visible part of a deeper trend: short-lived certs killing revocation. Apple, Google and Mozilla have all signed on to a 47-day max cert lifetime by 2029. At those timescales the entire revocation tower (CRLs, OCSP, OCSP stapling, MUST-STAPLE) becomes architectural overhead for solving a problem that goes away naturally.

Migrate your ACME automation to handle 7-day renewals (LE is already running this in beta) and the only "PKI" you'll ever think about is the cert chain itself.