OCSP stapling explained, and how to verify it
OCSP stapling moves the revocation check for a certificate off the user's browser and onto your server, which fixes the two things wrong with plain OCSP at once: it stops leaking your visitors' browsing to a third party, and it removes a slow extra connection from every handshake. Understanding why requires seeing what plain OCSP does first.
What OCSP is for
A certificate can be revoked before it expires, for example if its private key leaks. Clients need a way to learn that a certificate is no longer valid. The Online Certificate Status Protocol is one answer: the certificate carries the URL of an OCSP responder run by the issuing authority, and a client asks that responder whether this specific certificate is still good, revoked, or unknown.
The problems with plain OCSP
Making the client do the asking causes three issues.
| Problem | Why it happens |
|---|---|
| Privacy leak | the client tells the CA which site it is visiting, by certificate serial |
| Latency | an extra network round trip to the responder during connection setup |
| Soft fail | if the responder is slow or down, clients usually proceed anyway |
The privacy leak is the sharpest. Every time a user visits your site, their browser may contact your certificate authority and reveal, by serial number, which site they are connecting to. The authority sees a stream of who is visiting which sites. The latency is felt on every fresh connection. And because browsers soft fail when the responder is unreachable, an attacker who can block the OCSP request can often make the client accept a revoked certificate anyway, which undermines the whole point.
How stapling fixes it
With stapling, your own server does the OCSP query ahead of time, on a schedule, not per visitor. The authority signs a timestamped status response, and your server caches it and attaches, or staples, that signed response to the TLS handshake. The client receives the certificate and its proof of good standing together, in one exchange.
The client never contacts the authority, so there is no privacy leak and no extra round trip. The response is signed by the authority and timestamped, so your server cannot forge a "good" status for a revoked certificate. One query by your server every few hours replaces millions of queries by individual visitors, which is also far easier on the authority.
What must-staple adds
Stapling alone has a gap: a client cannot tell the difference between a server that chose not to staple and one that was prevented from stapling by an attacker stripping the response. So it still soft fails. The status_request extension, commonly called must-staple, is a flag baked into the certificate itself that says: this certificate must always arrive with a stapled OCSP response. A client seeing that flag will refuse the connection if no valid staple is present, turning a soft fail into a hard fail and closing the stripping attack. The cost is operational strictness. If your stapling breaks, a must-staple certificate takes the site down rather than degrading quietly, so enable it only once stapling is reliably working.
Verifying it is on
From the command line, request the status and look for the stapled response:
openssl s_client -connect example.com:443 -status < /dev/null 2>&1 | grep -A2 "OCSP Response Status"
A working staple prints OCSP Response Status: successful followed by the status good. If you see OCSP response: no response sent, stapling is not active, and the client would fall back to querying the authority itself. Browsers do not surface this directly, so a tool or openssl is the practical way to confirm it.
Quick checklist
- Enable stapling at the server, so visitors never query the authority.
- Confirm the staple is actually present, not just configured.
- Add must-staple only after stapling has proven stable, because it hard fails.
To check a host's certificate revocation status and whether a valid OCSP response is available, the OCSP Checker performs the query for you.