How to enable OCSP stapling for faster TLS

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. Note that this only applies when your CA operates OCSP responders: Let's Encrypt retired its responders in 2025 and moved to CRLs, so its certificates cannot be stapled.

Why it matters

If your CA still offers OCSP, stapling spares clients a separate lookup to the CA and keeps revocation data in the handshake. Major browsers no longer query OCSP directly (Chrome uses CRLSets, Firefox uses CRLite), so the gain is mostly for other clients.

How it is exploited

Without stapling, a client that checks OCSP has to query the CA's 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

1. 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.
2. 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.
3. 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.
4. 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

ssl_stapling on; ssl_stapling_verify on;

SSLUseStapling on

A scan shows the fix is in place. To test whether this, or anything around it, can still be exploited, run an AI pentest. Retesting a found issue is free.

References

• RFC 6066 (TLS Extensions)
• RFC 6960 (OCSP)

Related reading

• Background concepts and deeper context
• Fix weak TLS (disable 1.0, 1.1, weak ciphers)
• How to fix SSL/TLS certificate expiry
• How to fix a missing HSTS header
• Run the tls / https check

Frequently asked questions

What is OCSP stapling?

OCSP stapling is a TLS extension where your server fetches a signed revocation status from the certificate authority and attaches (staples) it to the TLS handshake. Clients get a fresh proof of validity without contacting the CA themselves.

How is stapling different from OCSP?

Plain OCSP makes each client that checks revocation query the CA's responder directly, which leaks the client's IP and the hostname they visited and adds a round-trip on every fresh handshake. Stapling moves that lookup to the server, which caches the response and serves it in the handshake, so the client never has to talk to the CA.

Does every CA support stapling?

No. Let's Encrypt, the largest CA, ended OCSP support in 2025 in favor of CRLs, so its certificates cannot be stapled at all. Most commercial CAs still publish OCSP responders, but quality varies. Check whether your certificate contains an OCSP URL (openssl x509 -in cert.pem -noout -ocsp_uri), then test with openssl s_client -status after enabling and watch your server logs for failed fetches.