The Hidden Risks of Expired Certificate Revocation Lists (CRL)

Quick answer: A Certificate Revocation List (CRL) is a signed, published list that a Certificate Authority uses to tell relying systems which certificates should no longer be trusted, even though they have not yet expired. Systems that check certificates against a CRL are protected against compromised or misissued certificates. Systems that rely on an expired, unreachable, or stale CRL are not, because they have no reliable way to see that a certificate has already been revoked.

Digital certificates are the identity documents of the internet. They let a browser or server confirm that the website, API, or application on the other end of a connection is who it claims to be, and every certificate carries a fixed expiry date that limits how long it can be trusted. But certificates do not always make it to that expiry date safely. A private key can leak, a domain can change hands, or a Certification Authority can discover it issued a certificate in error. When that happens, the certificate has to be killed off early, and the mechanism that does the killing is the Certificate Revocation List.

Executive Summary

An expired or unreachable Certificate Revocation List (CRL) breaks the one mechanism relying systems have for rejecting a compromised or misissued certificate before its scheduled expiry. The risk is compounding: Let’s Encrypt shut down its OCSP service on August 6, 2025, consolidating revocation checking almost entirely onto CRLs, and DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations had certificate-related downtime in the past year, with 37.5% traced to an expired certificate (Source: DigiCert Trust Pulse Survey, July 2025). Machine identities requiring certificates now outnumber human identities 109 to 1 (Source: Palo Alto Networks 2026 Identity Security Landscape Report), which means the renewal and monitoring workload behind every CRL and CDP endpoint keeps growing even as the CA/Browser Forum phases maximum public TLS certificate validity down to 200 days in March 2026, 100 days in March 2027, and 47-day TLS certificates by March 2029 (Source: CA/Browser Forum ballot, via Sectigo). Manual tracking cannot catch a stale CRL at that scale. Automated certificate discovery and certificate automation close that gap, and the same inventory discipline that keeps CRLs healthy also underpins crypto agility and PQC readiness: a live CBOM gives security and compliance teams the same continuous visibility.

Jump to: Risk Matrix | Impact by Team | What to Do Next | How Encryption Consulting Can Help | FAQ

Key Takeaways

• A CRL is a signed list, published by a CA, naming every certificate that has been invalidated before its scheduled expiry.
• An expired, offline, or misconfigured CRL means relying systems can keep trusting a certificate that has already been revoked, or reject valid ones by mistake.
• Let’s Encrypt turned off its OCSP service on August 6, 2025, and now publishes revocation status only through CRLs, a direction the CA/Browser Forum has been pushing the whole industry toward.
• CA/Browser Forum Ballot SC-081v3 is cutting maximum TLS certificate validity to 47 days by March 2029, which shrinks the exposure window but does not remove the need for revocation checking on standard certificates.
• Continuous monitoring, such as the PKI health checks in CertSecure Manager, can flag a failing CRL or CDP/AIA endpoint before it causes an outage or a compliance finding.

How a Certificate Revocation List Works

A CRL exists because a certificate’s expiry date only tells you when it will stop being valid, not whether it should already be treated as dead. Public key infrastructure (PKI) needs a second channel for that, and the CRL is the oldest and still most widely deployed one. It works like a blacklist: the CA maintains it, updates it whenever a certificate is revoked, and signs it so that anyone downloading it can confirm the list has not been tampered with.

Steps Involved in Building and Publishing a CRL

• Revocation request:

  The certificate holder, or someone acting on their behalf, notifies the issuing CA that a certificate needs to be revoked. Common reasons include key compromise, misuse, or the certificate holder no longer controlling the domain. The request typically includes the certificate’s serial number and the reason for revocation.

• Verification:

  The CA checks that the revocation request is legitimate. Once it confirms this, it marks the certificate as revoked in its internal records.

• List update and signing:

  The CA adds the certificate’s serial number to its CRL and signs the updated list with its private key, so relying parties can verify the CRL itself has not been altered.

• Publication:

  The signed CRL is published at a location relying parties can reach, most often a web server referenced in the certificate’s CRL Distribution Point (CDP), and sometimes via LDAP.

• Distribution:

  Browsers, servers, and other relying software periodically download the current CRL from the location the certificate points to.

• Usage:

  When a relying system encounters a certificate, it checks the certificate’s serial number against the downloaded CRL. A match means the certificate is treated as revoked, regardless of what its expiry date says.

How to Check a Certificate’s Revocation Status

Every publicly trusted certificate points to the CRL that covers it, through a field called the CRL Distribution Point. You can find that field yourself, either by opening a downloaded certificate directly or by inspecting one presented by a website.

To check a website’s certificate, click the padlock icon next to the address bar, then follow these steps:

1. Click “Connection is secure,” then open the certificate details.
2. Scroll to the CRL Distribution Points (CDP) field.
3. Note the URL or URLs listed there, which point to where the CA publishes its CRL.
4. Copy a URL and paste it into your browser’s address bar.
5. Your browser will download the CRL file, which you can inspect for the current revocation list.

Risks of an Expired or Unreachable CRL

Security Risk: Accepting a Revoked Certificate

If a CRL is outdated or expired, systems relying on it have no way to see that a certificate was revoked after the CRL’s last update. A compromised or invalid certificate can then be accepted as trustworthy, which is exactly the vulnerability revocation checking exists to prevent.

Operational Risk: Service and Compliance Issues

Many servers and applications are configured to always check for a valid CRL before accepting a certificate. If the CRL has expired, these systems may reject certificates automatically, causing outages and service interruptions rather than security gaps. On the compliance side, several regulatory frameworks require CAs and relying organizations to keep revocation checking current; falling behind on that can lead to audit findings and financial penalties.

Trust and Revenue Risk

When a system cannot reliably confirm a certificate’s status, it undermines confidence in every connection that certificate protects. For a customer facing service, that translates directly into lost transactions and lost trust, since users and downstream systems can no longer be certain the certificate they are relying on is genuinely valid.

The table below summarizes these risks as a single reference: what causes each failure, what it costs the business, how teams typically detect it, how to mitigate it, who should own the fix, and where the evidence for the claim comes from.

Cause	Business Impact	Detection Method	Mitigation	Owner	Evidence Source
CRL past its “next update” timestamp but still served	A revoked certificate is silently trusted as valid, exposing systems to a compromised or misissued credential	Automated CRL freshness checks against the CDP endpoint	Alert before the next-update timestamp passes; automate republishing on a fixed cadence	PKI Team	Post body: How a CRL Works
CDP or AIA endpoint unreachable	Relying software cannot fetch the CRL at all, and most browsers soft fail, granting trust with no actual revocation check	Endpoint uptime monitoring on every CDP/AIA URL	Host CDP/AIA on redundant, monitored infrastructure with alerting on failure	Platform and Infrastructure Team	Post body: Security Risk section
Strict-fail systems reject certificates once their CRL expires	Legitimate services go offline even though nothing was actually compromised	Correlate outage tickets with CRL expiry logs	Track remaining CRL lifetime centrally and refresh well ahead of expiry	Security Team	Post body: Operational Risk section
Industry consolidation onto CRL-only revocation (OCSP retirement)	A CRL failure is now the only revocation channel, not one of two	Track CA and browser policy announcements	Treat CRL monitoring as a baseline control, not a secondary check	Compliance Team	Let’s Encrypt, OCSP service end of life, August 6, 2025
Shrinking certificate validity without matching revocation monitoring	Teams assume shorter lifetimes make CRL health less urgent, leaving the same proportional exposure window	Audit revocation monitoring coverage against certificate lifespan	Maintain revocation monitoring for every certificate longer than seven days, regardless of validity period	PKI Team	CA/Browser Forum Ballot SC-081v3

Why CRL Health Matters More Now, Not Less

Revocation checking has been quietly consolidating around CRLs over the past two years, which raises the stakes for keeping them healthy. Let’s Encrypt shut down its OCSP responders on August 6, 2025, after removing OCSP URLs from newly issued certificates that May, and now publishes revocation information exclusively through CRLs. The CA/Browser Forum has moved in the same direction, downgrading OCSP support to optional for CAs while keeping CRL publication a baseline requirement. For organizations that run their own CRL infrastructure or depend on a CA’s CRL, that shift means a CRL failure is no longer one of two revocation channels going down. Increasingly, it is the only one.

Shorter certificate lifespans are part of the same story, but they are not a substitute for revocation checking. Under CA/Browser Forum Ballot SC-081v3, maximum TLS certificate validity drops to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029. Certificates issued with a lifetime of seven days or less are exempt from CRL and OCSP requirements entirely, because they simply expire before revocation would matter. Everything issued on a standard schedule still needs a working revocation channel for its full lifetime, and a 47-day certificate with an expired CRL is exposed for just as long, proportionally, as a 398-day certificate was under the old rules. In our experience advising teams on certificate lifecycle programs, the organizations that get caught out are rarely the ones ignoring revocation on purpose. They are the ones who assumed shorter lifetimes made CRL monitoring less urgent and stopped watching it.

The cost of getting this wrong is not hypothetical. When Sectigo’s AddTrust External CA Root expired on May 30, 2020, it broke certificate validation for a wide range of production systems, including Sophos firewalls and several unrelated consumer and enterprise services, because the expiration of an old trust-chain component was not being actively monitored (Source: Sectigo knowledge base, AddTrust External CA Root Expiring May 30, 2020). It was a root certificate expiration rather than a CRL specifically, but the failure pattern is identical to a stale CRL: a piece of PKI infrastructure that relying systems depend on silently lapses, and nobody catches it until production traffic starts failing.

Who Owns This: Impact and Action by Team

CRL health does not belong to one team. Each function below owns a distinct piece of keeping revocation checking reliable.

Team	What Changes For Them	Immediate Action
PKI Team	Owns CRL publication, signing, and refresh cadence for every CA in the environment	Inventory every CA and confirm each CRL’s next-update timestamp is tracked centrally
Security Team	Depends on CRL and CDP/AIA monitoring to catch a revoked certificate before it is wrongly trusted	Confirm certificate transparency and revocation monitoring cover every CA in scope
Platform and Infrastructure Team	Runs the servers and network paths that host and reach CDP/AIA endpoints	Verify CDP/AIA endpoints are on monitored, redundant infrastructure with uptime alerts
Compliance Team	Uses CRL health evidence to demonstrate current revocation checking during audits	Confirm audit evidence can show CRL freshness on demand, not just after a manual pull

What to Do Next

• PKI teams: Confirm every CA’s CRL next-update timestamp is tracked and refreshed well ahead of expiry, not discovered after a validation failure.
• Security teams: Validate that CDP and AIA endpoints are monitored for reachability, not just certificate expiration.
• Platform and infrastructure teams: Move CDP/AIA hosting onto redundant infrastructure so a single outage cannot take revocation checking offline.
• Compliance teams: Confirm CRL health reporting can be produced on demand as audit evidence, matching the cadence your framework requires.

How Encryption Consulting Can Help

CertSecure Manager gives teams a PKI health view built to catch exactly this kind of failure before it reaches production. Here is what that looks like in practice:

CertSecure Manager runs a detailed check across every Certification Authority component, surfacing CDP and AIA endpoints along with how many days remain before each CRL expires. When it detects a problem, it alerts administrators automatically instead of waiting for someone to notice a validation failure downstream.

• Full CA health check: CertSecure Manager verifies every certification authority component and gives you one centralized view of overall PKI health.
• CDP and AIA visibility: It identifies the CRL Distribution Point and Authority Information Access endpoints so you always know where a certificate’s revocation data lives.
• Remaining CRL lifetime: It shows how much time is left before a CRL expires, giving administrators a window to refresh it before it becomes a liability.
• Automated alerts: CertSecure Manager notifies administrators of upcoming CRL expirations and flags incidents when a revocation check fails, closing the gap between a problem occurring and someone finding out about it.

Where certificate readiness intersects with broader cryptographic risk, our PQC Center of Excellence uses the same certificate and CA inventory to help sequence a post-quantum migration, and our guidance on turning a CBOM into an operational capability keeps that inventory current long after the initial PKI health rollout.

Conclusion

A Certificate Revocation List keeps digital communication trustworthy by giving relying systems a way to reject certificates that were compromised or invalidated before their expiry. That protection only holds up if the CRL itself stays current. An expired, offline, or misconfigured CRL can undo the very trust it was built to protect, leading to accepted revoked certificates on one side and unnecessary outages on the other.

A certificate lifecycle management platform like CertSecure Manager gives teams centralized visibility into their certificates and CRLs across the organization, which is what actually prevents outages, cuts downtime, and avoids the cost of reactive remediation after something has already broken.

Frequently Asked Questions

What is the main takeaway from The Hidden Risks of Expired Certificate Revocation Lists (CRL)?

An expired, offline, or misconfigured CRL removes the one mechanism relying systems have for rejecting a revoked certificate. Since Let’s Encrypt retired OCSP on August 6, 2025, CRLs are increasingly the only revocation channel available, so a CRL failure is no longer a secondary risk behind OCSP; it is often the whole safety net.

Why does this matter for enterprise certificate lifecycle management?

Certificate lifecycle management is what keeps a CRL’s next-update timestamp from silently passing unnoticed. As the CA/Browser Forum phases maximum public TLS certificate validity down to 47 days by 2029, the volume of certificates and CRLs to track grows, and manual tracking cannot keep pace with that scale.

What teams are responsible for acting on this guidance?

PKI teams own CRL publication and refresh cadence. Security teams own CDP and AIA endpoint monitoring. Platform and infrastructure teams host and maintain the systems those endpoints run on. Compliance teams rely on CRL health evidence to demonstrate current revocation checking during audits.

What risks increase if this topic is handled manually?

Manual tracking increases the risk of a CRL’s next-update timestamp passing unnoticed, an unreachable CDP endpoint going undetected because most browsers soft fail silently, and audit findings when revocation evidence cannot be produced on demand. DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations had certificate-related downtime in the past year, with 37.5% traced to an expired certificate.

How does automation reduce certificate outage risk?

Automated PKI health monitoring, such as the checks in CertSecure Manager, tracks every CA’s CDP and AIA endpoints and remaining CRL lifetime continuously, alerting administrators before a CRL expires rather than after a validation failure has already occurred.

What metrics should teams track after implementation?

Track the number of days remaining before each CRL’s next-update timestamp, CDP and AIA endpoint uptime, the number of revocation-related outages or near-misses per quarter, and the time required to produce CRL health evidence for an audit on demand.

How does this connect to 47-day TLS certificate readiness?

A 47-day certificate with an expired CRL is exposed for just as long, proportionally, as a 398-day certificate was under the old validity rules. Organizations that already automate CRL health monitoring today will not need to rebuild that discipline when shorter validity periods take full effect in 2029.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid PKI environments should monitor CDP and AIA endpoints for every CA, whether an internal Microsoft CA or a public CA, from a single centralized view rather than checking each one separately. A CRL failure in any one environment can leave relying systems there without a working revocation channel while every other environment appears healthy.