OCSP Stapling (TLS Certificate Status Request)

OCSP stapling is a TLS mechanism in which the server, not the browser, fetches a signed OCSP response from the CA and sends it to clients during the TLS handshake. The client requests it with the status_request extension defined in RFC 6066; in TLS 1.3 the response travels inside the Certificate message. Because the response is signed by the CA and expires, the server cannot forge a "good" status or replay one indefinitely.

Why it matters

Stapling removes the privacy leak and extra round trip of client-side OCSP: the CA sees one query per server every few hours rather than one per visitor. It only helps when the certificate actually contains an OCSP URL. Since CA/Browser Forum Ballot SC-063 made OCSP optional, some CAs publish only CRLs, and Let's Encrypt removed OCSP URLs from new certificates on 2025-05-07, so for those certificates there is nothing to staple and the server simply skips it.

Example

nginx configuration:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

Check whether a staple is sent:

openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null | grep -i "ocsp response"

OCSP Response Status: successful means a staple was sent; OCSP response: no response sent means none was. nginx fetches responses lazily, so the first connection after a reload may arrive without a staple.

Common misconceptions

• Stapling makes revocation checks hard-fail. Without Must-Staple, a client that receives no staple usually just continues; stapling improves speed and privacy, not enforcement.
• Enabling stapling breaks sites whose certificate has no OCSP URL. nginx only logs a warning and completes the handshake without a staple.
• ssl_stapling on is all you need. nginx also needs a DNS resolver to reach the responder and the issuer certificate to verify the responses it fetches.