OCSP Stapling

What is OCSP stapling?

OCSP stapling is a TLS optimization that fixes the performance and privacy problems of checking whether a certificate has been revoked. Certificates can be revoked before they expire (if the private key is compromised or the cert was mis-issued), so clients need a way to check “is this certificate still valid, or has it been revoked?” The Online Certificate Status Protocol (OCSP) answers that — but the traditional approach, where the client contacts the Certificate Authority’s OCSP server during the handshake, is slow and leaks privacy. OCSP stapling flips it: the web server periodically fetches a fresh, CA-signed proof of its own certificate’s good standing and “staples” it directly into the TLS handshake, so the client gets the revocation status without contacting the CA at all.

The problems it solves — the client-side OCSP flaws

To see why stapling matters, consider what plain client-side OCSP does wrong. When the client checks revocation itself, every TLS connection triggers an extra request to the CA’s OCSP responder, which causes three problems. Latency: an additional network round-trip to a third party (the CA) added to the handshake, slowing down connection setup — and if the CA’s OCSP server is slow, every connection to your site is slow. Privacy leak: the client is telling the CA which sites it’s visiting (the CA sees “this user is checking the cert for bank.com”), exposing users’ browsing to the certificate authority — a real privacy concern. Reliability / soft-fail: if the CA’s OCSP responder is unreachable, browsers historically “soft-fail” — they proceed without checking rather than blocking the connection, because hard-failing would make sites unreachable whenever a CA had an outage. But soft-fail guts the security value: an attacker who can block the OCSP check simply prevents revocation from being noticed. OCSP stapling addresses all three: the server fetches the signed OCSP response ahead of time (on its own schedule, cached) and includes (“staples”) it in the handshake, so there’s no client-to-CA round-trip (fast), the CA doesn’t learn who’s visiting (private — only the server talks to the CA), and the status is reliably present in the handshake. The stapled response is CA-signed and time-stamped, so the client can trust it wasn’t forged by the server.

The realities and the broader revocation picture

OCSP stapling is a clear improvement and is widely recommended and supported, but there are practical points. The server must be configured to fetch and cache the OCSP response (and refresh it before it expires) — a misconfigured server that fails to staple falls back to the client checking (or not), and a server stapling a stale/expired response can cause errors. OCSP Must-Staple is a stronger option — a certificate flag that requires a valid stapled response, closing the soft-fail hole entirely (the client hard-fails if no valid staple is present), but it demands rock-solid server stapling or the site breaks, so it’s used cautiously. The bigger context worth knowing is that the whole OCSP mechanism is being reconsidered industry-wide: OCSP’s privacy and operational problems led some (notably Let’s Encrypt, and browser vendors) to move away from OCSP toward alternatives — browsers increasingly rely on pushed revocation lists (Mozilla’s CRLite, Chrome’s CRLSets) that bundle revocation data and distribute it to clients directly, avoiding per-connection checks entirely, and Let’s Encrypt announced it is ending OCSP support in favor of CRLs for privacy and cost reasons. So OCSP stapling is a solid current-practice optimization where OCSP is used, but the industry direction is toward client-side aggregated revocation data rather than per-handshake OCSP at all. The recurring mistakes: not enabling stapling (leaving clients to the slow, privacy-leaking, soft-failing client-side check), stapling stale/expired responses (causing handshake errors), and enabling Must-Staple without reliable stapling infrastructure (breaking the site on any stapling hiccup).

What people get wrong

• Not enabling stapling — without it, clients do the slow, privacy-leaking client-side OCSP check that soft-fails anyway; stapling makes revocation checking fast, private, and reliable.
• Stapling stale responses: a server that fails to refresh the OCSP response before it expires staples an invalid one, causing handshake errors — the fetch-and-cache must stay current.
• Must-Staple without solid infrastructure — requiring a valid staple hard-fails the connection if stapling ever hiccups, so it demands reliable server configuration; and note the industry is shifting toward pushed CRLs over OCSP entirely.

Primary source: RFC 6066 / TLS Certificate Status Request (OCSP stapling)