July 18, 2022 0

What Is OCSP Stapling & Why Does It Matter?

in Cyber Security

(10 votes, average: 5.00 out of 5)

Loading...

OCSP stapling makes verifying the revocation status of an SSL/TLS certificate faster and easier for a client than ever before. It’s an improvement on the current industry standard, OCSP. But what is OCSP stapling and why does it matter to your website’s security?

When you use a browser to access a website, the browser checks many things on the site’s TLS certificate: the certificate’s signature, validity period, whether the certificate is valid or revoked, etc. There are several methods for verifying the revocation status of the TLS certificate, including certificate revocation lists (CRLs), the online certificate status protocol (OCSP), and OCSP stapling.

In our previous article, we looked at OCSP and how it helps you verify the revocation status of a website certificate. With OCSP, the client requests the site’s certificate from the site. The site’s web server sends its certificate to the issuing CA, which uses its OCSP responder to provide information about the certificate’s revocation status. In turn, the web server then sends it back to the user’s browser.

It’s a secure method, but it has its limitations. OCSP stapling was developed to overcome some of those limitations.

What Is OCSP Stapling? A Look at the Online Certificate Status Protocol Stapling

OCSP stapling refers to the verification technique for the status revocation of X.509 certificates, where the server sends periodical status requests to the CA and passes on the CA’s response to the client browser. Thus, when the client browser wants to connect, the server will present the CA’s status response indicating whether the certificate is valid or revoked.

OCSP stapling is described in the RFC 2560 and RFC 5019. The website’s server provides an updated status directly to the client attempting to connect. The client can trust it as it is signed and timestamped by the issuing CA.

To help you visualize the process, imagine your doorbell rings at an odd hour. You open the door and see two serious-looking people standing on the doorstep, who ask whether they can come in for a chat. Do you let them in? Probably not. But what if they’re wearing uniforms and have ID badges saying they work for the FBI? Then your perspective might change. Think of OCSP stapling as being akin to those ID badges. You don’t need to check with the FBI when an agent knocks on your door, because the badges indicate that they can be trusted.

As a client connecting to a website, the website shows you a digitally signed, timestamped report detailing whether the TLS certificate is valid. Just like the FBI issues those badges, the verification is issued by the CA. The FBI will take away the badge if an agent is suspended, fired, or quits — similarly, CAs revoke TLS certificates under certain circumstances.

How OCSP Stapling Differs from CRLs

OCSP is better than using CRLs to verify the revocation status of TLS certificates. A CRL is the whole list of revoked website certificates that gets periodically updated. OCSP refers to a server response that comes from a website certificate’s issuing CA. It provides current, up-to-date data about the certificate’s revocation status. However, as a result, also uses more resources. OCSP stapling is a third option that keeps information about the certificate’s revocation status readily on hand by “stapling” it.

OCSP process can be slow when lots of clients send requests to high-traffic websites because the certificate authority (CA) must send out individual responses to individual clients. Using OCSP stapling speeds up the process as the website server will have the certificate ready for the client whenever they asked for. So, instead of numerous clients placing individual requests to the CA, the server itself will send requests at regular intervals. 

So, the traditional OCSP is more accurate than OCSP stapling because it’s providing a real-time server response (versus something that may have been issued prior to a certificate being revoked). But OCSP stapling is helpful because it helps to improve performance because it can rely on the timestamped information and doesn’t have to make a new revocation check.

How Does OCSP Stapling Work?

Unlike with other verification methods, where the client takes responsibility for verifying the certificate revocation status of websites, OCSP stapling places the burden on the server. When a client wants to connect, the server presents the last updated verification status to them.  The CA has the authority to decide the refreshing time of the response. The client can trust the certificate as it is signed by the CA that issued the server certificate. It’ll also include a timestamp that shows the date and time it was created.  

A Step-by-Step Look at OCSP Stapling

The OCSP stapling process goes like this:

1. The web server requests the updated revocation status from the CA on the backend as the two entities are in regular communication.
2. The CA sends signed, timestamped information about its revocation status to the server, which stores it in its cache.
3. The client browser sends a connection request to the server.
4. The server “staples” or annexes the cached information about its own revocation status to its reply to the client.
5. If the server certificate is valid, the client browser will connect to the website.
6. If the server certificate is revoked, the client browser will display an error message that the certificate is invalid.

A visual representation of how OCSP stapling works

Certificate Responses

The following responses are possible with OCSP stapling:

• Revoked: When a server certificate is revoked, the browser will show a warning and likely not connect to the website. This response is known as a hard fail because the browser will immediately terminate the connection. A revocation message will look like this to users:

Image caption: An example screenshot of a revoked certificate warning message that displays in Google Chrome.

• Good: A good response is given when the OCSP responder recognizes the certificate serial number and finds that it is valid.

• Unknown: This message displays if the responder doesn’t recognize the certificate, an unknown response is sent. The responder might not have access to the CA that issued the certificate. This type of failure is called a soft fail because it may (or may not) allow the connection to go through.

What Are the Advantages of Enabling OCSP Stapling?

There are many advantages of using OCSP stapling for verifying the revocation status of TLS certificates, including:

• Offers improved speed and performance. Speed is one of the most significant advantages of the OCSP stapling method. It takes a minimal amount of time to verify the revocation status of any TLS certificate.

• Providers better privacy for users. Since the CA or the OCSP responder can’t see the websites visited by the client, the client’s privacy is better protected than with traditional OCSP responder queries.

• Requires fewer resources. In comparison to CRL or OCSP, the OCSP stapling uses fewer network resources for the client, making it a more efficient method.

3 Limitations of OCSP Stapling

As with any other protocol, OCSP stapling has its limitations:

• No verification of intermediate certificates. Sometimes, TLS certificates contain many intermediate CA certificates forming a certificate chain. OCSP stapling typically doesn’t provide verification for the intermediate certificates (it typically just provides revocation status checks for leaf/server certificates). However, multi-stapling was introduced in June 2013 through RFC 6961. TLS 1.3 has the support for multiple OCSP responses.

• Period between OCSP responses may leave you unaware of new revocations. There is usually a delay between two OCSP stapling responses. This time gap can be a few hours or longer. If the certificate is revoked during that time, the server could give out outdated responses. 

• OCSP stapling isn’t supported by all browsers. Not all browsers and web servers support stapling at the current time, although it is becoming more widespread.

Distinguishing Features of OCSP Stapling Over CRLs & OCSP

Some of the features that differentiate OCSP stapling from other methods are:

• Liability of Proof: When a server uses OCSP stapling and the website visitor’s client supports it, the server takes on the responsibility of proving that its TLS certificate has not been revoked.
• Cost of Proof: The cost of requesting and providing the revocation status is to be borne by the server, including its processing and network-related resources.
• Improved Efficiency: The client doesn’t have to request the revocation status of the TLS certificate; the server will provide one automatically from the certificate’s issuing CA. It saves time and makes the TLS handshake very efficient.

OCSP vs. OCSP Stapling at a Glance

OCSP stapling builds on simple OCSP. This table lays out the differences between the two methods:

OCSP	OCSP Stapling
The responsibility of verification lies with the client browser	The server has to provide proof that the certificate has not been revoked
The privacy of the client might be compromised as the CA can see all the websites the user has visited	The server contacts the CA for its timestamped response, so the CA can’t see other sites visited by the client
The cost of verification is borne by the client	The cost of verification is borne by the server
Slower than OCSP stapling as there are many rounds of communication	Faster than OCSP because it doesn’t have to send out individual OCSP server requests
Not ideal for high-traffic websites	Ideal for high-traffic websites
All certificates in the certificate chain can be verified	Not all certificates in the certificate can be verified as the server only staples its own revocation status response
No time gap between the request from the client browser and the response from the CA	There is an interval between two requests sent by the server to the CA

Which Browsers Support It

OCSP stapling is enabled by default in most of the big browsers, but it’s not universally supported. The following browsers and services support this revocation check method:

• Apache — Apache HTTPD Server 2.3.3+
• Edge — Supports it
• Firefox — Firefox enabled default in version 3.0 and above
• Google Chrome — Enabled by default
• Internet Explorer — Version 7.0 and above supports OCSP stapling
• NSS (Network Security Services) — Supported by version 3.15 and above
• OpenSSL — Supported by version 0.9.8h and above
• Opera — Version 8.0 and above supports stapling
• Safari — Enabled by default in Mac OS X 10.7 and above

How Can You Turn on OCSP Stapling?

Most browsers have OCSP stapling enabled by default. However, if you want to enable it for your server, you can do so. Below, we’ve outlined the steps for enabling this revocation checking method in Apache specifically.

Enabling OCSP Stapling in Apache

If you use Apache, then you can follow the steps given below to enable OCSP stapling:

1. Check which version of Apache you use. The versions Apache 2.3.3+ allow this revocation check method. You can verify which environment you’re using with one of the two following commands (the first is for Ubuntu or Debian, the second is for CentOs or Red Hat):

apache2 -v 

httpd -v

• Before you turn on OCSP stapling on the Apache server, you first need to confirm that your intermediate certificates are installed properly.

• You’ll also want to make sure you don’t already have OCSP stapling enabled. To do this, use the following OpenSSL command (you should see an OCSP response message “Successful”):

openssl s_client -connect yourdomain.com:443 -status

• Now, it’s time to edit your site’s virtual host configuration file using an editor like Nano or Vi:

nano /filepath/apache2/ssl/your-domain-ssl.conf

• Now, it’s time to turn on OCSP. You can do this with the following command inside the virtual host tags (they look like <VirtualHost></VirtualHost>):

SSLUseStapling on

• You can specify the time (in seconds) to wait for the OCSP response from the responder. For example, here’s how to set it for 15 seconds:

SSLStaplingResponder Timeout 15

• Prevent the error message by entering the following command:

SSLStaplingReturnResponderErrors off

• Point to the path of your full trusted certificate chain, including root, intermediate, and server by placing the following command inside the <VirtualHost></VisualHost> tags:

SSLCACertificateFile /yourpath/apache2/ssl/full_cert_chain.pem

Otherwise, you can specifically link to your certificate and key files:

SSLCertificateFile /yourpath/apache2/ssl/yourdomain_certificate.crt
SSLCertificateKeyFile /yourpath/apache2/ssl/yourdomain.com/example_key.key

• Use the following command (outside the VirtualHost tags) to specify the place where you want to cache the OCSP response:

SSLStaplingCache shmcb:/var/run/ocsp(128000)

Test Your Configurations and Reload Apache

Of course, once all of this is done, you’ll need to double-check to ensure that everything is properly configured. You can do this by running a quick test and reloading your Apache service using the following commands:

apachectl -t
service apache2 reload

Final Thoughts on OCSP Stapling and Why It Matters

Visiting sites with expired or revoked TLS certificates can easily lead to cybercriminals stealing your customers’ critical sensitive data so they can use it for malicious purposes. OCSP stapling is a technique that allows browsers to verify whether the TLS certificate of a website you want to visit has been revoked by providing a real-time revocation status check.

Although OCSP stapling is faster and more efficient than CRLs and OCSP, it’s not universally supported by all browsers. However, it is gaining in popularity, though, and you may see it utilized more in the future.

• #OCSP Stapling