What is OCSP stapling, and why should I turn it on?

What is OCSP stapling, and why should I turn it on?

If checking revocation leaks every visitor's browsing to the CA and slows the handshake, can the server do the check on the visitor's behalf? Yes — that is precisely what OCSP stapling solves.

Normally, to learn whether a certificate is revoked, each visitor's browser queries the CA's OCSP (Online Certificate Status Protocol) responder directly. Two costs: latency (an extra round trip to a third party mid-handshake) and privacy leakage (the CA sees the IP and SNI of everyone visiting your site).

Stapling (TLS Certificate Status Request extension, RFC 6066) inverts this. Your server periodically fetches a signed, time-stamped OCSP response from the CA and "staples" it into the TLS handshake. The visitor gets fresh revocation proof without ever contacting the CA. The proof is signed by the CA, so a malicious server can't forge a "good" status.

One caveat beginners miss: by default stapling still fails open — a server that omits the staple just looks like a server that doesn't support it. The fix is the status_request Must-Staple flag baked into the certificate (RFC 7633), which makes clients require a staple. Adoption is low and being deprecated alongside OCSP itself, so weigh it carefully.

Further reading: RFC 6066 (status_request); RFC 7633 (Must-Staple).

Bottom line: stapling moves the revocation check to your server — faster handshakes, no visitor privacy leak. Enable it; treat Must-Staple as advanced and increasingly historical.