OCSP vs CRL: The Best Bet To Revoke Certificates In A PKI

Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) are different methods of verifying certificate status. While they have similarities, the modern choice between OCSP vs. CRL is clear: across all important categories, CRL outperforms OCSP.

In this article, we’ll explain how OCSP and CRLs work, compare their strengths and weaknesses, and examine why browsers, certificate authorities (CAs) and enterprise PKI deployments are increasingly picking CRLs over OCSP for modern certificate revocation.

Why Certificate Lifecycle Management Is Critical

Expired certificates can lead to outages that block legitimate users from accessing resources, while granting access with revoked certificates poses serious security issues. That’s why staying ahead of certificate lifecycle management is essential to a healthy and secure business.

But network administrators shouldn’t have to spend all their time performing certificate revocation status checks and monitoring revocation dates.

Instead, admins need certificate lifecycle automation systems that handle daily operations reliably and securely, keeping accounts and devices safe from unauthorized access.

With automated tools, manual OCSP and CRL checks aren’t the only way to confirm certificate validity.

What Is OCSP (Online Certificate Status Protocol)?

OCSP stands for Online Certificate Status Protocol. It’s a protocol described in RFC 6960 that can be used to request the revocation status of a specific digital certificate.

OCSP uses a Transport Layer Security (TLS) client to check live revocation status on demand. The client requests the status of one certificate and receives a signed response verifying that certificate’s validity with one of the following responses:

• Good: The certificate is currently valid
• Revoked: The certificate is revoked (response includes a reason code and timestamp)
• Unknown: The OCSP responder can’t determine the status of the certificate

Why Is OCSP Important?

OCSP is helpful because it delivers the real-time status of a specific certificate upon request.

OCSP was created to be more efficient than CRL (which we’ll explain shortly). And in some ways, it was. Unlike CRLs, with OCSP, admins didn’t have to review a list of all certificates to find one certificate status.

Unfortunately, large numbers of individual requests are resource-intensive and ultimately slow down OCSP responders. If the responder is overloaded or goes down, requests receive error messages. Meanwhile, users with revoked certificates may gain access.

This, along with privacy concerns and rising costs, has contributed to the gradual shift away from OCSP. In August 2023, the industry’s standard body for CAs and browsers (the CA/Browser Forum) made OCSP optional for CAs — but a valid CRL is mandatory.

How to Check Certificate Revocation Status With OCSP Requests

In OCSP, every authentication request requires the RADIUS server to do a lookup against the PKI using HTTP.

The OCSP response requires several operations on the PKI side, including digitally signing the OCSP response with a private key. This response is then sent back to the RADIUS server and requires another cryptographic operation, which is expensive in terms of server load, to verify the response.

One solution to minimize the lookup costs is a technique called “OCSP Stapling,” in which two of the necessary requests are combined to further enhance speed.

However, stapling is not supported for Wi-Fi client certificates. Furthermore, some implementations of OCSP are vulnerable to replay or man-in-the-middle attacks.

Here are the steps to check certificate revocation status with OCSP:

1. Client extracts CA-operated OCSP URL from a specific certificate’s embedded Authority Information Access (AIA) extension
2. Client creates an OCSP request with certificate serial number and issuer’s public-key and name hashes
3. Client sends request via HTTP GET (short requests) or HTTP POST (long requests)
4. OCSP server receives the request and references database to determine certificate status (CA updates database after each certificate revocation)
5. OCSP responder returns a digitally signed response with the certificate status (good, revoked, or unknown), validity period and responder’s signature
6. Client validates response signature against CA’s public key, proceeding with TLS handshake only if status is “good” and response is still within the validity period

What Is a CRL?

CRL stands for Certificate Revocation List. It’s exactly what it sounds like — a list of all the revoked certificates populated by the issuing CA.

But CRL is more than just a list; it’s an essential security tool. Once a specific certificate is revoked and its serial number appears on that list, any systems that reference the CRL will refuse to authenticate that certificate. That includes network equipment (like RADIUS servers) along with standard web browsers.

CRLs store the name of the issuing certificate authority, publication date of the latest CRL, date of the next updated CRL and the CA’s digital signature.

For every certificate revoked, CRL entries include the following details:

• Serial number of the revoked certificate
• Revocation date (not the original expiration date, but the date on which the CA invalidated the certificate)
• (Optional) Reason code explaining why the certificate was revoked

When a client requests a site’s certificate information, it accesses a specified CRL distribution point (CDP): the server-specific location of that CRL. If CDPs are unreachable, it’s almost impossible to check the current CRL.

Why Are CRLs Important?

CRLs matter because responsible certificate revocation keeps network resources, websites, and sensitive data safe, which is not possible without reliable certificate status checks.

As the modern industry standard, CRLs help protect publicly trusted CAs, organizations, application and website owners, and users from serious dangers.

Without reliable certificate revocation, compromised or fraudulently issued certificates may continue to be trusted, opening open the door to MITM attacks, exposing credentials and sensitive data such as financial records, credit card information and Social Security Numbers. Attackers may also use fraudulent certificates to distribute malware or trick users into downloading malicious software.

Cyberattacks like these can cause widespread data breaches, identity theft and impersonation, financial loss, data loss and diminished trust in an organization.

How to Check Certificate Revocation Status With CRL Distribution Points

In the CRL method for checking certificates, the client (such as a browser) requests authentication by a RADIUS server. The server communicates with the CRL and based on the certificate status, can either authorize or refuse access.

The diagram below shows the basic request process, but exact steps vary based on the nature of the request and what’s being accessed.

Here’s a specific example of how to reference a CRL to check certificate revocation status for access to a WPA2-Enterprise network with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication:

1. Client device presents digital certificate to wireless access point (AP).
2. AP forwards the certificate to RADIUS server.
3. RADIUS server verifies the certificate has not expired.
4. RADIUS server checks identity directory (such as Entra ID) to confirm the user is authorized.
5. RADIUS server downloads CRL or references cached copy, checking whether certificate’s serial number appears on it.
6. If certificate’s serial number appears on CRL, RADIUS server denies access.
7. If certificate passes all checks, server grants network access.

This process is much simpler with SecureW2 because our CRLs are pre-parsed for faster checks. The file is copied from our PKI at fixed intervals and requires a very simple public key decryption (verify signature) and a binary lookup of a serial id in a file.

Essentially, we skip the slow parts of a CRL check by doing the heavy lifting of the authentication event in advance.

Even if the file grew to a few hundred MB it would still be quicker to use the CRL because we use another improved CRL technique called “Delta + Base CRL”.

In this setup, a copy of the CRL is stored locally on the RADIUS server for quick reference (the Base CRL) and updated regularly, often during off-peak times. The update request returns the Delta CRL, a much smaller list that only contains changes to the Base CRL since the last update, significantly reducing the load.

The image below shows you the SecureW2 CRL technique.

OCSP vs. CRL: Key Differences

The table below summarizes how OCSP and CRL differ across the most important dimensions for network architects and PKI administrators.

	OCSP	CRL
Definition	Real-time protocol for querying certificate revocation status from a CA-operated responder	Periodically published list of revoked certificate serial numbers signed by the issuing CA
How it works	Client sends certificate status request to an OCSP responder; responder returns a signed good/revoked/unknown status	Client downloads the CRL file and checks the target certificate’s serial number against the list locally
Speed & bandwidth	Fast query but slower under load; requires a live round-trip per authentication event	Slow at first with large initial download, then faster at scale; CRL is cached locally and checked with a binary lookup
Frequency of checks	On demand for every request	Periodically
Privacy	Low. Each OCSP request reveals to the CA which certificate (and site) the user is accessing	High. No real-time reporting to the CA; the client checks the list locally
Network failure behavior (offline capability)	Poor. Authentication may fail or experience a soft fail if the OCSP responder is unreachable	Strong. Cached CRL continues to function during network interruptions, up to its validity period
OCSP stapling support	Supported for TLS web certificates; not supported for Wi-Fi client certificates	Not applicable
Drawbacks	Slow and expensive at scale, not private (CAs see user activity), revoked certificates may gain access if OCSP responder is down	Revoked certificates retain access until next list publication, clients must download and cache entire list to check certificate status, constant updates require frequent downloads
Best for	Short-lived TLS certificates where real-time status is critical	Wi-Fi, VPN, and RADIUS deployments where speed, privacy, and offline resilience matter

Why Browsers and CAs Are Moving Away From OCSP

Although it’s often considered an upgrade, the reality is that a lot of popular browsers don’t even use OCSP: Google Chrome uses a CRL; Firefox uses a CRL (admittedly, with a soft check for OCSP if the CRL fails).

Some OCSP configurations are just using a CRL under the hood for most operations because it tends to be faster.

Ultimately, the limiting factor in checking revoked certificates is typically network latency, not CPU cycles, so CRLs are shown to perform better across distributed networks.

OCSP had the potential to replace CRL, but in its current state, it is our belief that OCSP is an inferior solution for Wi-Fi security applications.

CAs are taking notice, too. Let’s Encrypt shut down its OCSP services in August 2025, and they’re not alone.

There are three main reasons CAs and browsers are phasing out OCSP.

Lack of Privacy With OCSP Responder

The privacy problem with OCSP is straightforward: every time a browser checks a certificate, it sends the certificate’s serial number to the CA’s OCSP responder. That responder now knows which site the user is visiting, at what time, and from what IP address.

At scale, OCSP creates a detailed browsing record held by a third-party CA. Google’s decision to move Chrome to CRLSets was driven in part by this concern, alongside performance considerations.

Poor Reliability During Outages

Reliability is the second factor. An OCSP responder is a live service, and live services go down.

When an OCSP responder is unreachable, browsers must choose between blocking the user (hard fail) or allowing the connection anyway (soft fail). Soft-fail behavior, which most browsers default to, means OCSP revocation checks provide limited real security value during outages.

Slow Performance at Scale

Performance at scale is the third factor. A CRL is downloaded once and cached locally. Every subsequent revocation check against that CRL is a local binary lookup, not a network round-trip.

Across a distributed enterprise network with hundreds of daily authentication events, the cumulative latency difference is significant.

As the existing SecureW2 analysis shows, the limiting factor in revocation checking is network latency, not CPU cycles, and CRLs win on that dimension.

OCSP vs. CRL for Wi-Fi and RADIUS Authentication

In the context of 802.1X authentication, the choice between OCSP vs. CRL is not just a performance question but a practical one.

OCSP stapling, which would otherwise reduce the per-authentication round-trip cost, is not supported for Wi-Fi client certificates. That removes the main performance mitigation that makes OCSP viable for web TLS.

RADIUS servers handling certificate-based authentication need to check revocation status for every device that connects. With OCSP, that means a live HTTP lookup against the PKI for each event.

With CRL and the Delta+Base CRL technique described above, the heavy cryptographic work is done in advance. The Base CRL is stored locally on the RADIUS server, and only the smaller Delta CRL is fetched during off-peak update cycles. The result is a revocation check that is both faster and more resilient to network interruptions than OCSP.

For organizations running a Dynamic PKI at scale, this matters even more. A managed PKI that issues certificates to thousands of devices generates a high volume of daily authentications. The per-event overhead of OCSP lookups compounds quickly, while the CRL-based approach keeps authentication latency flat regardless of certificate volume.

Schedule a demo to see how SecureW2 JoinNow Cloud RADIUS uses certificate-based authentication with optimized CRL checking for Wi-Fi and VPN deployments.

---

Frequently Asked Questions

Why are certificates revoked?

A CA may revoke a website certificate or other certificate ahead of its expiration date if:

• The certificate was fraudulent or wrongfully issued
• The certificate's private key was compromised
• The issuing CA was compromised
• The certificate was granted on the basis of false or misleading information
• The application or website owner violates terms with the CA
• The application or website owner relinquishes ownership

What is OCSP and how does it work?

OCSP (Online Certificate Status Protocol) is a real-time protocol defined in RFC 6960 for checking whether a digital certificate has been revoked.

A client sends a request containing the certificate’s serial number to an OCSP responder operated by the issuing CA. The responder returns a signed response indicating the certificate’s status: good, revoked, or unknown.

Unlike CRL, which is downloaded and cached locally, OCSP requires a live network connection for each check.

What is a Certificate Revocation List (CRL)?

A Certificate Revocation List (CRL) is a file published by a Certificate Authority (CA) that lists the serial numbers of all certificates the CA has revoked before their natural expiration.

Clients download the CRL and check it locally whenever they need to verify a certificate’s revocation status.

CRLs are signed by the issuing CA so their authenticity can be verified without a live connection to the CA.

What is the difference between OCSP and CRL?

OCSP checks revocation status of a single certificate in real time by querying a live CA-operated responder, while CRL is a periodically updated list of all revoked certificates, which clients download and check locally.

OCSP introduces per-authentication network latency and privacy trade-offs; CRL trades absolute real-time accuracy for speed, resilience, and privacy.

For most enterprise Wi-Fi and RADIUS deployments, CRL with Delta+Base updates performs better than OCSP.

What is OCSP stapling?

OCSP stapling is a TLS extension that allows a web server to obtain and cache a signed OCSP response from the CA, then attach (“staple”) it to the TLS handshake for the client. This eliminates the client’s need to contact the OCSP responder directly, improving both performance and privacy.

However, OCSP stapling applies only to web server TLS certificates. It is not supported for Wi-Fi client certificates used in 802.1X authentication.

Why are browsers shifting away from OCSP?

Browsers are moving away from OCSP primarily because of privacy concerns, reliability issues, and performance at scale. OCSP lookups disclose user browsing activity to third-party CAs. OCSP responder outages lead to soft-fail behavior that provides little real security value. And local CRL checks are faster than live OCSP round-trips at enterprise scale. Google Chrome, for example, uses its own CRL distribution mechanism (CRLSets) rather than relying on OCSP.

But browsers aren't the only ones shifting from OCSP — certificate authorities are, too. Let's Encrypt shut down its OCSP services in August 2025.

What are the disadvantages of OCSP?

The main disadvantages of OCSP include per-request latency from live network lookups; privacy exposure because the CA learns which certificates clients are checking; availability risk when OCSP responders go offline; and lack of support for stapling in Wi-Fi client certificate contexts.

In soft-fail mode, OCSP outages mean revocation checks are silently bypassed, which undermines the security value the protocol is intended to provide.

Are CRLs still used today?

Yes, CRLs are still used by browsers, applications, and certificate authorities today. In fact, in 2023, CA/Browser Forum's Ballot SC063 made CRLs mandatory for CAs.

CRLs provide a traceable record of certificate validity that isn't susceptible to OCSP's issues with privacy (CAs could monitor browser activity), reliability (when OCSP responders are down, users with revoked certificates may gain access), and latency (one certificate per request creates more requests overall), along with rising costs at scale.

Due to these OCSP deficiencies, CRL remains the modern standard for reliable certificate status checks.