Revocation used to be the boring appendix of every TLS checklist. In 2026 it is a design choice with sharp edges. Browsers soft-fail OCSP more often than operators expect. CRL distribution points still matter for some enterprise clients and mTLS. Short-lived certificates shrink the blast radius of a compromised key—and change how you respond when something leaks. If your incident playbook still says "revoke and wait for OCSP," you are fighting last decade's web.

I wrote this with help from AI tools and checked every command and claim myself against current client behaviour. I build PixelValut, a set of free browser-based developer and network tools, and this is Part 3 of Web PKI & Certificate Forensics in Practice. Part 1 covered leaked private keys and safe rotation. Part 2 taught reading X.509 by hand. Here we talk about what happens when a leaf must die early.

📚 Series Roadmap — Web PKI & Certificate Forensics in Practice

Related: Subdomain Takeover & Dangling DNS Reconnaissance

How does TLS certificate revocation work in 2026?

Direct answer: Public CAs still publish CRLs and often OCSP, but many browsers treat soft-fail OCSP as optional and rely more on short lifetimes, CRLSets/CRL caches, and rapid replacement. For operators, the reliable incident response is: replace the leaf immediately, revoke at the CA, verify clients see the new chain, and treat revocation as defense-in-depth—not as a guaranteed kill switch.

Steel padlock and sealed envelope on dark slate, AI-generated

The three mechanisms you still need to name

Mechanism What it is 2026 reality
CRL Signed list of revoked serials from a CA/issuer Still authoritative for many enterprise, Java, and mTLS stacks; large and cache-sensitive
OCSP Live query: "is this serial revoked?" Privacy and reliability issues; stapling helps servers; many browsers soft-fail
Short-lived certs Leaf validity measured in days/hours Shrinks window where revocation must work; ACME automation becomes mandatory

When we read certificates by hand, you already saw CRL Distribution Points and Authority Information Access (OCSP URL). Those extensions are not decoration—they tell clients where to ask. Whether clients ask is the 2026 plot twist.

Inspect what your leaf advertises 

# CRL DP and OCSP URLs on a live leaf openssl s_client -connect example.com:443 -servername example.com \ </dev/null 2>/dev/null | openssl x509 -noout -text \ | sed -n '/X509v3 CRL Distribution Points/,/X509v3/p;/Authority Information Access/,/X509v3/p'

Typical Let's Encrypt-style output still shows an OCSP URI and CRL DP. An SSL certificate checker is a fast second view of issuer, SANs and expiry while you dig into extensions with OpenSSL.

Check OCSP for a specific serial 

# Extract leaf and issuer, then query OCSP (URLs vary by CA) openssl s_client -connect example.com:443 -servername example.com -showcerts \ </dev/null 2>/dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{print}' > chain.pem # Split leaf vs issuer manually, then: openssl ocsp -issuer intermediate.pem -cert leaf.pem \ -url http://ocsp.example-ca/ -resp_text -no_nonce

Expect one of: good, revoked, or transport/timeout failures. Timeouts are why soft-fail exists—and why attackers and outages both benefit from clients that prefer availability over a hard fail-closed check.

Why OCSP declined as a browser kill switch

Three pressures piled up:

  1. Privacy: Classic OCSP tells the CA which site a client is visiting. Stapling moves the check to the server handshake, which is better, but stapling must be configured and refreshed.
  2. Availability: Hard-fail OCSP turned CA or network blips into user-facing outages. Soft-fail became the default compromise.
  3. Scale: Pushing revocation into browser-side lists (vendor CRLSets / equivalent caches) covers high-impact revocations without a round trip on every navigation.

For public HTTPS, that means: do not assume every visitor will learn about your revocation within minutes. Assume some clients will trust the leaf until Not After unless you replace it.

CRL still matters where soft-fail does not

Internal PKI, Java trust stores, API gateways doing mTLS, and some mobile stacks still fetch or cache CRLs aggressively. If you run a private CA:

  • Publish a reachable CRL URL over HTTPS.
  • Keep CRL lifetime short enough that a revoke shows up before your next compliance window.
  • Monitor CRL fetch failures the same way you monitor ACME renewals (Part 5). 
# Fetch and skim a CRL (PEM/DER depends on CA) curl -fsSL "$CRL_URL" -o crl.der openssl crl -inform DER -in crl.der -text -noout | head -n 40

Short-lived certificates change the incident math

If a leaf lives 90 days, a leaked key is a long emergency. If a leaf lives 6 days—or less with automated issuance—the calendar itself contains the blast radius. That is why short-lived certs and solid ACME automation pair so well with the rotation playbook from Part 1.

Practical implications:

  • Automation is non-optional. Manual renewals will page you.
  • Clock skew matters more. A 24-hour cert plus a bad NTP config is an outage.
  • Revoke anyway. Short life is not a reason to skip CA revocation after a confirmed leak; it is a reason you survive if some clients never check.

Incident playbook: revoke without magical thinking

When a key is compromised or a leaf must die:

  1. Issue and deploy a replacement leaf immediately (new keypair preferred).
  2. Revoke the old serial at the CA (ACME revoke or CA API).
  3. Confirm the live handshake shows the new serial and full chain.
  4. Purge stale certs from load balancers, CDNs, and forgotten regional endpoints.
  5. Verify a sample of clients—browser, openssl s_client, and any mTLS callers.
  6. Treat residual risk as "old leaf may still work for soft-fail clients until expiry." 
# Confirm serial changed after rotation openssl s_client -connect example.com:443 -servername example.com \ </dev/null 2>/dev/null | openssl x509 -noout -serial -dates -subject

Browse more PixelValut network and TLS tools when you need a quick second opinion without pasting private keys anywhere.

OCSP stapling (still worth doing)

Even with soft-fail browsers, stapling improves handshake privacy and helps clients that do check:

ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/ssl/certs/fullchain-with-root-or-intermediates.pem; resolver 1.1.1.1 8.8.8.8 valid=300s;

Then verify:

openssl s_client -connect example.com:443 -servername example.com \ -status </dev/null 2>/dev/null | sed -n '/OCSP Response/,/Certificate chain/p'

You want a successful stapled response, not "no response sent."

Diagnostic checklist

  1. Does the leaf advertise CRL DP and/or OCSP URLs you can reach?
  2. Is OCSP stapling enabled and actually present in the handshake?
  3. Do you know which of your clients soft-fail vs fail-closed on revocation?
  4. For private CA / mTLS, is the CRL URL monitored and short-lived enough?
  5. After a revoke request, did you verify CA status and live deployment of a new leaf?
  6. Are forgotten endpoints (old LBs, staging CNAMEs) still serving the old serial?
  7. Are leaf lifetimes short enough that a missed revoke is survivable?
  8. Is ACME renewal alerting louder than your pager threshold for expiry?
  9. Have you tested clock skew against short-lived certs in staging?
  10. Does your incident doc say "replace first, revoke second, verify third"?

FAQ

If browsers soft-fail OCSP, why revoke at all?

Because some clients still check, CA records matter for compliance, and browser CRLSets / similar lists may pick up high-impact serials. Revocation is defense-in-depth; replacement is the control that actually stops most users.

Is OCSP Must-Staple worth enabling?

Only if you can guarantee stapling. Must-Staple turns a stapling outage into a hard failure—which is good for security and painful for ops. Most public sites skip it; high-assurance setups sometimes accept the trade.

Do short-lived certificates replace revocation?

They reduce dependence on timely client checks. They do not replace CA revocation after a known compromise, especially for enterprise and mTLS clients.

Why did openssl ocsp say revoked but browsers still connected?

Soft-fail, cached state, different intermediates, or a CDN edge still on the old cert. Always verify the serial on every edge you terminate TLS.

Should I pin OCSP responses?

No. Prefer short lifetimes, monitored stapling, and CT monitoring (Part 4). Pins without escape hatches cause outages.

What about Let's Encrypt and other public CAs specifically?

Flows change; the pattern does not: replace the leaf, revoke via their documented ACME/API path, confirm serials on every terminator. Re-read your CA's current revoke docs during the incident—not after.

Next in this series, Part 4 covers Certificate Transparency monitoring so you catch unexpected certificates for your domains before users do.

Follow & Connect