Certificate revocation lists expose the real PKI governance gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: Certificate revocation is only useful when status checks are operationally reliable, so locating, downloading, and inspecting a Certificate Revocation List is essential.

Why it matters: PKI and DevOps teams need revocation checks that work in live workflows, because stale, unreachable, or unreadable CRLs can turn a certificate status control into an outage or trust failure.

Context

Certificate revocation checking is the part of PKI that proves whether a certificate is still trustworthy at the moment a system is about to use it. A revocation process that exists on paper but cannot be checked in workflows leaves trust decisions exposed.

This article is about the operational side of certificate status validation: finding the CRL Distribution Point, retrieving the CRL, and reading freshness and revocation data in tools such as OpenSSL, Windows, and EJBCA. For teams running TLS, CI/CD, or CA operations, the issue is governance of status data, not just knowledge of the protocol.

The article treats CRL checking as a practical control that has to work under real network, format, and scaling conditions. That is the right lens for PKI teams because revocation only matters when the list is reachable, current, and machine-readable at decision time.

Key questions

Q: What breaks when a CRL is stale or unreachable?

A: When a CRL is stale or unreachable, consuming systems may be unable to confirm certificate status at decision time. That can cause trust failures, blocked connections, or unsafe acceptance of certificates whose revocation state can no longer be verified. The failure is operational as much as cryptographic: the revocation control stops being dependable.

Q: Why does revocation checking matter before a TLS connection is trusted?

A: Because revocation is only valuable if the status source can be checked before the connection is accepted. If a system cannot confirm that a certificate is still in good standing, it cannot safely rely on the identity asserted by that certificate. The practical risk is trusting a certificate whose status is unknown or outdated.

Q: How do security teams know if their CRL process is actually working?

A: They know it is working when certificates can be traced to the correct CDP, the CRL is current, the parser can read the format, and revocation decisions are made from fresh data rather than cached assumptions. A working process produces repeatable validation, not occasional manual success.

Q: What is the difference between CRL and OCSP in certificate status checking?

A: CRL and OCSP both help determine whether a certificate should still be trusted, but they work differently. A Certificate Revocation List is a published list of revoked certificates, while OCSP asks a responder for the status of a specific certificate in real time. OCSP is typically faster and more granular, while CRLs are simpler to distribute and cache.

Technical breakdown

How a CRL distribution point anchors status checking

A Certificate Revocation List depends on the CRL Distribution Point extension inside the certificate. That extension tells the client where the issuing CA publishes revocation data, usually as a URL. Without that pointer, a verifier cannot discover which list to check, and revocation becomes an abstract promise rather than an operational control. In practice, the CDP is the first dependency in the chain because every downstream check relies on finding the right publication source. If the certificate points to stale, unreachable, or incorrect CDP data, the trust decision becomes unreliable before the list is even downloaded.

Practical implication: verify that every certificate used in production publishes a current and reachable CRL Distribution Point.

What matters when reading a CRL file

A CRL is not just a revoked-serial list. It also carries issuer identity, last update time, next update time, and optional reason codes for each entry. Those fields determine whether the list is trustworthy enough to use in automation or troubleshooting. If Next Update has passed, the list is stale. If the issuer does not match the expected CA, the verifier may be looking at the wrong trust source. If the serial number is present, revocation is confirmed; if it is absent, that only means the certificate is not listed in that specific CRL at that moment.

Practical implication: make freshness and issuer validation part of every CRL inspection, not just serial-number lookup.

Why CRL validation breaks in enterprise workflows

CRL validation fails for predictable operational reasons: the CDP is unreachable, the list has expired, the file format does not match the parser, or the CRL has grown large enough to create timeouts. Those failures matter because revocation is often checked inside automated workflows, not during a manual review. In CI/CD or TLS validation paths, a failed fetch can block service access or leave the system unable to determine status. The underlying problem is that revocation infrastructure behaves like a dependency, not a passive registry. If it is unavailable or too slow, the security control stops being decisive.

Practical implication: monitor CRL availability, size, and format compatibility as production dependencies, not background housekeeping.

NHI Mgmt Group analysis

CRL checking exposes a governance problem, not just a protocol problem: certificate revocation only protects trust decisions when the list can be found, fetched, and interpreted at the moment of use. In many environments, the control exists but the workflow around it does not, which turns revocation into an advisory signal instead of an enforced one. The practitioner conclusion is simple: a revocation mechanism that cannot be operationalised is not a control.

CRL freshness is the real PKI control boundary: once a CRL is stale or unreachable, the issuer may still be trusted by policy even though the status source is no longer reliable. That creates a governance gap between CA administration and consuming systems, especially when automation expects status to be available on demand. The practitioner takeaway is that revocation monitoring belongs in the same operational discipline as certificate issuance.

Certificate status validation is a runtime dependency, not a periodic task: the article shows that teams need to check distribution points, update timestamps, and parsing compatibility before a trust decision is made. That shifts CRL handling from a troubleshooting exercise to a continuous assurance requirement. The practitioner implication is that status checking should be treated as part of identity and trust governance.

PKI teams must own the trust-availability boundary: the burden is not only on the CA to publish a list, but on consumers to prove they can reach and read it under real workload conditions. This is where certificate governance meets operational resilience, and it is where many programmes assume away failure. The practitioner conclusion is that revocation controls should be measured by successful validation, not by publication alone.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

CRL governance is really a trust-availability problem: the control fails if the publication point cannot be reached, the file cannot be parsed, or the list has expired before the next validation event. Teams should measure success by whether certificate consumers can actually complete status checks, not by whether the CA emitted a list.

Certificate status data should be treated like any other production dependency: when revocation metadata is stale, unreachable, or too large to process, the trust decision degrades in the same way a failed API does. That means monitoring, alerting, and fallback design belong in the PKI operating model, not just in the CA administrator’s toolkit.

For practitioners

• Verify CRL Distribution Points in every production certificate Check that each certificate points to the correct, current CRL publication location and that the URL is reachable from consuming systems before rollout.
• Monitor CRL freshness and expiry continuously Track the Last Update and Next Update fields so an expired or stale list is detected before certificate validation fails in production.
• Test CRL parsing in the tools your teams actually use Validate OpenSSL, Windows certutil, browser viewers, and CA interfaces against both DER and PEM formats so format mismatch does not break checks.
• Treat unreachable CDPs as an operational incident Build alerts for DNS, firewall, and network paths to the CDP because revocation is ineffective when clients cannot retrieve the list on demand.
• Use OCSP as a complement where latency or scale is a concern If CRL download and parsing are slow or too large for your environment, pair CRLs with OCSP so status checks stay practical for automated workflows.

Key takeaways

• Certificate revocation only protects trust when the consuming system can retrieve and interpret current status data at the point of validation.
• The article shows that stale, unreachable, or malformed CRLs turn revocation into an unreliable control and can disrupt automated workflows.
• Teams should monitor CDP reachability, CRL freshness, and parser compatibility as production controls, not after-the-fact troubleshooting.

Key terms

• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• CRL Distribution Point: A CRL Distribution Point is the location embedded in a certificate where revocation data can be retrieved. It is the mechanism that connects the certificate to its current trust evidence, so a missing or unreachable CDP breaks verification even when the certificate chain itself appears valid.
• Next Update: Next Update is the timestamp in a CRL that indicates when a fresh list should be published. If the current time is past this value, the CRL is stale and should not be treated as reliable evidence of current certificate status.
• Revocation and Status Checking: Revocation and status checking are controls that confirm whether a digital credential is still valid at the time it is presented. Revocation lets an issuer invalidate a credential early, while status checking lets a verifier confirm current validity. Together they prevent expired or compromised credentials from being trusted.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.