How does OCSP revocation actually work and what is stapling?

OCSP revocation works by having clients query a third-party OCSP responder, specified in the certificate, to check its validity in real-time, while OCSP stapling improves this process by having the server provide a signed validity proof with the TLS handshake. The core problem with basic OCSP is that it creates a separate, blocking HTTP request to a Certificate Authority's (CA) OCSP server before a secure connection is established. This introduces latency, privacy concerns (the CA sees who is visiting your site), and a single point of failure. OCSP stapling solves this by allowing the web server itself to periodically fetch a fresh, signed OCSP response from the CA and then 'staple' it directly into the TLS handshake. The client can then validate the certificate's status using this pre-fetched, cryptographically signed proof without making an external call. This improves performance, enhances user privacy, and reduces dependency on the CA's OCSP infrastructure.

To implement stapling on a server like Nginx, you enable and configure the relevant directives in your configuration file.

ssl_stapling on;

ssl_stapling_verify on;

resolver 8.8.8.8;

ssl_trusted_certificate /etc/ssl/certs/trusted.crt;

The `ssl_stapling on;` directive enables the feature. `ssl_stapling_verify on;` tells Nginx to verify the OCSP response it receives from the CA's server. The `resolver` directive is needed for Nginx to resolve the OCSP responder's hostname. Finally, `ssl_trusted_certificate` points to a file containing the CA's root and intermediate certificates necessary to verify the OCSP response's signature. The server then automatically handles fetching and attaching the OCSP response for clients that support the extension.