What is OCSP stapling?

OCSP stapling lets a server hand out proof that its certificate is not revoked, instead of making every visitor ask the certificate authority. Plain OCSP had the browser query the CA’s responder during the handshake, which was slow, unreliable, and told the CA which sites every user visited. With stapling, the server fetches a signed, time-stamped OCSP response itself, caches it, and attaches ("staples") it to the TLS handshake. Visitors get fresh revocation status with no extra connection and no privacy leak.

The mechanism rides the TLS status_request extension: the client asks for a stapled response, and the server includes one signed by the CA, typically valid for a few days and refreshed in the background. Because the response is CA-signed, the server cannot forge it; the worst a compromised server can do is staple the most recent "good" answer it obtained.

Stapling never became universal, and its weaknesses were structural. A server that stopped refreshing could serve a stale response until it expired, and most browsers treated a missing staple as acceptable rather than fatal, so the security value was soft. The strict version — the OCSP Must-Staple certificate extension — saw so little real deployment that CAs began dropping support for it.

The bigger shift is that OCSP itself is being retired. Let's Encrypt ended its OCSP service in 2025 and moved revocation to CRLs, and browsers already check revocation through aggregated CRL summaries pushed with browser updates rather than live OCSP queries. For an operator in practice: stapling only matters if your CA still runs OCSP, and the durable fixes for revocation remain short certificate lifetimes and fast reissuance rather than any real-time lookup.