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

A CRL certificate check is one of the most basic safeguards in public key infrastructure (PKI). When a digital certificate is compromised, incorrectly issued or no longer trusted, the certificate authority (CA) adds it to a certificate revocation list, a signed, timestamped file that tells every relying party to stop trusting that credential.

If your network relies on X.509 certificates for Wi-Fi, virtual private network (VPN), or application access, then understanding how CRLs work and where they fall short is essential. This guide covers what a CRL is and how it fits into certificate-based authentication. We’ll also explain the standard revocation reason codes defined in RFC 5280, and the alternatives (OCSP, OCSP stapling, delta CRLs) that address its limitations.

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 PKI trust hierarchy, where authority flows from the CA. Only the CA that originally issued a certificate 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 are often confused, but they serve different purposes in the certificate lifecycle.

Certificate expiration happens automatically. Every certificate is issued with a validity period, typically one to three years for enterprise certificates. When that window closes, the operating system or RADIUS server rejects the certificate without consulting the CRL.

Certificate revocation is a deliberate action taken before a certificate expires. A CA revokes a certificate when the private key is compromised, an employee leaves the organization, a device is decommissioned or the certificate was issued in error. Certificates may be either temporarily or irreversibly revoked.

Expired certificates never appear on a CRL, because they are already invalid. And certificates that expire while sitting on a CRL are automatically pruned from the list.

This keeps the CRL from growing indefinitely, which matters because list size directly affects authentication speed.

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.

How CRL Checks Work in Certificate-Based Authentication

The CRL check happens at a specific point in the authentication handshake. Let’s look at two common examples: Wi-Fi connections and web browsers.

How RADIUS Servers Check CRLs for Wi-Fi Authentication

Here’s how a client device requests and receives authentication on a typical WPA2-Enterprise network using EAP-TLS, the protocol most enterprises use for certificate-based 802.1X authentication.

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

How Web Browsers and Applications Check CRLs for SSL/TLS Certificates

Here’s how a browser or application verifies a website’s Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificate. They do so with a TLS handshake: a communication between client and server to authenticate identities and ensure a secure connection.

1. Client and server exchange a series of “hello” messages to agree on parameters for the secure connection.
2. The server presents a digital certificate with a public key, issued by a publicly trusted CA.
3. In mutual authentication, the client may also present its certificate.
4. Client authenticates server certificate by comparing its signature against the issuing certificate authority’s public key.
5. If the keys don’t match, the handshake ends; no connection is established.
6. If the keys match, ephemeral key exchange occurs. (In TLS 1.2 and earlier, static RSA key exchange was possible, but TLS 1.3 removed it due to security concerns.)
7. Server decrypts the message with its corresponding private key, establishing a shared secret and chain of trust.
8. Client connects with CRL issuer (CA) and downloads CRL to ensure the server certificate is valid.
9. If certificate has been revoked, the handshake ends; no connection is established.
10. If certificate has not been revoked, the chain of trust is established; client authenticates server certificate and authorizes a connection.

CRL Distribution Points: How Clients Retrieve Revocation Data

Every X.509 certificate contains 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 are the most common. The CA publishes the CRL to a web server, and clients fetch it over standard HTTPS.
• LDAP-based CDPs 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 1 to 24 hours.

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.

Why Does a Digital Certificate Get Revoked?

CRL entries may include a reason code explaining why the certificate was revoked. These codes are defined in RFC 5280, the specification that governs X.509 certificates and CRLs. Administrators reference these codes when deciding whether to reissue a certificate or keep it permanently revoked.

Here are the ten reason codes defined in RFC 5280:

• unspecified (0): The default, catch-all code when no specific reason applies.
• keyCompromise (1): The certificate’s private key was compromised — lost, stolen or extracted.
• cACompromise (2): The issuing CA itself was compromised, which means every certificate it ever issued is now suspect.
• affiliationChanged (3): The certificate holder’s organizational affiliation changed — most commonly, an employee left the company.
• superseded (4): A new certificate replaced the old one, usually because user information (name, department, role) changed.
• cessationOfOperation (5): The service or system the certificate was bound to has been decommissioned.
• certificateHold (6): The certificate is temporarily suspended. Unlike other codes, this revocation can be reversed.
• removeFromCRL (8): Used to remove a certificate from hold status on the next CRL update.
• privilegeWithdrawn (9): The user or device had its access privileges removed — common during offboarding or device retirement.
• aACompromise (10): The attribute authority (AA) that validated the certificate’s attributes was compromised.

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:

	CRL	OCSP	OCSP Stapling
How it works	Client downloads the full revocation list from the CDP	Client queries an OCSP responder for a single certificate’s status	Server pre-fetches the OCSP response and delivers it during the TLS handshake
Response size	Large (grows with every revocation)	Small (one certificate per query)	Small (one certificate per query)
Latency	Higher for large lists	Lower per-query	Lowest — no extra round trip for the client
Privacy	No CA involvement at validation time	CA sees every query (knows which sites you visit)	CA only sees queries from the server, not end users
Freshness	Updated on a schedule (hours to days)	Near real-time	Depends on server’s refresh interval
Failure mode	Stale if cache expires and CDP unreachable	Soft-fail risk if responder is down	Soft-fail risk if server does not staple

How Does OCSP Work?

OSCP (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?

OSCP stapling solves the privacy problem introduced by OSCP. 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.

CRL Limitations in Enterprise Networks

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

• Latency between revocation and propagation: When a CA revokes a certificate, the updated CRL is not available until the next scheduled publication which may be hours or even a full day away. During that window, a revoked certificate can still authenticate successfully against a cached CRL.
• List bloat: Organizations with thousands of certificates and frequent revocations accumulate large CRLs. A list with 100,000 entries can exceed several megabytes, and every RADIUS server on the network needs to download and parse it.
• Delta CRL complexity: Delta CRLs (lists containing only changes since the last base CRL) reduce download size, but they add operational complexity. The RADIUS server must maintain both the base CRL and every delta CRL issued since the last base refresh, and a missed delta can cause validation errors.
• CDP availability: If the CRL distribution point goes offline, some clients hard-fail (deny access) while others soft-fail (allow access without proper revocation checking). Neither behavior is ideal.
• No real-time identity context: A CRL tells you whether a certificate was revoked. It does not tell you whether the device fell out of MDM compliance, the certificate’s usage pattern looks anomalous, or the user behind that certificate was disabled in your identity provider five minutes ago. This can lead to authentication of recently revoked certificates.

These gaps are the reason enterprises are moving toward real-time revocation models, where the RADIUS server checks the identity provider and device posture at the moment of authentication, not hours later.

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 revocation 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.

---

Frequently Asked Questions

What does CRL stand for in certificates?

CRL stands for certificate revocation list. It is a signed file published by a certificate authority (CA) that lists the serial numbers of digital certificates revoked before their scheduled expiration date. Any system that checks the CRL, whether a RADIUS server, browser, or VPN gateway, will reject a certificate whose serial number appears on the list.

How do I find the CRL of a certificate?

To find the CRL for a specific certificate, view the certificate details and look for its CRL Distribution Point (CDP): a URL indicating where to access the issuing CA's CRL files. However, certificate management tools such as the SecureW2 Management Portal can automate the lookup process, confirming certificate status with a valid CRL.

How often is a CRL updated?

CRL update frequency depends on the CA's configuration. Most CAs publish a new CRL every 1 to 24 hours. The "Next Update" field in the CRL tells clients when to expect a fresh version. Some CAs also publish delta CRLs between base CRL updates to distribute changes faster.

What is the difference between CRL and OCSP?

A CRL is a downloadable file containing every revoked certificate's serial number. OCSP is a protocol that lets a client query the CA for the status of a single certificate. CRLs are larger, but validation happens entirely on the client side, with no outbound request to the CA. OCSP responses are smaller and closer to real-time, but introduce privacy concerns because the CA sees every query.

What is the difference between CRL and certificate transparency logs?

Both CRLs and certificate transparency logs (CT logs) store X.509 certificate information, but they store different certificate details for different purposes. CT logs store details of all certificates issued for a specific domain, whether or not they've been revoked. Conversely, CRLs only store the details of revoked certificates; they don't include active or expired certificates.

What happens if the CRL is unavailable during authentication?

Behavior varies by implementation. Some systems "hard fail" and deny access when they cannot reach the CRL distribution point. Others "soft fail" and accept the certificate without a revocation check. Hard-fail is more secure but can cause outages if the CDP goes down. Cloud-based RADIUS services with built-in identity lookups reduce dependency on CRL availability.

Can a revoked certificate be reinstated?

Only certificates revoked with reason code 6 (certificateHold) can be reinstated. A certificate on hold is temporarily suspended, and the CA can remove it from the CRL on the next update using reason code 8 (removeFromCRL). Certificates revoked for any other reason, such as key compromise or affiliation change, are permanently revoked.