Why Your SSL is Slower Than it Should Be (and the Nginx Fix)

Imagine this: a user lands on your site, but instead of the page snapping open, there’s a tiny pause. Barely noticeable, but it happens to every visitor. As a dev, it’s bugging you. Well, the reason might be your browser is stopping to ask a CA (Certificate Authority) server if your SSL certificate is still valid. It’s a clunky process—slower than it should be, and it even exposes your user’s browsing habits along the way.

What’s can be the fix then? That’s what this article is all about. Let’s begin.

OCSP

First of all, what is OCSP ? OCSP, which stands for Online Certificate Status Protocol, is a protocol used to determine the revocation status of a digital certificate without relying on the traditional Certificate Revocation Lists (CRLs).

Imagine a digital certificate is like a driver's license. To check if a driver's license is still valid (and hasn't been revoked), you have a couple of options:

1. Checking a big list: The traditional method was to check a Certificate Revocation List (CRL), which is like a massive PDF of all revoked licenses. This file can be very large and is updated infrequently, making the process slow and potentially outdated.

2. Making a quick call: OCSP is like making a quick, real-time call to the Department of Motor Vehicles. A client (like a web browser) sends a request to an OCSP responder (a server run by the Certificate Authority) asking, "Is certificate X still good?" The responder then replies with a simple, signed response: "good," "revoked," or "unknown."

This real-time, per-request method is much more efficient and up-to-date than checking a CRL.

Now that OCSP is out of the way, let’s discuss OCSP stapling.

OCSP stapling

When a user connects to your website, their browser performs a series of checks to ensure the connection is secure. One of the most critical of these is verifying the certificate's revocation status—making sure the certificate hasn't been compromised or revoked by the Certificate Authority (CA). For that, client (your web browser) makes the request to CA server. Generally, that is.

Here comes OCSP stapling into picture. Instead of browser making the request to CA server, the web server proactively checks with the CA for a signed, time-stamped status response and then “staples” that response with the certificate during initial TLS handshake. This is OCSP stapling.

Here’s the step-by-step workflow:

1. Server Prepares the Response: Your web server (e.g. Nginx) proactively queries the Certificate Authority's OCSP responder at regular intervals. It requests the current revocation status of its own SSL certificate.

2. CA Signs and Returns the Status: The CA checks the certificate's status. It then generates a digitally signed, time-stamped OCSP response confirming if the certificate is good, revoked, or unknown.

3. Server Caches the Response: Your server receives this signed response and stores it in its local memory. The response has a validity period (e.g., a few days), and the server will periodically refresh it before it expires.

4. The Staple is Sent: When a client (e.g., your web browser) initiates a TLS handshake with your server, the server includes the cached OCSP response as an extension to its certificate. This response is "stapled" to the certificate itself.

5. Client Verifies Instantly: The client receives the certificate and the signed OCSP response in a single step. It can instantly verify the signature and the time stamp of the response to confirm the certificate's status, all without making a separate network call to the CA.

Enabling stapling in Nginx

It is actually very simple and effortless to enable OCSP stapling in Nginx. By just adding few additional directives to your existing nginx config, you can easily achieve the stapling.

Inside your server block:

server {

    # existing confs ...
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
}

I am assuming that you are using letsencrypt as CA. You can provide path to your trusted_cetificate accordingly. Here’s what each directive mean:

ssl_stapling on;: This directive enables the OCSP stapling feature.

ssl_stapling_verify on;: It tells Nginx to verify the stapled OCSP response to ensure it's valid and has a trusted signature from the CA. Much important.

ssl_trusted_certificate: This directive points to the file containing your intermediate and root certificates. Nginx needs this to verify the stapled response.

After saving, you can test your nginx config with nginx -t and reload your nginx.

That’s it ! Now, can enjoy various benefits that comes with the stapling.

Benefits

1. It Makes Things Faster
Normally, your browser has to pause and ask the CA, “Hey, is this certificate still good?” That extra back-and-forth takes time. With OCSP stapling, the server already has the CA’s answer “stapled” to its certificate, ready to go. The result? Faster secure connections and happier users (plus a small SEO perk since search engines love speed).

2. It Keeps Your Browsing Private
Without stapling, every time your browser checks in with the CA, it’s also handing over your IP address. That means a third party can see what sites you’re visiting. With stapling, your server talks to the CA on behalf of your users—so their browsing habits stay private.

3. It Closes a Security Loophole
Old-school OCSP had a flaw known as “soft-fail.” If your browser couldn’t reach the CA’s server, it would just shrug and assume everything was fine. Hackers could exploit that by blocking the request. OCSP stapling fixes this: if the server doesn’t provide a valid stapled response, the browser can block the connection entirely. Safer for everyone. You need to enable the OCSP must-staple for this though. OCSP Must-Staple is a special flag embedded in a certificate at the time of issuance. This flag tells a browser, "This certificate is only valid if a current and signed OCSP response is stapled to it."

With a Must-Staple certificate, the browser's behavior changes completely:

• If a valid stapled response is present: The browser quickly verifies the certificate and proceeds with the connection.

• If the stapled response is missing or invalid: The browser immediately hard-fails and terminates the connection, showing a security error to the user.

Enabling OCSP must-staple ( Pro max )

This is one step even further. This is a special flag embedded in your certificate that tells a browser that it must receive a valid stapled OCSP response. If the server fails to provide one, the browser will hard-fail and terminate the connection, closing the soft-fail security hole. To get a certificate with this flag, you must explicitly request it from your CA. If you use Certbot, simply add the --must-staple flag when you issue or renew your certificate:

sudo certbot certonly --nginx --must-staple -d yourdomain.com

Verify if it’s working

To verify your OCSP stapling is working successfully, you can use the command provided below:

openssl s_client -connect yoursite.com:443 -status

If it is working it will return OCSP response. Look for :

OCSP Response Status: successful (0x0)

This way, you can leverage the power of OCSP stapling to make your server fast, secure and more reliable.

Here are the additional resources to look into if this article sparked some curiousity.

OCSP: https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
OCSP stapling wikipedia: https://en.wikipedia.org/wiki/OCSP_stapling
For k8s folks: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-ocsp