You set `ssl_stapling on;` on an nginx server, but `openssl s_client -status` reports no OCSP response. What else does nginx need before it can staple, and why is the first handshake after a reload usually unstapled?
answer
- nginx becomes an HTTP client here
- name lookups need the resolver directive
- verification needs the root, the served chain does not
- the fetch is lazy, not at startup
- fails open unless Must-Staple
basics
~20 snginx needs a resolver to look up the OCSP responder named in the certificate, and ssl_trusted_certificate when ssl_stapling_verify is on. It fetches the response lazily on demand, so the earliest handshakes after a reload carry no staple.
solid answer
~40 s`ssl_stapling on;` only expresses intent. nginx must fetch the OCSP response itself over HTTP from the responder URL in the certificate's AIA extension, which means resolving a hostname — and nginx does not use the system resolver for its own outbound lookups, so without a `resolver` directive it logs that no resolver is defined and silently serves handshakes unstapled. If you also set `ssl_stapling_verify on;`, nginx validates the responder's signature and needs `ssl_trusted_certificate` pointing at a file containing the issuer chain **and** the root, which is not the file you serve as `ssl_certificate`. The fetch is lazy: nginx requests the response after client traffic arrives, so a single `openssl s_client -status` immediately after a reload frequently shows nothing. Test twice, a moment apart, before concluding it is broken.
code
bash · 2 linesopenssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null | grep -A 5 'OCSP Response Status'
grep -i 'ocsp\|resolver' /var/log/nginx/error.log | tailgo deeper
Know that stapling means the server attaches a fresh revocation proof to the handshake so the client does not have to contact the CA, and that ssl_stapling on; alone is not enough.
Explain the mechanics: nginx acts as an HTTP client against the AIA responder URL, needs the resolver directive for name lookup, and needs ssl_trusted_certificate including the root when verification is enabled.
Show the diagnosis and the failure semantics — read the error log, re-test after warm-up because the fetch is lazy, and recognise that stapling fails open except under OCSP Must-Staple, where it becomes an outage.
Decide whether stapling is worth its operational surface at all, given shorter certificate lifetimes and shifting CA revocation infrastructure, and never take on Must-Staple without monitoring that would catch a silent staple loss.
## What stapling is doing at the nginx layer A client that wants to know whether a certificate has been revoked can ask the CA's OCSP responder itself — costing a DNS lookup and an HTTP request in the middle of page load, leaking which site is being visited to the CA, and failing awkwardly when the responder is slow. Stapling moves that work to the server: nginx fetches a signed, time-stamped OCSP response for its own certificate and attaches it to the handshake. The client gets a fresh revocation statement for free. The nginx-specific part — and the part interviews probe — is that nginx is now an HTTP *client*, with everything that entails. ## The three things `ssl_stapling on` does not provide **A resolver.** The responder URL lives in the certificate's AIA extension as a hostname, and nginx resolves names for its own outbound requests using the `resolver` directive rather than `/etc/resolv.conf`. With no `resolver`, the error log carries a message about no resolver being defined to resolve that host, and stapling never happens. This is the most common cause by a wide margin, and it is invisible unless you read the error log. ```nginx resolver 127.0.0.53 valid=300s; resolver_timeout 5s; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; ``` **Trust material for verification.** `ssl_stapling_verify on;` makes nginx check the responder's signature before serving the response, which requires trusting the issuer that signed it. `ssl_trusted_certificate` supplies that: the intermediate chain plus the root. Note the asymmetry with the served chain — you deliberately exclude the root from `ssl_certificate` and deliberately include it here. Certificates named by `ssl_trusted_certificate` are used for verification only and are never sent to clients. **Outbound network access.** Egress-restricted hosts frequently cannot reach the responder at all. The symptom is identical to a missing resolver: no staple, a line in the error log, and handshakes that still succeed. ## Why the first handshake is unstapled nginx does not prefetch the OCSP response at startup. It initiates the fetch in response to traffic, and until the response arrives and is cached it serves handshakes without a staple, refreshing it in the background thereafter. So the classic test — reload nginx, run `openssl s_client -status`, see nothing, conclude stapling is broken — produces a false negative. Run the check again a few seconds later. This laziness is also why stapling is best verified by continuous monitoring rather than by a one-shot check during a deploy. ## Verifying ```bash openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null \ | grep -A 5 'OCSP Response Status' ``` A working staple shows `OCSP Response Status: successful` with `Cert Status: good` and This Update / Next Update timestamps. "OCSP response: no response sent" means nginx has nothing cached — go and read the error log. ## The failure mode that actually hurts Stapling normally fails *open*: no staple, handshake still succeeds, nobody notices. The dangerous variant is a certificate carrying the OCSP Must-Staple extension. That is a promise: a compliant client receiving no staple must refuse the connection. Combine Must-Staple with a missing resolver or blocked egress and you have a total outage that no amount of certificate renewal fixes. Do not request Must-Staple certificates unless stapling is monitored end to end. For environments where nginx cannot reach the responder, `ssl_stapling_file` lets you hand nginx a pre-fetched DER-encoded OCSP response produced out of band — you then own the refresh schedule, because a stale response is worse than none. ## Where this sits in the wider revocation story Stapling is one lever among several, and the ecosystem has been moving: shorter certificate lifetimes reduce the value of revocation checking, and some CAs have scaled back OCSP infrastructure. Treat stapling as a latency and privacy optimisation you configure correctly if you configure it at all, not as the thing standing between you and a compromised key.
- Why does ssl_trusted_certificate need the root when ssl_certificate deliberately omits it?They serve opposite directions. `ssl_certificate` is what nginx sends to clients, and clients already hold the root, so including it wastes handshake bytes. `ssl_trusted_certificate` is what nginx uses to verify the OCSP responder's signature, and that path must terminate in a root nginx itself trusts. Its contents are never transmitted.
- What happens if stapling silently stops working on a certificate carrying the OCSP Must-Staple extension?Compliant clients refuse the connection outright, turning a normally invisible misconfiguration into a full outage. Must-Staple converts stapling from an optimisation into a hard dependency on nginx's ability to reach the responder, so only enable it alongside monitoring that alerts on a missing staple.
- How would you monitor that stapling is still working in production?Probe the endpoint periodically with `openssl s_client -status`, assert that the response status is successful and that Next Update is comfortably in the future, and alert when either fails. A one-off check at deploy time is unreliable because nginx fetches lazily and a cached response can go stale later.
saying these in an interview costs you the question
- nginx resolves the OCSP responder through /etc/resolv.conf
- Stapling works as soon as ssl_stapling on is set
- ssl_trusted_certificate is the file clients receive
- A missing staple always breaks the handshake
- Stapling replaces certificate renewal as revocation protection