OCSP vs CRL: What’s the Difference?

OCSP vs CRL: What’s the Difference?

1 Star2 Stars3 Stars4 Stars5 Stars (11 votes, average: 5.00 out of 5)

Before connecting to a website, browsers check the validity of the site’s TLS certificate and show a warning if the certificate is revoked. Browsers use several revocation status verification methods: OCSP, CRLs, OCSP stapling and OCSP must-staple. In this post, we’ll compare OCSP vs CRLs.

Every SSL/TLS certificate has an expiration date assigned by the certificate authority (CA) that issues it. However, a CA can revoke certificates early under certain circumstances. The result of a revoked certificate is that the website gets viewed as untrustworthy and most browsers will show a warning to users or refuse to connect them to such sites.

But how do web clients know that a site’s certificate has been revoked? The online certificate status protocol (OCSP) and certificate revocation lists (CRLs) are two commonly used techniques for verifying the revocation status of TLS certificates. OCSP is used more often these days, but CRLs are still in use as well.

In previous articles we’ve looked at OCSP, CRLs, and OCSP stapling. This time, we’ll focus on the differences between OCSP vs CRLs.

Don't make the same mistakes

Yahoo, Equifax, Home Depot,

LinkedIn, and Ericsson did!

Get our free 15-point checklist and

avoid the same costly pitfalls.

Please Select Your Country
  • Afghanistan
  • Albania
  • Algeria
  • Andorra
  • Angola
  • Antigua & Deps
  • Argentina
  • Armenia
  • Aruba
  • Australia
  • Austria
  • Azerbaijan
  • Bahamas
  • Bahrain
  • Bangladesh
  • Barbados
  • Belarus
  • Belgium
  • Belize
  • Benin
  • Bermuda
  • Bhutan
  • Bolivia
  • Bosnia Herzegovina
  • Botswana
  • Brazil
  • Brunei
  • Bulgaria
  • Burkina
  • Burundi
  • Cambodia
  • Cameroon
  • Canada
  • Cape Verde
  • Central African Rep
  • Chad
  • Chile
  • China
  • Colombia
  • Comoros
  • Congo
  • Congo {Democratic Rep}
  • Costa Rica
  • Croatia
  • Cuba
  • Curaçao
  • Cyprus
  • Czech Republic
  • Denmark
  • Djibouti
  • Dominica
  • Dominican Republic
  • East Timor
  • Ecuador
  • Egypt
  • El Salvador
  • Equatorial Guinea
  • Eritrea
  • Estonia
  • Eswatini
  • Ethiopia
  • Fiji
  • Finland
  • France
  • Gabon
  • Gambia
  • Georgia
  • Germany
  • Ghana
  • Greece
  • Grenada
  • Guatemala
  • Guinea
  • Guinea-Bissau
  • Guyana
  • Haiti
  • Honduras
  • Hungary
  • Iceland
  • India
  • Indonesia
  • Iran
  • Iraq
  • Ireland {Republic}
  • Israel
  • Italy
  • Ivory Coast
  • Jamaica
  • Japan
  • Jordan
  • Kazakhstan
  • Kenya
  • Kiribati
  • Korea North
  • Korea South
  • Kosovo
  • Kuwait
  • Kyrgyzstan
  • Laos
  • Latvia
  • Lebanon
  • Lesotho
  • Liberia
  • Libya
  • Liechtenstein
  • Lithuania
  • Luxembourg
  • Macedonia
  • Madagascar
  • Malawi
  • Malaysia
  • Maldives
  • Mali
  • Malta
  • Marshall Islands
  • Mauritania
  • Mauritius
  • Mexico
  • Micronesia
  • Moldova
  • Monaco
  • Mongolia
  • Montenegro
  • Morocco
  • Mozambique
  • Myanmar
  • Namibia
  • Nauru
  • Nepal
  • Netherlands
  • New Zealand
  • Nicaragua
  • Niger
  • Nigeria
  • Norway
  • Oman
  • Pakistan
  • Palau
  • Panama
  • Papua New Guinea
  • Paraguay
  • Peru
  • Philippines
  • Poland
  • Portugal
  • Qatar
  • Romania
  • Russian Federation
  • Rwanda
  • St Kitts & Nevis
  • St Lucia
  • Saint Vincent & the Grenadines
  • Samoa
  • San Marino
  • Sao Tome & Principe
  • Saudi Arabia
  • Senegal
  • Serbia
  • Seychelles
  • Sierra Leone
  • Singapore
  • Slovakia
  • Slovenia
  • Solomon Islands
  • Somalia
  • South Africa
  • South Sudan
  • Spain
  • Sri Lanka
  • Sudan
  • Suriname
  • Sweden
  • Switzerland
  • Syria
  • Taiwan
  • Tajikistan
  • Tanzania
  • Thailand
  • Togo
  • Tonga
  • Trinidad & Tobago
  • Tunisia
  • Turkey
  • Turkmenistan
  • Tuvalu
  • Uganda
  • Ukraine
  • United Arab Emirates
  • United Kingdom
  • United States
  • Uruguay
  • Uzbekistan
  • Vanuatu
  • Vatican City
  • Venezuela
  • Vietnam
  • Yemen
  • Zambia
  • Zimbabwe

Contact details collected on InfoSec Insights may be used to send you requested information, blog update notices, and for marketing purposes. Learn more...

What Is a CRL? An Overview of Certificate Revocation Lists

A certificate revocation list is an indelible list of websites’ revoked SSL/TLS certificates that’s issued and updated regularly updated by the issuing certificate authority. CAs store their CRLs on their public domains and shares the URL for the list via a certificate extension known as a CRL distribution point (CDP). This URL makes the CRLs available to client browsers attempting to connect to the listed sites.

According to IBM, CAs can have more than one CDP to use different protocols (HTTP, LDAP, etc.). In some cases, you may notice a CA using the same protocol for more than one CRL distribution point — for example, two HTTP CDPs. This can be beneficial for controlling the size of the certificate revocation list.

Take a look at the following screenshot of SectigoStore.com’s certificate details and check the highlighted CDP:

OCSP vs CRL graphic: A screenshot of the CRL distribution point (CDP) information for the Sectigo SSL/TLS leaf certificate for SectigoStore.com.

A screenshot of a TLS certificate showing CRL distribution point

In this screenshot, you’ll see that Sectigo offers a single CRL distribution point.

When a client browser attempts to connect to a website, it requests the CRL from the site certificate’s issuing CA. The browser then verifies whether the serial number for the server certificate of the website is on the list:

  • If it is not on the list, the certificate is deemed valid and the browser will allow the connection.
  • If the certificate serial number is on the list, it means the certificate has been revoked and the browser will show a warning that connecting to the site could be unsafe. Many modern browsers won’t connect at all in this instance.

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

Online certificate status protocol (OCSP) is a technique where the OCSP responder (or OCSP server) sends the status of the requested TLS certificate. There are three possible certificate statuses:

  • Good — The TLS certificate is valid, so the browser will connect to the website.
  • Revoked — The TLS certificate has been revoked, so the browser will show a warning and may not connect. This is known as a “hard fail.”
  • Unknown — The OCSP responder didn’t give a response, sothe browser may or may not connect, depending on the browser and its configuration. This is known as a “soft fail.”

The following screenshot shows what happens when a client browser tries to connect to a site with a revoked certificate:

CRL vs OCSP graphic: A screenshot from BadSSL.com that shows what happens when a user tries to connect to a website that's had its SSL/TLS certificate revoked.

A screenshot of the browser after attempting to load a website with a revoked TLS certificate

Look at this warning through your customers’ eyes: it’s definitely not a pretty sight. Because your site is deemed insecure, it means any data you share with that website (as the customer) is at risk to man-in-the-middle (MitM) attacks. If your customers and prospective customers receive these types of warnings, it could drive them away. And when that happens, they’re more likely to turn to your competitors with their business.

OCSP vs CRL: Let’s Compare How CRLs and OCSP Features Match Up

While both CRL and OCSP are techniques to verify the revocation status of TLS certificates, there are certain differences between the two. Let’s compare a few important considerations as part of this CRL vs OCSP piece.

What Is Responsible for Certificate Revocation Verification

With both methods, the responsibility for verifying the status of the TLS certificate lies with the client’s browser. With the CRL method, the browser sends a request to the CRL distribution point, while with OCSP the client sends the request to the OCSP responder. So, in both scenarios, the browser takes responsibility for verification.

Response Format

The response received by the client is very different with CRLs and OCSP:

  • CRLs: The responder (the CA) lists the serial numbers of all the certificates the CA revoked. The client browser downloads the whole list and searches for the serial number of the certificate of the website it is trying to connect to. If that serial number is not on the list, the browser considers that the certificate is not revoked and allows the connection. Since updated CRLs aren’t required to be published right away, it means that a certificate could be revoked a few hours after the last CRL update and your browser wouldn’t know it.
  • OCSP: The OCSP responder sends the revocation status of the specific TLS certificate requested by the browser — “good,” “revoked,” or “unknown.” These revocation status checks are done on a connection-by-connection basis, so the information is as up to date as possible.

Speed and Resources

The CRL method requires the browser to download the list of all the revoked certificates and parse it to look for the certificate serial number. As such, it can take longer to come up with a result than it does to request a single certificate’s revocation status with OCSP. Downloading the CRL also uses more network resources than downloading the response for a single website, so OCSP is less resource intensive.

Support for Multiple Certificates

OCSP is fast and efficient when requesting a single certificate’s revocation status. But for servers catering to multiple clients trying to access different websites, CRLs are more efficient as it’s possible to verify the status of multiple websites by downloading a single list. There’s no need to send multiple requests, provided the websites have the same CA. However, if the websites are certified by different CAs, OCSP is the better choice.

Real-Time Updates

The CA/Browser Forum (CA/B Forum) says in its SSL/TLS Baseline Requirements that CRLs must be “regularly updated” — but those intervals vary depending on the issuing CA and other specific considerations. For example, they could be updated every hour, every 24 hours, or even just once a week, so there can be a time lag between the last update and the client request.

If a website certificate is newly revoked after a CRL has been published, the browser could end up connecting to an insecure site. OCSP provides real-time updates and doesn’t have this issue.

Network Failure

We’ve all faced situations where our networks fail. So, what happens when the responder’s network is down? With OCSP, connections will likely be dropped as the responder will provide an “unknown” response. However, because CRLs are stored offline once downloaded, the browser can refer to it again and again without having to repeatedly connect to the CA.

OCSP vs CRL: An At-a-Glance Comparison of Both Revocation Check Methods

Let’s summarize the differences between OCSP and CRL:

CRLOCSP Security
Lists all revoked certificates issued by a CAContains the revocation status of the requested website only
Revocation status verification takes longer than OCSP for checking an individual site’s certificateRevocation status verification takes less time than with CRLs for checking an individual site’s certificate
Uses more network resources than OCSP for checking single URLsUses fewer network resources for checking single URLs
Suitable when multiple verifications are requiredOnly suitable for the verification of a single TLS certificate at a time
Doesn’t provide real-time updates on the revocation status of a TLS certificateProvides real-time updates
Useful in case of network failures if the CRL is saved offlineWon’t work if the OCSP responder network is down

Final Thoughts on OCSP vs CRL

Browsers check whether the TLS certificate of a website is valid before they connect to the site. OCSP and CRLs are both used to verify the revocation status of TLS certificates, but the way they work is very different. While a CRL lists all the revoked certificates, OCSP gives the revocation status of the single website requested by the browser.

Needless to say, each method has its advantages and disadvantages for different applications and use cases. But CRLs are falling out of use with OCSP taking over as the industry standard.

About the author

Megha can usually be found reading, writing, or watching documentaries, guaranteed to bore her family. She is a techno-freak with interests ranging from cooking to travel. A regular contributor to various web security blogs, she has earned her diploma in network-centric computing. Being a mother has taught her to speak less and write more (coz who listens to moms, right?).