(1 votes, average: 5.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

October 26, 2023 2

OCSP vs CRL: What Each Is & Why Browsers Prefer One Over the Other

in Hashing Out Cyber Security, Industry Lowdown, Monthly Digest

Although they both serve largely the same function, OCSP servers and CRLs do their jobs differently. Here’s what to know about the similarities and differences between the two security certificate validation checking methods and why browsers are moving toward using CRLs primarily instead.

In July, the industry’s standard body voted to make using CRLs a requirement and OCSP optional for certificate authorities (CAs) starting March 15, 2024. These tools are how browsers check automatically to see whether a website’s SSL/TLS certificate has been revoked, so it knows whether to trust it to establish an encrypted connection. (If it’s revoked, it can’t be trusted, and the browser should terminate the connection immediately.)

But with this in mind, we’ll provide an overview of each method and go over the advantages of using one revocation checking system over the other (OCSp vs CRL) by exploring what led to the CA/Browser Forum’s (CA/B Forum) decision to require CRLs over the use of OCSP.

Let’s hash it out.

OCSP vs CRL: An Overview of the Certificate Revocation Checking Mechanisms

The online certificate status protocol (OCSP) and certificate revocation list (CRL) are two of the tools certificate authorities (CAs) can use to indicate when certificates have been revoked.

Revoked = the certificates aren’t trustworthy for a reason other than expiration (e.g., your key has become compromised, the certificate was misissued by the CA, etc.)

Much like groceries, every digital certificate is issued with an expiration date. However, there are cases when certificates go “bad” and are revoked before their assigned expiration dates. Think of it like buying milk from the grocery store: Image you’ve bought a gallon of milk from the store:

• If you bring it home and keep it refrigerated properly, then it should stay good until its expiration date.
• If you take it home and accidentally leave it sitting on the counter overnight, then you’ll have a gallon of spoiled milk that needs to be tossed.

The first example is akin to certificate expiration: the milk is supposed to stay good until the assigned expiry date. The second example is akin to a certificate being revoked: something compromised or otherwise affected the milk prior to its expiration date (leaving it undrinkable).

TL;DR: A Comparison Table of CRL vs OCSP

Don’t have time to read a whole article on the differences between OCSP vs CRL? Check out the following table for an overview of both revocation status-checking methods:

	Online Certificate Status Protocol	Certificate Revocation List
What It Is	A server response that provides information about whether a certificate has been revoked prior to its expiration date.	A timestamped list of digital certificates that have been revoked before expiration.
What It Does	Informs a client about a certificate’s revocation status, so it knows whether to allow or reject connections.	Informs clients about a certificate’s revocation status, so they know whether to allow or reject connections automatically.
What It Contains	Responses of “good,” “revoked” or “unknown”	Each revoked certificate’s serial number and revocation date.
When Is It Checked?	OCSP servers are checked during each connection	Clients generally check the locally stored CRL on each connection; if a certificate or CRL list has expired, the browser will download a new list.
Is It Required?	No. The use of OCSP is optional, but when it’s implemented, “OCSP responders operated by the CA SHALL support the HTTP GET method as described in RFC 6960 and/or RFC 5019.”	Yes. The use of a publicly available CRL is mandatory. CAs must make either of the following available on a publicly accessible HTTP URL: – A full and complete CRL – Partial lists that, together, form a complete CRL
Revocation Update Requirements	OCSP status responses for subscriber certificates: – Equal or greater than 8 hours – Less than or equal to 10 days   OCSP status responses for CA certificates: – Every 12 months (at least) – Within 24 hours after revoking a subordinate CA certificate	A new subscriber certificate CRL must be updated and published: – Within 24 hours of recording a certificate’s revocation, – At least every 7 days for certificates containing AIA extensions, or – At least every 4 days otherwise   CA certificate CRLs must be updated: – Every 12 months, or – Every 24 hours after recording a certificate revocation

How Will the CRL & OCSP-Related Changes to the Baseline Requirements Impact You?

For the most part, they won’t (at least, not directly). The brunt of these CRL and OCSP changes will be felt by the certificate authorities that issue your SSL/TLS certificates. This is because the new requirements affect the methods and update frequencies surrounding how they publish revoked digital certificates. None of these things should affect the services you receive from the CAs.

Have a bit more time or do you just want to dig more into each method? Great. We have plenty more to share.

What Is the Online Certificate Status Protocol (OCSP)?

The online certificate status protocol, more commonly called OCSP, is a method for determining a website’s certificate validity status in real time. This is done using OCSP servers, or what are often called OCSP responders. The CA that issued the certificate in question Is responsible for maintaining and updating the server’s database.

When a client reaches out to ask about a specific certificate, it triggers a series of events that instigate a response from the OCSP server of the CA that issued the certificate. Here’s a quick overview of how a browser checks a certificate’s revocation status with OCSP:

What Is a Certificate Revocation List (CRL)?

A certificate revocation list is akin to a blacklist of X.509 digital certificates that a CA has revoked for one reason or another (typically due to mis-issuance or compromise-related issues). The certificates included in the list are intended for use for authenticating servers over the internet (i.e., SSL/TLS certificates, or what are otherwise known as website security certificates).

The process works similarly to OCSP in the first couple of steps — i.e., the client tries to connect to the site, and the site’s server sends its SSL/TLS certificate. But the process after that differs:

Publishing and maintaining a current CRL list enables a CA to inform clients whenever it revokes a certificate. This allows the client to know that the certificate isn’t trusted and, therefore, shouldn’t be used to forge secure connections. Typically, you can find CRL information included in the CRL Distribution Points section of an SSL/TLS certificate:

How Often Do Browser Clients Update the Local CRLs?

Isn’t there a requirement for how frequently browser makers must make their browser clients update their local CRLs? Nope. That’s because the CA/B Forum only defines the requirements for CAs; it doesn’t define them for browsers or other software makers. So, I guess you could say it’s a bit of a “wild west” regarding the frequency of CRL downloads by clients.

Simply put, there are no specific requirements for the browser client update frequency, and it’s subject to change based on the determination of each browser maker. For example, Mozilla Firefox has a proprietary list (CRLite) that they push out “up to 4 times per day,” according to one of their blog posts on CRLite.

Google Chrome has a proprietary set of CRLs that’s ever-so-creatively named “CRLSets.” According to The Chromium Project:

 “We maintain an internal list of crawled CRLs which are intended to cover immediate revocations. The CRLs from that set go to make the published CRLSet. CRLs on the list are fetched infrequently (at most once every few hours) and verified against the correct signing certificate for that CRL.”

OCSP vs CRL: Why Either Tool Is Needed

Generally speaking, certificate revocation can mitigate issues stemming from compromised, misissued, or otherwise insecure digital certificates and keys. Although mass revocations are uncommon, they have been known to happen now and again. For example, multiple CAs revoked millions of certificates due to insufficient serial number sizes in 2019, and Let’s Encrypt had to do the same due to coding-related vulnerabilities.

But simply revoking them isn’t enough; browsers need a way to ensure that once a certificate has been revoked, a digital certificate is no longer trusted. By checking the validity of a website’s SSL/TLS certificate using one of these recognized methods, web clients can verify its current validity status before trying to use it to authenticate and connect to the site.

What the CA/B Forum’s Required Changes Entail

Revocation Mechanisms Are Now Optional for Short-Lived Certificates

Although this isn’t the focus of the article at hand, we thought it would be worth mentioning that Ballot SC-63 also approved some changes regarding a topic that was introduced years ago in Ballot 153 (i.e., “short-term certificates”). The newly approved changes in the SSL/TLS BR Version 2.0.1 indicate that a CA “MAY support revocation of Short-lived Subscriber Certificates,” but it’s not a requirement.

Furthermore, the certificates aren’t required to be included in any CRL or OCSP responses, either (likely due to their shortened validity periods.

Not sure what counts as a “short-lived” certificate?

• Starting on March 15, 2024, subscriber certificates with validity periods of “less than or equal to 10 days (864,000 seconds)”
• For those issued after March 15, 2026, the maximum validity period will be 7 days (604,800 seconds) or fewer.

Other certificates with max validity dates surpassing these periods have standard lifespans of 398 days.

CRLs Must Be “Full and Complete”

In addition to the general requirement of using a certificate revocation list, the industry’s standards organization specifically requires either the CRL is:

• a “full and complete” list, or
• a “sharded” (partitioned) set of CRLs that, together, equate to the same.

Subscriber Certificate CRLs Must Meet Specific Time Constraints

Generally speaking, a CRL must be updated and published within 24 hours of a certificate receiving revocation status. But this isn’t a hard-and-fast rule; according to Ballot SC-63, there are exemptions and alternative processes to follow depending on a couple of key factors.

1. Certificates Include AIA Extensions: This update-and-republish timeline doesn’t necessarily apply if a CA’s certificates all include an Authority Information Access (AIA) extension “with an id-ad-ocsp accessMethod (‘AIA OCSP pointer’).” An AIA certificate extension is a way of specifying which responder to use. So, the use of AIA extension means that CAs have up to 7 days to publish an updated CRL if all certificates meet the described requirements (i.e., they have OCSP revocation support).
2. Regular Interval Updates: If a CRL includes certificates without OCSP support, it’ll still be required to update and publish an updated list, regardless, “at least every four (4) days in all other cases.” (NOTE: It SHOULD still revoke applicable certificates within 24 hours.) This way, when a browser requests a CRL, it’ll know it has the most up-to-date information (even if no new certificates have recently been recorded as revoked).

Now comes the tricky part: Microsoft’s root policy requires the use of OCSP pointers. So even though they’re not technically a requirement the situation isn’t that cut-and-dry because that would leave CAs in the lurch.  

We reached out to Corey Bonnell, Industry Technology Strategist at DigiCert for clarification on this point. Bonnell has been active on behalf of the CA as a representative of the CA/B Forum. He also had a hand in helping the Google Chrome team write significant parts of the ballot.

“Every TLS certificate will have an OCSP pointer,” Bonnell said. “So, despite the allowance in the BRs for TLS certs to omit the OCSP pointer, CAs who participate in the [Microsoft Root Program] (which is basically all publicly trusted CAs) must include the OCSP pointer to comply with their policy.”

Having your certificates included in Microsoft’s Root Certificate Program is vital because this is what enables anything signed by those root certificates to be recognized by Windows operating systems and browsers.

CRLs for CA Certificates Must Also Meet Specific Time Constraints

As with the new subscriber certificate CRL requirements, CRLs for CA certificates also must be updated and published within 24 hours after a cert’s revocation recording has been entered. Otherwise, it’s only required to update and publish a new list every 12 months. 

Why Certificates May Get Revoked in the First Place

So, what are some examples of reasons why a certificate might be revoked? Here’s an overview of the reasons specified in the CA/B Forum’s SSL/TLS Baseline Requirements (version 2.0.1):

Why a Certificate Shall Be Revoked in 24 Hours	Why a Certificate SHOULD Be Revoked in 24 Hours (and MUST Be Revoked Within 5 Days)
1. Unspecified reason	1. Certificate doesn’t comply with BR requirements in Sections 6.1.5 and 6.1.6
2. Unauthorized original certificate request	2. Certificate has been misused and privileges have been withdrawn
3. Subscriber’s certificate private key is compromised	3. Subscriber violated obligations and certificate privileges have been withdrawn
4. Subscriber’s certificate private key is weak	4. Domain specified in the certificate is no longer valid or the subscriber no longer controls it
5. Subscriber’s status or authorization isn’t reliable	5. Wildcard certificate is misused to misrepresent a FQDN
	6. Pertinent certificate information has changed
	7. Certificate was improperly issued
	8. Certificate information is inaccurate
	9. Issuing CA’s issuance rights have expired, revoked, or otherwise been terminated
	10. Certificate is revoked for an unspecified reason relating to the CA’s CP/CPS
	11. Subscriber’s private key is compromised due to flawed key generation

OCSP vs CRL: Why the Industry Is Shifting Away from OCSP

There are two key reasons why industry leaders are making OCSP optional:

1. Data Privacy Concerns and Considerations

People have a right and expectation of privacy, and OCSP requests aren’t amenable to it. Why? Because OCSP requests that are sent include the serial number of the certificate’s status that’s being requested. If that information is transmitted, it means that someone could use that information to identify which website a user is visiting and/or what specific page they’re looking at. 

According to the CA/B Forum’s justifications document: “OCSP requests reveal details of individuals’ browsing history to the operator of the OCSP responder. These can be exposed accidentally (e.g., via data breach of logs) or intentionally (e.g., via subpoena).”

As a result, the Forum has voiced a preference for mandating the use of a certificate revocation status-checking method that favors privacy (i.e., a CRL list).

2. OCSP Issues and Financial Considerations

The issues regarding OCSP extend beyond privacy concerns; performance issues and costs were also key considerations. But performance isn’t a new issue; in 2017, we saw Firefox disable OCSP checking for domain (DV) and organization validation (OV) SSL/TLS certificates due to performance-related issues.

Where costs are concerned, CA/B Forum leaders further justify their decision in part by pointing out the continuing financial feasibility of OCSP: “Concern surrounding OCSP is further elevated considering the disproportionately high cost of offering these services reliably at the global scale of the Web PKI.”

Simply put, CRLs are less expensive and are considered consistent and reliable methods of certificate revocation status checks. In addition, they preserve privacy because the querying web client isn’t required to send information relating to a specific website.

What About OCSP Stapling?

OCSP stapling is a mechanism of incorporating proof of certificate validity directly into the TLS handshake to avoid a client having to reach out to the CA to double-check its accuracy. This helps to optimize performance and increases data privacy.

All of this sounds great, right? So, why isn’t there a bigger movement toward OCSP stapling? Frankly, it boils down to the low adoption and usage rates. But aside from that, there are additional pressing reasons.  

According to the discussions surrounding Ballot SC-63: 

“Independent of usage statistics, relying parties can’t consistently depend on OCSP stapling for security unless responses are stapled on all connections. Further, even if the web server ecosystem had improved support for OCSP-stapling and we could require the use of the ‘must-staple’ extension, we’d remain dependent upon robust and highly-reliable OCSP services, which have been an ongoing ecosystem challenge.”

OCSP vs CRL: Let’s Wrap This Up

We hope you’ve found this article informative in differentiating OCSP vs CRL revocation-checking methods. Both tools have their uses and will continue to be relied upon by businesses for years to come. The hope, though, is that the changes regarding short-lived certificates will help shrink the potential attack window open to cybercriminals. Furthermore, by not requiring the inclusion of these certificates in CRLs, it’ll likely decrease the size of the CRLs that organizations globally will increasingly rely upon. 

• #CRLs
• #OCSP
• #OCSP vs CRL