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, VPN, or application access, then understanding how CRLs work and where they fall short is essential. This guide covers what a CRL is, 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 file published by a certificate authority that contains the serial numbers of every certificate it has revoked before the certificate’s scheduled expiration date.

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—a RADIUS server, a web browser, 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.

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.

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.

How CRL Checks Work in Certificate-Based Authentication

The CRL check happens at a specific point in the authentication handshake. Here is how it plays out on a typical WPA2-Enterprise network using EAP-TLS, the protocol most enterprises use for certificate-based Wi-Fi 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.

CRL Distribution Points: How Clients Retrieve Revocation Data

Every X.509 certificate contains a field called the CRL Distribution Point (CDP). This field holds one or more URLs (typically HTTP or LDAP) where the CA publishes its current CRL.

When a relying party, like a RADIUS server, a browser, or a VPN concentrator, needs to verify a certificate, it reads the CDP from the certificate and downloads the 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.

RFC 5280 Revocation Reason Codes

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): Catch-all code when no specific reason applies. Typically the default.
• 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, OCSP and OCSP stapling, address different limitations of the CRL model.

 

	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 (Online Certificate Status Protocol, 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 itself 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 checks through the RADIUS server remain the most common method. OCSP and OCSP stapling are more prevalent in web TLS (browser-to-server) scenarios.

CRL Limitations in Enterprise Networks

CRLs work, but they have operational gaps 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 5 MB, 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 a revocation check). 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 user behind that certificate was disabled in your identity provider five minutes ago, whether the device fell out of MDM compliance, or whether the certificate’s usage pattern looks anomalous.

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, ad 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.

SecureW2 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. Or explore our pricing to find a plan that fits your organization.

---

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