CRL vs OCSP Explained: Complete Guide to Stapling & Must-Staple

When you visit a website with HTTPS, your browser needs to verify that the SSL/TLS certificate is valid and hasn’t been revoked. Certificate revocation is crucial for web security. Certificates may be revoked due to private key compromise, certificate authority errors, or other security concerns. Two primary methods to handle this verification are Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP). In this article, we tried to explain CRL and OCSP, comparing them from different aspects, including performance, privacy, and SEO perspectives.

Common reasons for SSL/TLS certificate revocation

Although every TLS/SSL certificate is issued with a defined validity period, it can sometimes be invalidated before its expiration date through a process known as certificate revocation. Revocation ensures that certificates that are no longer trustworthy cannot continue to be used, protecting the security of users who rely on them.

There are several scenarios where revocation becomes necessary. For example, a certificate authority (CA) may discover that it mistakenly issued a certificate, in which case it must revoke the incorrect one and reissue a valid replacement.

Here are some reasons for revocation:

• CA compromise: If the issuing certificate authority itself is breached, all certificates issued during the affected period may be revoked.
• Domain ownership changes: When a certificate owner no longer controls the domain tied to the certificate.
• Certificate replacement: When an older certificate is intentionally retired and substituted with a newer one.
• Legal or organizational changes: Such as when the certificate owner’s legal name or entity structure changes.
• Privilege revocation: If a user’s or system’s network access is intentionally withdrawn.

What is a Certificate Revocation List (CRL)?

A Certificate Revocation List (CRL) is a digitally signed list published by a Certificate Authority (CA) that contains all certificates that have been revoked before their scheduled expiration date. Think of it as a list that browsers and applications can check against. A CRL can be from a few bytes to even more than 10MB depending on the number of revoked certificates.

How CRL works

When a browser needs to verify a certificate using the CRL method, it follows these steps:

1. The browser extracts the CRL distribution point URL from the certificate.
2. It downloads the complete CRL file from the CA.
3. The browser checks if the certificate’s serial number appears in the list.
4. If found, the certificate is considered revoked; if not, it’s valid.

How to find a CRL address?

You can check a certificate CRL address in your browser. For example, in Google Chrome, follow these steps:

Open DevTools => Navigate to the “Privacy and security” tab => Click on the “View certificate” => Navigate to the “Details” tab => Find “CRL Distribution Points”

The CLR filesize in the image above is 120KB. So, when a browser wants to access a page with that certificate, it should download that 120KB file if it does not have it depending on the last-modified date.

When a browser sends a request to CA to download the CRL, based on the Last-Modified in the HTTP response header, it may or may not download the file. It means that if the browser has downloaded the CRL file after the last-modified time, it won’t download it again.

CRL benefits and drawbacks

While the CRL mechanism provides a straightforward and widely compatible solution, it comes with trade-offs in terms of performance and scalability. Below are the main strengths and weaknesses of the CRL approach.

CRL advantages:

• All browsers and operating systems support CRL
• No privacy concerns since you download the entire list

CRL disadvantages:

• Can be large file sizes that grow over time (can be several megabytes)
• Latency impact on page load times

What is Online Certificate Status Protocol (OCSP)?

An Online Certificate Status Protocol (OCSP) is a real-time protocol that allows applications to query the status of a specific certificate rather than downloading an entire revocation list.

According to RFC 6960, for purposes of efficiency, an OCSP responder is allowed to generate pre-signed, static responses ahead of time instead of dynamically creating a new one for every client request. This approach reduces server workload, lowers response latency, and helps prevent bottlenecks during periods of high demand.

How OCSP Works

With OCSP, browsers can quickly determine whether a certificate is valid. The verification flow looks like this:

1. The browser extracts the OCSP responder URL from the certificate
2. It sends a request to the OCSP responder with the certificate’s serial number
3. The OCSP responder checks its database and returns one of three responses:
   • Good: The certificate is valid and not revoked
   • Revoked: The certificate has been revoked
   • Unknown: The responder doesn’t know about this certificate
4. The browser accepts or rejects the connection based on the response

The OCSP response includes the Certificate status (good, revoked, or unknown), Response validity period (thisUpdate and nextUpdate timestamps), Digital signature from the OCSP responder, and Optional revocation reason and timestamp (if revoked).

How to find an OCSP responder address?

You can find an OCSP responder address in your browser. For example, in Google Chrome, follow these steps:

Open DevTools => Navigate to the “Privacy and security” tab => Click on the “View certificate” => Navigate to the “Details” tab => Find “Authority Information Access”

OCSP benefits and drawbacks

OCSP offers several advantages over traditional CRLs, improving efficiency and scalability, but it also comes with some drawbacks. Here’s a closer look at the key benefits and potential downsides:

OCSP advantages:

• Smaller response sizes (typically a few kilobytes)
• Real-time or near-real-time status information
• Reduced bandwidth consumption
• Faster verification process
• Better scalability for CAs managing millions of certificates

OCSP Disadvantages:

• Potential performance bottleneck if the responder is slow or unavailable
• “Soft-fail” problem where browsers often accept certificates if OCSP is unavailable
• Privacy concerns (discussed in detail below)

Privacy concerns with OCSP

Each time a browser checks a certificate via OCSP, it contacts the certificate authority’s OCSP responder with the certificate’s serial number. This effectively tells the CA (or anyone monitoring the traffic) which websites the user is visiting and when. Over time, this data could reveal a user’s entire browsing history.

Moreover, OCSP traffic can be logged, subpoenaed, or monitored by governments or ISPs. This makes it a potential channel for surveillance of user activity.

What is OCSP Stapling?

OCSP Stapling (formally called the TLS Certificate Status Request extension) addresses many of OCSP’s shortcomings by shifting the responsibility of obtaining the OCSP response from the client to the server. In other words, with stapling, the web server itself provides a signed OCSP response directly to the browser, eliminating the need for the browser to contact the certificate authority and thereby preventing the CA from tracking which sites the user visits.

How OCSP Stapling Works

OCSP Stapling streamlines certificate validation by letting the server provide revocation status directly to the client. The process works as follows:

1. The web server periodically requests an OCSP response for its own certificate
2. The server caches this time-stamped OCSP response
3. During the TLS handshake, the server “staples” the OCSP response to the certificate
4. The client receives both the certificate and its OCSP response simultaneously
5. The client verifies the OCSP response signature and checks its validity period

OCSP Stapling Benefits and Drawbacks

While OCSP Stapling addresses many of the privacy and performance issues of standard OCSP, it also has its own set of benefits and limitations. Here’s a closer look:

OCSP Stapling Benefits

• Privacy Enhancement: The client never contacts the OCSP responder directly. So, the CA cannot track which websites users visit.
• Performance Improvement: Eliminates the need for a separate OCSP request, which reduces TLS handshake latency while servers can cache OCSP responses and serve them quickly.
• Reliability: Continues working even if the OCSP responder is temporarily unavailable. The server can update the stapled response in the background

OCSP Stapling Limitations

• Requires server configuration and support
• Client must support the stapled response

What is OCSP Must-Staple?

OCSP Must-Staple is a certificate extension that requires servers to provide a stapled OCSP response. It’s defined in RFC 7633 and addresses the optional nature of standard OCSP Stapling. In other words, OCSP Must-Staple makes the stapling mandatory.

How OCSP Must-Staple Works

OCSP Must-Staple enforces stricter certificate validation by requiring stapled OCSP responses. The workflow works as follows:

1. When requesting a certificate, the domain owner includes the Must-Staple extension
2. The CA issues a certificate with the “status_request” extension flag
3. When a client connects, it checks for this extension
4. If present, the client requires a valid stapled OCSP response
5. If no valid stapled response is provided, the client rejects the connection

OCSP Must-Staple benefits and drawbacks

OCSP Must-Staple strengthens security by ensuring clients always receive a stapled OCSP response, but like any feature, it comes with both advantages and potential challenges. Here’s an overview:

OCSP Must-Staple Benefits

• Security Enforcement: Eliminates the soft-fail problem and prevents attackers from blocking OCSP requests to hide revoked certificates
• Privacy Guarantee: Ensures OCSP checks never leak browsing information to CAs

OCSP Must-Staple Challenges

• Operational Complexity: Requires careful server configuration and monitoring
• Limited Adoption: Requires both server and client support

Comparing CRL and OCSP

When deciding between CRL and OCSP (and their enhanced versions), it’s important to look at them side by side. Each method handles revocation differently, with trade-offs in speed, privacy, reliability, and complexity. The table below highlights the key differences and makes it easier to see why modern TLS deployments increasingly favor OCSP Stapling and Must-Staple over traditional CRLs.

Feature	CRL	OCSP	OCSP Stapling	OCSP Must-Staple
Update Frequency	Periodic (often hours or days)	Real-time	Real-time (server provides cached response)	Real-time
Performance	Can be slow for large lists	Slower for each certificate query	Fast (response cached by server)	Fast (requires stapling)
Privacy	No privacy for CA (client reveals used CAs)	Client reveals visited sites to CA	Improved privacy (CA not contacted by client)	Improved privacy
Reliability	High if CRL cached	Dependent on CA responder availability	High	High, but the server must be configured correctly
Complexity	Low	Medium	Medium	High

Case study: Timing Comparison of CRL vs OCSP

To better understand the real-world performance differences between CRL and OCSP, I collaborated with Mohammad Mansouri, a network engineer and network security professional. Mohammad conducted a series of tests using different tools to measure the time it takes for browsers to validate certificates via CRL and OCSP.

In this case study, five websites using CRL and five websites using OCSP were randomly selected, and their certificate validation times were measured using tools such as OpenSSL, cURL, and Wireshark. To ensure accurate results, the browser and DNS cache were cleared before each measurement, eliminating any cached data that might otherwise affect the timing. The focus was on capturing the raw delay introduced by each method and comparing the average response times between CRL and OCSP.

Method 1: OpenSSL and cURL

The first method focused on simple timing measurements using OpenSSL and cURL to record the time it took for each revocation check. Five random websites that relied on CRL were tested, and five websites that used OCSP were tested in parallel. The results show the average delay added by each approach during certificate validation.

Method 2: Wireshark

The second method analyzed the TLS handshake process in detail using Wireshark packet captures. This approach broke down each stage of the connection to show exactly where time was spent.

CRL Timing Result (microsoft.com)

Time	Protocol	Packet Info
0.000 S	DNS	Standard query for x1.c.lencr.org
0.015 S	TCP	SYN -> Three-way Handshake starts
0.035 S	TLSv1.3	Client Hello -> TLS Handshake starts
0.100 S	HTTP/2	GET /r10.crl
0.150 S	HTTP/2	HEADERS (HTTP/1.1 200 OK)
0.151 S	TCP	TCP segment of a reassembled PDU
0.458 S	TCP	TCP segment of a reassembled PDU

OCSP Timing Result (microsoft.com)

Time	Protocol	Packet Info
0.000 S	DNS	Standard query for oneocsp.microsoft.com/ocsp
0.015 S	TCP	SYN -> Three-way Handshake starts
0.035 S	TLSv1.2	Client Hello -> TLS Handshake starts
0.095 S	TLSv1.2	Application Data (Encrypted)
0.096 S	OCSP	OCSP Request
0.135 S	TLSv1.2	Application Data (Encrypted)
0.136 S	OCSP	OCSP Response: GOOD

Conclusion

Both CRL and OCSP serve the critical function of certificate revocation checking, but they make different tradeoffs:

• Use CRL when: When you can afford bandwidth and storage, real-time updates aren’t critical, and you’re building offline-capable systems
• Use OCSP when: When you need more current revocation information, bandwidth efficiency is important, and you can accept some privacy tradeoffs
• Use OCSP Stapling when: When you want both privacy and performance, and you control the server infrastructure
• Use OCSP Must-Staple when: When maximum security and privacy are required, you have a robust operational infrastructure, and you can ensure high availability

For most modern websites, implementing OCSP Stapling provides the best balance of security, privacy, and performance. OCSP Must-Staple represents the ideal, but requires careful operational consideration. As the web security landscape evolves, newer approaches like CRLite and short-lived certificates may eventually supersede these traditional methods.

FAQ about CRL and OCSP