Topic starter
25/06/2026 1:20 am
TL;DR: Checking a certificate revocation list is a core PKI operation because it lets teams verify issuer status, inspect revoked serial numbers, and detect stale or unreachable revocation data, according to Keyfactor. The governance issue is not whether revocation exists, but whether enterprise workflows can actually validate and act on it before trust decisions are made.
Editorial analysis by NHI Mgmt Group, based on content published by Keyfactor: “How to View and Check a Certificate Revocation List”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Certificate revocation only protects trust when the consuming system can retrieve and interpret current status data at the point of validation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:41 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Certificate revocation lists expose the real PKI governance gap