What is a Certificate Revocation List (CRL)? OCSP, CRL, SSL

We’ve spent years helping IT teams troubleshoot certificate-based Wi-Fi and VPN deployments, and CRL issues come up more often than most people expect. A certificate revocation list (CRL) is a signed list published by a certificate authority (CA) that identifies certificates that have been revoked before their expiration date.

We’ve seen revoked certificates that still authenticate because a cached CRL hadn’t updated yet, RADIUS servers that slow down under a bloated CRL, and distribution points that go offline at the worst possible time. Understanding how CRLs work, how systems check them and where they fall short can help IT teams avoid these problems.

This guide breaks down how CRLs actually work in practice, the reason codes defined in RFC 5280 and where CRLs fall short compared to Online Certificate Status Protocol (OCSP) and OCSP stapling.

What Is a Certificate Revocation List?

A certificate revocation list (CRL) is a digitally signed log of every certificate the publishing certificate authority (CA) has revoked before its scheduled expiration date. CAs may revoke certificates and place them on a CRL due to wrongful issuing, compromised data (such as its private key) or other scenarios where client/server trust is lost.

CRLs are managed entirely within the Publick Key Infrastructure (PKI) trust hierarchy, where authority flows from the CA. Only the CA that originally issued a certificate, or an authority explicitly delegated by that CA, has the authority to revoke it.

Once a certificate’s serial number appears on the CRL, any system that checks the list, such as a RADIUS server, a web browser or a VPN gateway, will reject authentication attempts that present that certificate.

Each CRL entry includes:

• Serial number of the revoked certificate
• Revocation date — when the CA declared it invalid
• Reason code (optional) — a standardized code from RFC 5280 explaining why (see the full list below)

The CRL itself also carries metadata, such as the issuing CA’s distinguished name, the date the list was published, the date the next update is expected and the CA’s digital signature to prevent tampering.

Notably, CRLs do not include expired certificates. In the next section, we’ll check out the difference between expired and revoked certificates.

Certificate Revocation vs. Certificate Expiration

These two concepts get confused often, but they serve different purposes in the certificate lifecycle. The table below highlights the key differences.

Why Are CRLs Important?

CRLs are important because they warn users that a site, application or network may be unsafe. Verifying the validity of certificates protects organizations, devices and end-users from man-in-the-middle (MITM) attacks that can compromise credentials and private data.

When untrustworthy connections occur, they can lead to data breaches, identity theft, loss of data and lost revenue.

How CRL and PKI Work Together

Public Key Infrastructure (PKI) uses digital certificates and advanced encryption to protect virtual communications and data exchanges. CRLs allow PKI tools to determine the validity and trustworthiness of every certificate, protecting the PKI and the organization.

As part of a healthy PKI framework, a dependable CRL minimizes security risks and builds trust with certificate-verifying entities.

Certificate revocation sounds simple in theory, but managing it in a real PKI environment is harder

The video below explains the challenges IT and security teams face when deciding when to revoke a certificate and how those decisions can affect access to Wi-Fi, VPNs and applications.

How Certificate Revocation Lists Work

A CA issues a certificate with an expiration date, but things can happen before that date arrives, such as a private key gets stolen, an employee leaves or a certificate gets issued in error.

The CA needs a way to say “stop trusting this” before the certificate naturally expires. A CRL is that mechanism, a published list of certificates that the CA has revoked early.

Here’s how it plays out:

1. The CA can revoke a certificate when it is no longer trustworthy due to a key compromise, offboarding, an issuance error or another reason.
2. The CA adds the revoked certificate’s serial number to its CRL and publishes the updated list.
3. A device later tries to use that certificate, for example, when connecting to corporate Wi-Fi.
4. The verifying system, usually a RADIUS server, checks the CRL for that certificate’s serial number.
5. The system finds the certificate’s serial number on the CRL and determines that the certificate has been revoked.
6. Access is denied, even though the certificate has not expired.

For certificates that have not been revoked, their serial numbers do not appear on the CRL, so the authentication process can continue.

The flowchart below illustrates the process.

One distinction worth remembering is that revocation happens once, when the CA updates the list. Rejection happens every time someone tries to use that revoked certificate because the check runs fresh each time. The CRL is what makes that repeated rejection possible without the CA stepping in manually on every attempt.

CRL Structure and Contents

Per RFC 5280, a CRL contains several fields that provide information about the issuer, publication timing and revoked certificates. Key fields are included in the table below.

Expired certificates drop off the list once their validity period ends, since they’d be rejected for expiration anyway. This is configurable by the CA.

CRL Entries and Revocation Reason Codes

When a CA revokes an X.509 certificate, it assigns a reason code defined in RFC 5280, the core specification governing digital certificates and CRLs.

These codes provide crucial context during audits, help determine if signatures created prior to revocation remain trustworthy and guide administrators on whether a certificate should be reissued or permanently retired.

Understanding these specific reason codes helps security teams distinguish between routine operational updates (like a role change or planned decommission) and severe security events (such as key exposure), ensuring swift and appropriate remediation actions.

How to Check a Certificate Revocation List

Checking a CRL manually is straightforward. The process involves locating the CRL, verifying its authenticity and checking whether the certificate’s serial number appears on the list.

Here’s how to check a CRL:

• Find the CRL Distribution Point (CDP) URL listed in the certificate’s extensions.
• Download the CRL file from that URL, usually over HTTP or LDAP.
• Verify the CA’s digital signature on the CRL to confirm it hasn’t been altered.
• Search the list for the certificate’s serial number.
• If the serial number appears, treat the certificate as revoked and stop trusting it.
• If it doesn’t appear, and the certificate hasn’t expired, it’s still valid.
• Most systems, browsers, RADIUS servers, VPN clients, do all this automatically. A manual check is mainly useful for troubleshooting or audits.

Types of Certificate Revocation Lists

There are several types of CRLs, each designed for a different revocation scenario:

What Is the CRL Lifecycle?

A CRL isn’t a static file. It goes through its own cycle of publication, updates and eventual replacement.

• Updates: Each time a CA revokes a certificate, that revocation needs to make it into a published CRL before relying parties can act on it. Some CAs update the base CRL directly. Others publish delta CRLs between base updates, so changes propagate faster without a full re-download.
• Expiration: Every CRL carries a “next update” field telling relying parties when to expect a fresh version. Once that time passes, cached copies are considered stale, and clients are expected to fetch a new one before trusting it further.
• Frequency: Commonly, CAs publish a new CRL every few hours to a few days, though this varies by CA policy and how often revocations happen. High-security environments often publish more frequently, while lower-risk environments can get away with a longer refresh window.

CRL Distribution Points: How Clients Retrieve Revocation Data

Most X.509 certificates contain a field called the CRL Distribution Point (CDP): an HTTP or LDAP server location holding one or more URLs where the CA publishes its current CRL.

When a relying party, such as a RADIUS server, a browser or a VPN concentrator, needs to verify a certificate, it reads the CDP from the certificate and downloads the corresponding CA’s CRL from that location.

Here’s how distribution works in practice:

• HTTP-based CDPs: These CDPs are the most common. The CA publishes the CRL to a web server, and clients fetch it over plain HTTP.
• LDAP-based CDPs: These are used in Microsoft Active Directory environments. The CRL is published to a directory service accessible within the corporate network.
• Caching: Most clients cache the CRL locally and refresh it based on the “Next Update” field in the CRL itself. A typical refresh interval is every few hours to a few days.

If the CDP is unreachable due to a downed server, network segmentation or a blocking firewall rule, some clients will “soft fail” (accept the certificate anyway) while others will “hard fail” (deny access). This inconsistency is one of the operational headaches that CRL-dependent systems create.

CRL vs. OCSP vs. OCSP Stapling

CRLs are not the only way to check certificate revocation status. Two alternatives, Online Certificate Status Protocol (OCSP) and OCSP stapling, address different limitations of the CRL model.

The basic difference between OCSP vs CRL is that CRLs are periodically updated lists of all revoked certificates, while OCSP requests check the real-time status of specific certificates on demand. OCSP stapling improves latency for high volumes of individual OCSP requests.

But there’s more to it than that, including privacy concerns with OCSP. Let’s compare:

How Does OCSP Work?

OCSP (defined in RFC 6960) lets a client ask a single question — “Is this certificate revoked?” — and receive a signed “good,” “revoked” or “unknown” response.

It is faster per-query than downloading an entire CRL but introduces a privacy issue: the OCSP responder (usually operated by the CA) sees every certificate check, which means it can track which sites a user visits.

How Does OCSP Stapling Work?

OCSP stapling solves the privacy problem introduced by OCSP. The server periodically fetches its own OCSP response from the CA and “staples” it to the TLS handshake. The client gets the revocation status without ever contacting the CA directly.

For enterprise Wi-Fi and VPN networks that use private PKI and EAP-TLS, CRL certificate checks through the RADIUS server remain the most common method. OCSP and OCSP stapling are more prevalent in web TLS (browser-to-server) scenarios.

See our video for more information on OCSP vs. CRL.

Benefits of CRL

The following are some of the benefits of CRLs:

• CRLs work without needing a live connection to the CA at the moment of validation.
• They give administrators a documented, auditable record of every certificate revoked and why.
• CRLs are supported by nearly every system that handles X.509 certificates, including RADIUS, VPNs and OS trust stores, making them broadly compatible across these environments.
• Once downloaded, a CRL can be cached and reused for multiple checks, which cuts down on network overhead.
• The signed format makes tampering easy to detect.
• Reason codes give context for each revocation, which helps with audits and incident reviews.

CRL Limitations in Enterprise Networks

CRLs work, but they have operational gaps and drawbacks that compound at enterprise scale:

• A revoked certificate can still authenticate if the updated CRL hasn’t been published yet, since updates only happen on a schedule.
• Large organizations with frequent revocations end up with bloated CRLs, and a list with 100,000 entries runs to several megabytes.
• Delta CRLs cut download size, but the RADIUS server still has to hold a current base CRL and merge the latest delta against it, and a stale or unreachable delta leaves it validating against out-of-date revocation data.
• If the CRL distribution point goes offline, some clients deny access outright while others let the certificate through unchecked, and neither outcome is good.
• A CRL only confirms certificate status. It says nothing about whether the user was just disabled in the identity provider or whether the device fell out of compliance.

CRLs Are Replacing OCSP for Certificate Revocation

For many years, OCSP was often considered the better option because it could check a certificate’s status in real time without downloading an entire revocation list.

That approach has now changed. In July 2023, the CA/Browser Forum approved Ballot SC-063, making OCSP optional for publicly trusted CAs while making CRLs mandatory.

The new requirements took effect in March 2024, marking a major shift in how certificate revocation is expected to work going forward.

The decision was driven by several long-standing issues with OCSP. Every OCSP request reveals which certificate a client is checking, creating privacy concerns. OCSP also depends on highly available responder servers, increasing operational costs for CAs.

More importantly, many applications use soft-fail behavior. If the OCSP responder cannot be reached, the certificate is often treated as valid instead of being rejected. This can allow revoked certificates to continue to be trusted.

Info: The industry has already started adopting this new approach. Let’s Encrypt stopped providing OCSP services in August 2025. Certificates issued after that point rely on CRLs for revocation information instead of OCSP.

For organizations running an internal PKI, these public CA requirements do not apply directly. However, the same operational lessons are relevant.

In certificate-based EAP-TLS deployments, RADIUS servers can download and cache CRLs locally. This allows them to continue checking revoked certificates even if the issuing CA is temporarily unavailable.

By comparison, an OCSP-based deployment may accept revoked certificates if the responder cannot be contacted and soft-fail behavior is enabled.

As more public CAs move away from OCSP, CRLs are becoming the primary revocation mechanism for modern PKI deployments.

Note: Organizations designing or updating certificate-based authentication should treat CRL distribution and management as a core part of their PKI strategy, rather than relying solely on OCSP for certificate validation.

How SecureW2 Handles Certificate Revocation

SecureW2 JoinNow Cloud RADIUS does not rely solely on CRL checks to determine whether a certificate should be trusted.

At every authentication event, Cloud RADIUS performs a real-time identity lookup against the organization’s identity provider to verify the user is still active and the device is still compliant.

All major identity providers are supported, including Entra ID, Okta and Google Workspace.

The effect is immediate. If an administrator disables a user in Entra ID at 2:00 PM, that user’s certificate stops working at 2:00 PM, not at the next CRL refresh cycle.

JoinNow Dynamic PKI also includes CertIQ ML Anomaly Detection, which monitors certificate usage patterns across the network. CertIQ flags certificates that appear in unexpected locations, authenticate at unusual times, or exhibit behavior inconsistent with the enrolled identity. This is a layer of defense that static CRLs cannot provide: it catches misuse that no one thought to revoke.

The result is a revocation model that combines traditional CRL support (for compatibility with third-party systems) with real-time identity checks and behavioral anomaly detection.

Move Beyond Static Revocation Lists

CRLs are a foundational part of PKI, but they were designed for a slower era, where hourly or daily revocation updates were acceptable.

Modern enterprise networks need to know whether a certificate, a user and a device are all trustworthy at the moment of connection, not based on a cached list from this morning.

Cloud RADIUS and Dynamic PKI give you both: full CRL compatibility for interoperability with existing systems, plus real-time identity lookups and CertIQ ML anomaly detection that close the gaps CRLs leave open.

Schedule a demo to see how real-time certificate validation works in your environment.