<b>Why isn't OCSP stapling enabled by default, given that everyone agrees it's better?</b>

<b>Why isn't OCSP stapling enabled by default, given that everyone agrees it's better?</b>

OCSP stapling (the certificate_status TLS extension, RFC 6066 §8) has the server fetch a CA-signed OCSP response and attach it to the handshake. It removes the client's privacy-leaking round trip to the responder and fixes much of OCSP's latency. So why is plain, non-stapled OCSP still common?

The answer is operational fragility in the fetch path. The server must periodically pull a fresh response from the CA's responder and cache it. Naive implementations — including older Apache and nginx configurations — fetched lazily, on the first client request after cache expiry. That request blocked while the server contacted the responder; if the responder was slow or down, the server either stalled the handshake or stapled nothing. A failed staple plus a Must-Staple certificate (RFC 7633) produces a hard-fail: the site goes dark.

This created a perverse incentive. Stapling done badly can be less reliable than no stapling, because it couples your uptime to the CA responder's uptime. Robust stapling requires a proactive, out-of-band refresh daemon (e.g. nginx's ssl_stapling with prefetch, or a sidecar that pre-fetches and validates before serving), decoupling the staple from the request path.

Evidence vs. speculation: the nginx "first request blocks" behavior was a documented, widely-reported pitfall; modern best practice is a separate prefetching process, not the web server's built-in lazy fetch.

<b>Further reading:</b> RFC 6066 §8; RFC 6961 (multi-staple); RFC 7633 (Must-Staple).

<b>Bottom line:</b> Stapling is strictly better only when the OCSP fetch is proactive and decoupled from client requests; done lazily it can tie your availability to the CA's responder, which is why cautious operators leave it off.