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

Integration boundary

We run an OpenSSL 3.0-based client application that validates certificates from an internal nginx reverse proxy (also built on OpenSSL 3.0) with OCSP stapling enabled. The OCSP responder URL in our CA-issued certificates recently changed, and we want to understand how caching on each side affects the freshness of the status information the client ultimately sees.

Goal and constraints

The goal is to guarantee that the client never accepts an OCSP response older than a defined freshness window after the responder migration, without disabling OCSP entirely. Our uncertainty is where staleness can persist: the client-side session/OCSP cache controlled by SSL_CTX_set_cache_mode() and SSL_CTX_set_timeout(), or the stapled response nginx caches and serves to every connecting client. We currently use SSL_CACHE_DEFAULT and a long session timeout, and it is unclear whether session resumption can bypass fresh status checks altogether.

Questions

1. Does OpenSSL 3.0 revalidate stapled OCSP responses on session resumption, or can a resumed session carry stale status from the original handshake?
2. Is there a supported way to bound or flush the client-side OCSP/session cache without switching to SSL_CACHE_OFF and paying a full handshake every connection?
3. Which side (nginx staple cache vs. client cache) should be treated as authoritative for enforcing the freshness window?