OpenSSL 3.0 client behind nginx reverse proxy: stale OCSP responses after responder URL change

Answer to the three questions

1. OpenSSL 3.0 does **not** automatically re‑validate a stapled OCSP response when a session is resumed. During a session‑resumption handshake the client re‑uses the stapled response that was cached from the original handshake, even if it is older than the new responder’s validity window.
2. Yes. The client can bound the age of cached OCSP responses by configuring SSL_CTX_set_timeout() to a short value and by using a cache mode that respects that timeout. After changing the responder URL you can purge the client cache with SSL_CTX_flush_sessions() without disabling caching.
3. The server’s stapling cache is the authoritative source for freshness. The client should treat the stapled response as valid only if its thisUpdate and nextUpdate fields fall within the desired window; otherwise it must either force a full handshake or perform a direct OCSP query.

Why stale responses can persist

The stapling cache lives on the server side. Nginx keeps a per‑upstream cache of stapled responses and serves the same response to every client that performs a session‑resume, regardless of whether the underlying responder URL has changed. The client’s own cache only records the stapled response once; it does not trigger a new stapling request on resume.

Practical steps to enforce a freshness window

1. Configure nginx to respect a short stapling cache timeout. Add or adjust ssl_stapling_response_cache and ssl_stapling_cache_size to a small value (e.g., 5 s). This forces nginx to fetch a fresh response from the new responder more frequently.
2. Set the client timeout. In your OpenSSL 3.0 client code:

   SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
   SSL_CTX_set_cache_mode(ctx, SSL_CACHE_CLIENT);  /* use client‑side cache */
   SSL_CTX_set_timeout(ctx, 60);   /* 60‑second freshness window */
   

3. Flush the client cache after the responder migration. Call:

   SSL_CTX_flush_sessions(ctx, 0);   /* purge all cached sessions */
   

   This forces the next connection to perform a full handshake and fetch a fresh stapled response.
4. Validate the stapled response. After each handshake, inspect the OCSP response’s thisUpdate and nextUpdate fields (via SSL_get0_ocsp_response()) and compare them to the current time. If the response is outside your window, reject the handshake or trigger a direct OCSP query.

What to check next?

To fine‑tune the policy, we need to know the current ssl_stapling_cache_size and ssl_stapling_response_cache values in nginx. If these are set to a large value, stale stapled responses may linger longer than desired.