OCSP vs CRL: What’s the Difference?

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.

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 share 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:

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 will not 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 did not 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 would not 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 may 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 is 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 does not 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:

CRL OCSP Security
Lists all revoked certificates issued by a CA. Contains the revocation status of the requested website only
Revocation status verification takes longer than OCSP for checking an individual site’s certificate Revocation status verification takes less time than with CRLs for checking an individual site’s certificate
Uses more network resources than OCSP for checking single URLs Uses fewer network resources for checking single URLs
Suitable when multiple verifications are required Only suitable for the verification of a single TLS certificate at a time
Does not provide real-time updates on the revocation status of a TLS certificate Provides real-time updates
Useful in case of network failures if the CRL is saved offline Won’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.

Source

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.

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 share 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:

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 will not 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 did not 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 would not 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 may 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 is 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 does not 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:

CRL OCSP Security
Lists all revoked certificates issued by a CA. Contains the revocation status of the requested website only
Revocation status verification takes longer than OCSP for checking an individual site’s certificate Revocation status verification takes less time than with CRLs for checking an individual site’s certificate
Uses more network resources than OCSP for checking single URLs Uses fewer network resources for checking single URLs
Suitable when multiple verifications are required Only suitable for the verification of a single TLS certificate at a time
Does not provide real-time updates on the revocation status of a TLS certificate Provides real-time updates
Useful in case of network failures if the CRL is saved offline Won’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.

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

Multiple Vulnerabilities Discovered in Device42 Asset Management Appliance

A series of vulnerabilities on the popular asset management platform Device42 could be exploited to give attackers full root access to the system, according...

Top 5 best backup practices

Give yourself peace of mind by implementing a new backup strategy with our tips....

Indian Power Sector targeted with latest LockBit 3.0 variant

Estimated reading time: 5 minutesAfter the infamous Conti ransomware group was disbanded, its former members began to target the energy and power sectors...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!