What it is
OCSP stapling lets your server fetch a signed revocation status from the CA and attach it to the TLS handshake. The client gets a fresh proof that the certificate is still valid without contacting the CA itself.
Why it matters
Without stapling, clients either skip revocation checks or leak browsing data to the CA on every connection. Stapling closes that gap, speeds up TLS, and keeps the site reachable when the CA's OCSP responder is slow or down.
How it is exploited
Without stapling, the client has to query the CA's OCSP responder directly to learn whether a certificate is revoked. When the responder is unreachable or slow, most browsers soft-fail the check and accept the certificate anyway, so a revoked cert held by an attacker keeps working in practice. Those direct OCSP lookups also leak the client's IP and the hostname they visited to the CA on every fresh handshake.
How to fix it
- Confirm the certificate chain is complete. Stapling needs the full intermediate chain on disk so the server can fetch and verify OCSP. Concatenate the issuer chain into your certificate file or point your config at the bundle your CA provides.
- Turn stapling on in the web server. Enable the stapling directives in Nginx or Apache and point them at a resolver that can reach the CA. Reload the server and watch the error log for the first successful fetch.
- Cache responses and set a timeout. Configure a response cache so the server reuses a valid OCSP response until it nears expiry. Set a sensible network timeout so a slow CA does not stall handshakes.
- Verify with a TLS probe. Run Barrion's OCSP stapling check or use openssl s_client -status against your hostname and confirm the OCSP response section is present and good. Re-test after certificate renewal.
Examples by platform
Nginx
ssl_stapling on; ssl_stapling_verify on;Apache
SSLUseStapling on