ASVS 5.0 V12.1.4 asks you to enable proper certificate revocation, for example OCSP stapling, and configure it correctly. It sits at Level 3, the tier for high assurance systems.
With stapling, your server fetches a signed OCSP response from the CA, caches it and sends it during the handshake. Clients learn the certificate is still good without contacting the CA themselves.
Why it matters
If a private key leaks, revoking the certificate is how you shorten the damage window. Revocation only helps if clients can find out. Stapling avoids the privacy leak and latency of each browser calling the CA, and it works when the CA responder is slow.
How to implement it
nginx:
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 1.1.1.1 9.9.9.9 valid=300s;
ssl_trusted_certificate must hold the issuer chain so nginx can verify the response. Your CA must also still offer OCSP for your certificate type, so check before relying on it.
How to test it
openssl s_client -connect example.com:443 -status -servername example.com < /dev/null | grep -A3 "OCSP response"
You want "OCSP Response Status: successful" and a future "Next Update". Run it twice, since some servers fetch the first response lazily.
Common mistakes
- Enabling the directive but leaving the resolver or chain file out, so stapling silently never works.
- Assuming a staple means revocation is enforced. Browsers differ, so plan for short lived certificates and fast key rotation too.
- Never alerting when the cached response expires.
Quick check
What does the server send when stapling works?
A CA signed OCSP response, attached to the TLS handshake, stating the certificate status and its validity window.
