What OCSP Response Signing Actually Does
OCSP stapling is standard practice now. But the signing part is where most people get tripped up. When a certificate authority's OCSP responder signs responses with its own key rather than the end-entity certificate key, you need to make sure that signature chain validates correctly. Most templates online assume you're working from a clean CA environment. That's not always your reality. I spent three weeks debugging a situation where our load balancer accepted OCSP responses one day and rejected them the next. The root cause was a mismatch between the signing certificate's validity period and what the responder was actually producing. Once I figured out the responder was using a backup signing key that had expired, everything clicked into place. That experience is what pushed me to document this process properly.
Unlock The Power Of Ocsp Response Signing With This Easytouse Template
Here's the OpenSSL-based approach that actually works in production. You'll need a signing certificate and private key separate from your CA bundle, and you'll need to configure your server to staple the signed OCSP response. First, generate or obtain a signing certificate. This certificate must be explicitly trusted by clients. Many organizations create a dedicated OCSP signing certificate under their CA hierarchy with the extended key usage set to OCSP Signing. If you don't have this, you can test with a self-signed certificate, but it won't validate in production without adding that certificate to client trust stores. The actual signing operation uses the openssl ocsp command with the -responder_key and -responder_cert flags:
openssl ocsp -responder_key ocsp_signer.key -responder_cert ocsp_signer.pem -issuer issuer.pem -cert server.crt -text -noverify This produces an unsigned response for testing. To sign it, add the -sign flag and point to your signing key: openssl ocsp -responder_key ocsp_signer.key -responder_cert ocsp_signer.pem -issuer issuer.pem -cert server.crt -signer ocsp_signer.key -signcert ocsp_signer.pem -text
Get the Full Details
For nginx specifically, the configuration looks like this in your server block: ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s; ssl_trusted_certificate /path/to/chain.pem; The ssl_trusted_certificate directive must include both your CA chain and your OCSP signing certificate. Without it, the stapling verification fails even if the signature itself is valid.
Common Pitfalls That Waste Your Time
The nonce handling is the biggest source of confusion. RFC 6960 specifies that responders should include a nonce in responses, but many implementations don't validate it strictly. If you're seeing intermittent failures, check whether your OCSP signing certificate is being cached properly. OpenSSL's caching layer has known issues with concurrent requests when the same signing key is used across multiple worker processes. Another issue: the -noverify flag you see in many examples. That's only for debugging. In production, remove it. The verifier checks that the signing certificate chains back to a trusted issuer and that the certificate has the OCSP Signing extended key usage. If your signing certificate lacks that EKU, the response gets rejected by strict clients like modern Chrome and Firefox. I also ran into a problem where the responder's next update field was set too far in the future. Some clients interpret an aggressive next update as a sign the response is stale and skip stapling entirely. Setting it to something reasonable like 24-48 hours resolves this. A few enterprise clients are even stricter and reject responses with next update beyond 72 hours.
Production Recommendations
Rotate your OCSP signing key periodically. I'd recommend every six months minimum, and immediately if there's any suspicion of compromise. The signing key doesn't need to be as protected as your CA key, but it still represents a trust anchor. Keep it on a separate HSM or at least a different filesystem from your main TLS keys. Monitor the response size. Signed OCSP responses can get large, especially when the signing certificate chain is long. Responses over 4KB may cause issues with some proxy servers that have strict header size limits. If you're hitting this, consider using a dedicated OCSP responder like ocspd from the OpenSSL project, which handles response compression and caching more gracefully than manual OpenSSL invocations. For automation, write a wrapper script that checks the response signature before deploying it. The script should verify the DER-encoded response, confirm the nonce matches (if you use nonces), and check that the signing certificate hasn't expired. Running this check in your deployment pipeline catches about 90% of the issues I've seen in production.
The template approach works well for standard PKI setups. If you're dealing with cross-signed certificates or an unusual CA hierarchy, the verification logic gets more complex. In those cases, test against openssl ocsp -VAfile with your actual trust store before relying on stapling in production.
When This Approach Falls Short
OCSP response signing doesn't solve every problem. If your CA's OCSP infrastructure is down, signed responses from your own responder only help if they were generated while the CA was reachable. There's no bypass for CA dependency unless you're running a full internal CA with delegated signing authority. Also, some legacy systems don't support OCSP stapling at all. Older Android versions, certain VPN concentrators, and some embedded devices simply ignore the TLS extension. For those, you're stuck with traditional OCSP lookups or CRL checks, neither of which benefits from your signing setup. If you need something more robust, consider moving to Certificate Transparency logs and DNS-based authentication of named entities (DANE). They address different attack surfaces but can complement OCSP stapling in a defense-in-depth strategy.
The template and commands here are sufficient for most standard deployments. The real value is in understanding the edge cases that break in production, not just getting the basic configuration to work.
