CRL and revocation vs expiry

Certificate revocation vs expired confusion drives wrong renewals: a cert can show a future notAfter while browsers reject it because the serial appears on a CRL or OCSP responder returns revoked.

Incident responders see “certificate has expired” in one tool and “certificate revoked” in another, then renew unnecessarily or miss compromise response. PKIX treats time validity and revocation status as separate gates—both must pass for strict clients.

This guide shows how to download CRLs, probe OCSP, and interpret openssl output next to date checks—without replacing your CA’s incident process.

After key compromise announcements, leadership asks whether any company property still serves affected serials. Certificate revocation vs expired triage separates hosts that need emergency reissue from hosts that only need calendar renewal on a peaceful weekend.

Browsers increasingly harden OCSP behavior; stapling mistakes show up as revocation errors even when notAfter is months away. Understanding CRL distribution points helps you argue with CDN vendors about staple freshness in contract reviews.

What to check

Expiry (notBefore / notAfter) answers whether the cert is inside its validity window. Revocation answers whether the CA withdrew trust early—compromise, key misuse, or superseding issuance. Trust path still needs complete chains (SSL not trusted intermediate missing).

Locate CRL Distribution Points and Authority Information Access (OCSP) in the leaf and issuer certs. Note soft-fail behavior: some clients block on revoked; others ignore OCSP timeouts.

Renewing a revoked cert without re-keying does not help—you need a new serial from the CA. Renewing an expired cert is normal reissuance.

Step-by-step

Read CRL and OCSP URLs from the certificate

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -dates -serial -ext crlDistributionPoints -ext authorityInfoAccess

Fetch and parse a CRL (DER → PEM)

curl -s -o ca.crl "$CRL_URL"
openssl crl -in ca.crl -inform DER -text -noout | head -60

Search for your serial (convert leaf serial to hex if needed):

SERIAL=$(echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -serial)
echo "$SERIAL"
openssl crl -in ca.crl -inform DER -text -noout | grep -i "$(echo $SERIAL | cut -d= -f2 | tr '[:upper:]' '[:lower:]')"

OCSP request with openssl

openssl s_client -connect www.example.com:443 -servername www.example.com -status </dev/null 2>&1 \
  | grep -A5 'OCSP Response Status'

For staple validation on servers you operate:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com -status 2>/dev/null \
  | openssl x509 -noout -dates

Compare date-only view

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -checkend 0 && echo "notAfter still in future"

If checkend passes but clients fail, suspect revocation or trust, not calendar expiry.

OpenSSL verify with CRL (lab)

openssl verify -crl_check -CRLfile ca.crl -untrusted intermediate.pem leaf.pem

Production trust stores vary; use this in staging with copies of issued chains.

How to read the output

CRL text lists Revoked Certificates with serial, revocation date, and reason code (keyCompromise, cessationOfOperation, etc.). Next Update shows CRL freshness; stale CRL caches cause inconsistent client behavior.

OCSP responses show good, revoked, or unknown. A revoked response with future notAfter on the cert is the canonical certificate revocation vs expired split. unknown may mean the CA no longer tracks that serial—follow vendor guidance.

s_client -status reports whether the server stapled OCSP. Missing staples shift burden to client OCSP lookups, which may fail closed in hardened environments.

Common mistakes

Renewing on calendar expiry when security already revoked the serial after key leak—attackers may still have the old private key until you rotate keys and install a new cert.

Ignoring intermediate CA revocation while the leaf date looks fine—some incidents revoke subordinate CAs, breaking entire chains.

Assuming openssl x509 -checkend is enough for compliance audits—assessors expect CRL/OCSP evidence or staple configuration.

Downloading CRLs once and caching forever—respect Next Update and automate refresh.

Confusing browser bypass clicks with fixed revocation—users can ignore errors temporarily while automation still fails.

Treating CT logs as revocation sources—they are not; see certificate transparency logs search for inventory only.

When to use automation

Monitor OCSP responder latency and staple freshness on properties you control. Alert when staples are missing on HSTS sites where clients hard-fail.

For portfolio visibility, automate serial + notAfter + OCSP status snapshots daily on critical hosts. Pair with live TLS expiry monitors; ssldays-style checks emphasize dates while your PKI team watches revocation tickets from the CA.

After CA incidents affecting your issuer, run bulk CRL diff against your inventory instead of waiting for user reports. Document decisions when CAs use short-lived certs to reduce revocation reliance.

Maintain offline copies of CRLs used during investigations with timestamps matching incident start. Legal may ask whether you could have known about revocation earlier.

Teach on-call that user bypass clicks in browsers do not clear automation failures—CI jobs and API clients still enforce revocation even when executives can click through warnings temporarily.

Coordinate with identity teams when smart card middleware caches CRLs longer than IT expects. Workstation trust settings affect internal admin tools separately from public website monitoring.

Schedule quarterly drills that rotate a lab certificate and revoke the old serial intentionally. Teams practice openssl CRL lookups before doing them under live incident pressure.

Risk committees sometimes ask for quantitative exposure after CA compromises: how many active connections still present revoked serials. Answering requires inventory plus OCSP sampling at scale, not a single openssl command on www. Plan engineering time for bulk serial extraction when media coverage spikes.

Vendor contracts with CDNs should specify staple refresh intervals and liability when staples serve stale good responses while certificates were revoked. Legal language lags technology; operations teams supply concrete openssl staple checks as exhibits during negotiations.

Developers embedding custom TLS stacks in firmware may disable revocation checks for size reasons. Document those exceptions explicitly in architecture decision records so incident responders do not assume uniform browser-grade PKIX everywhere.

Insurance and cyber policies increasingly ask whether revocation monitoring exists. CRL drill logs and ticket IDs demonstrate maturity better than claiming we use public CAs so it is fine.

Cross-border operations may face data residency limits on downloading CRLs hosted abroad. Consult compliance before automating CRL fetches from foreign URLs into centralized SIEM storage.

Publish a one-page revocation versus expiry decision tree in the on-call runbook so night shift engineers choose reissue versus renew paths within minutes instead of waking PKI architects for every alert.

Track staple deployment percentage on properties you operate; low staple coverage often correlates with mysterious client-specific revocation complaints that disappear when staples are enabled cluster-wide.

Executive simulations of ransomware scenarios should include a branch where attackers publish stolen keys and CAs revoke certificates. Teams rehearse certificate revocation vs expired triage under time pressure separate from generic ransom payment drills.

Academic partnerships studying post-quantum migration may temporarily issue parallel certificates; CRL and OCSP confusion rises when multiple valid chains coexist during experiments. Document lab hostnames clearly in monitoring tiers.