SEC_ERROR_OCSP_OLD_RESPONSE high
SEC_ERROR_OCSP_OLD_RESPONSE in Firefox
Firefox rejected a stapled OCSP response whose update window has already passed, so the cert's revocation status reads as stale.
What you see
Warning: Potential Security Risk Ahead The OCSP response is not yet valid (contains a date in the future). Error code: SEC_ERROR_OCSP_OLD_RESPONSE
What’s actually happening
Firefox blocks the site while Chrome and Safari load it fine, which is the giveaway that this is OCSP stapling and not the cert itself. The server stapled an OCSP response during the handshake, but its nextUpdate timestamp is in the past (or thisUpdate is too old), so Firefox decides it can't trust a status that stale and refuses. The cert is usually valid and unrevoked; the staple is just rotten.
Common causes
- The server cached an OCSP response and never refreshed it past its nextUpdate window — the classic nginx ssl_stapling bug where the staple isn't renewed until a request triggers it
- OCSP responses are short-lived (often a 24h thisUpdate validity, or the thisUpdate-to-nextUpdate interval), and the refresh cron/worker stopped running
- The server can't reach the CA's OCSP responder (egress firewall, DNS), so it keeps serving the last response it got until it goes stale
- Client clock is wrong — a machine running fast or with a bad timezone can read a fresh response as already expired
- A reverse proxy or LB is caching the stapled response longer than its validity
How to fix it
- Check the client clock firstIf it's one user, fix their system time and timezone (enable network time sync). A skewed clock makes every staple look stale, and it's a one-line fix before you go digging on the server.
- Inspect what the server is actually staplingopenssl s_client -connect host:443 -status -servername host 2>/dev/null | openssl ocsp -respin /dev/stdin -text -noverify (or read the 'OCSP Response Data' block from s_client -status). Look at thisUpdate/nextUpdate. If nextUpdate is in the past, the staple is the problem, full stop.
- Force the server to refresh its OCSP cacheOn nginx, reload after confirming ssl_stapling on; ssl_stapling_verify on; and a resolver directive are set; nginx fetches lazily, so the first hit after reload may still serve stale — hit it twice. Better: prefetch the response to a file and point ssl_stapling_file at it via a cron job that renews well before nextUpdate.
- Confirm the server can reach the OCSP responderPull the OCSP URL from the cert (openssl x509 -in cert.pem -noout -ocsp_uri) and curl it from the server itself. If outbound to that host is blocked, open it — without responder access the server can never get a fresh staple.
- If you can't fix stapling fast, disable itTurning ssl_stapling off stops Firefox from receiving a stale staple, so it falls back to its own revocation check and the site loads. Treat this as a stopgap, then fix the refresh job and turn stapling back on.
Stop it recurring
Run an OCSP prefetch job that renews the stapled response on a schedule comfortably shorter than nextUpdate, and monitor the staple's remaining validity.
Related errors