Certificate revocation lists expose the real PKI governance gap

At a glance

What this is: This is a practical guide to locating, downloading, and reading certificate revocation lists so teams can verify whether a certificate is still trusted.

Why it matters: It matters because PKI, DevOps, and IAM teams need revocation checks that work operationally, not just on paper, to avoid trusting invalid certificates in automation and production.

👉 Read Keyfactor's guide to viewing and checking a certificate revocation list

Context

Certificate revocation checking is the operational side of PKI trust. A certificate can look valid at issuance time and still become unsafe later, so teams need to verify current revocation status before relying on it in TLS, CI/CD, or administrative workflows.

For identity and access programmes, the lesson extends beyond certificates themselves. Revocation data is part of the control plane for machine identity, and failures in publication, retrieval, or parsing can turn a technical trust check into a governance blind spot.

Key questions

Q: How should security teams verify certificate revocation in production?

A: Security teams should verify revocation by checking the certificate’s CRL Distribution Point, downloading the current CRL, and matching the certificate serial number against the revoked list. They should do this from the same network locations used by applications and automation so the test reflects real trust conditions, not a local admin path.

Q: Why do CRL failures create identity governance risk?

A: CRL failures create identity governance risk because the trust decision depends on current revocation evidence. If the distribution point is unreachable, the list is expired, or the file cannot be parsed, the organisation loses confidence in whether the certificate should still be accepted. That breaks certificate-based access control in practice.

Q: What breaks when certificate revocation data is stale or unreachable?

A: When revocation data is stale or unreachable, relying systems may continue to trust certificates whose status has changed. That affects TLS validation, administrative workflows, and automated builds that depend on certificate checks. The failure is not just technical downtime. It is a loss of assurance about whether a certificate is still authorised for use.

Q: How do teams align certificate revocation with lifecycle governance?

A: Teams should align certificate revocation with lifecycle governance by revoking certificates during service retirement, vendor offboarding, and ownership transfer. Revocation should be part of the same control chain as issuance, renewal, and replacement so that credentials do not outlive the identities and systems they were issued to support.

Technical breakdown

How CRL distribution points work in X.509 certificates

A Certificate Revocation List, or CRL, is published by a certificate authority and referenced inside the certificate through the CRL Distribution Points extension. That extension tells clients where to fetch revocation data. In practice, this means the certificate itself carries a pointer to the trust evidence needed later. If the CDP URL is unreachable, stale, or misconfigured, the relying party cannot confirm status reliably, even if the certificate chain otherwise validates.

Practical implication: verify that every certificate used in production exposes a reachable CDP and that your monitoring treats CDP availability as a control requirement.

How to inspect revocation status with OpenSSL and Windows

Operational checking usually means downloading the CRL in DER or PEM format and reading it with a tool such as OpenSSL or certutil. The output shows the issuer, update timestamps, and the revoked certificate list, including serial numbers and revocation dates. That is the key mechanic: revocation is not inferred from the certificate alone, but matched against a published list. If the serial number appears, the certificate is revoked; if it does not, the CRL does not list it as revoked at that point in time.

Practical implication: standardise one command-line and one Windows-based validation path so administrators and automation see the same revocation evidence.

Why CRL freshness and size affect trust decisions

CRLs are only useful if they are current and parsable within expected time limits. The article highlights expired CRLs, large CRL performance problems, and format mismatch as common failure modes. These are not theoretical issues. An expired list means revocation status is no longer dependable, while very large lists can create timeouts or parsing failures in clients and build systems. In PKI governance terms, the control is not just publishing revocation data, but ensuring it remains timely, reachable, and consumable by real systems.

Practical implication: monitor Next Update, CRL size, and format consistency as first-class operational signals, not after-the-fact troubleshooting data.

NHI Mgmt Group analysis

Certificate revocation is a machine-identity governance control, not a documentation exercise. The article shows that a certificate is only trustworthy if clients can actually retrieve and interpret current revocation data. That makes CRL availability part of the access decision itself, which is why revocation handling belongs in workload identity and lifecycle governance rather than only in PKI administration. Practitioners should treat CRL checking as a production control, not a back-office task.

Availability failures in revocation infrastructure become trust failures in downstream systems. An unreachable CDP, an expired CRL, or a format mismatch does not merely slow troubleshooting. It can break the trust boundary for TLS, automation, and certificate-backed access. The practical conclusion is that revocation infrastructure needs the same monitoring discipline as other identity-critical dependencies.

Certificate lifecycle does not end at issuance. The guide makes clear that serial number lookup, update cadence, and revocation publication all determine whether a certificate remains safe to use. That is the same lifecycle problem NHIs face when keys, tokens, and certificates outlive their intended scope. Identity blast radius: the longer a credential remains valid without reliable revocation checking, the wider the potential impact when trust changes.

PKI teams and identity teams should stop treating revocation as a specialised edge case. Certificate status is part of the broader identity governance model that includes visibility, rotation, offboarding, and validation. When those controls are fragmented, trust decisions become inconsistent across browsers, automation, and administrative tooling. Practitioners should align certificate revocation with the same governance baseline used for other non-human identities.

From our research:

• 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.
• A separate finding shows that 97% of NHIs carry excessive privileges, which broadens the blast radius when revocation and lifecycle controls are weak.
• For teams extending revocation discipline beyond certificates, the NHI Lifecycle Management Guide explains how offboarding, rotation, and visibility fit together.

What this signals

Certificate revocation is part of the same governance problem as NHI offboarding. If teams cannot reliably revoke certificates, they are unlikely to have consistent control over other machine credentials either. The broader programme signal is that lifecycle management needs one ownership model across certificates, keys, tokens, and service accounts, with revocation tested in the same way as issuance and renewal.

69% of security leaders agree identity management must fundamentally shift to address agentic AI systems. That shift also raises the bar for machine trust infrastructure, because autonomous and non-autonomous systems both depend on evidence that credentials are current, scoped, and revocable. The governance model should assume more execution paths, not fewer, and plan revocation accordingly.

When revocation checks become part of build pipelines and runtime validation, the operational question is not whether a CRL exists but whether every consuming system can parse and trust it at scale. That is where certificate lifecycle control meets production resilience, and where identity teams need to measure real assurance rather than procedural compliance.

For practitioners

• Validate CDP reachability in production paths Test every CRL Distribution Point from the same networks, build runners, and application segments that consume certificates. If the CDP is unreachable from one of those paths, the revocation control is incomplete even if the URL works from an admin workstation.
• Monitor Next Update as an expiry control Alert before the Next Update timestamp passes and treat missed publication as an operational incident. This keeps CRL freshness visible before certificate checks begin failing across dependent systems.
• Standardise CRL parsing across teams Use the same OpenSSL and Windows validation methods for troubleshooting, and document how to handle DER to PEM conversion. Consistent parsing removes ambiguity when different operators or pipelines inspect the same revocation data.
• Tie certificate revocation to lifecycle offboarding Revoke certificates when services are retired, vendors are removed, or ownership changes so the certificate lifecycle matches the real identity lifecycle. Keep the revocation step in the offboarding workflow, not as a separate manual task.

Key takeaways

• Certificate revocation is an operational trust control, not just a PKI housekeeping task.
• Stale, unreachable, or oversized CRLs turn a valid certificate into an uncertain one for downstream systems.
• Identity teams should manage certificate revocation through the same lifecycle discipline used for other non-human credentials.

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.
• Revocation Freshness: Revocation freshness is the degree to which the published status information reflects the current state of a certificate. In practice, it depends on update cadence, delivery reliability, and client caching behaviour, and it is a critical part of whether certificate-based trust can be defended in production.
• Certificate Lifecycle Governance: Certificate lifecycle governance is the set of controls that manage issuance, renewal, monitoring, revocation, and retirement across the full life of a certificate. It ensures that certificates do not outlive the services, owners, or trust relationships they were created to support.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: How to View and Check a Certificate Revocation List. Read the original.