> Lesson 8 of PKI in 90 minutes: revoking certificates with CRLs and OCSP, why browsers soft-fail, Certificate Transparency, and famous CA failures. Source: https://pkizerotohero.com/course/when-trust-breaks/ · Last reviewed: 2026-10-20 # When trust breaks About 9 minutesCrash course **In one sentence:** Revocation is a weak brake because most clients soft-fail, Certificate Transparency makes wrong certificates visible, and failing CAs are removed from trust stores. ## The situation Friday, five in the afternoon. A developer finds that the private key of your main website was pushed to a public code repository three days ago. Within the hour you generate a new key, get a new certificate, deploy it, and ask the CA to revoke the old certificate. Can everyone relax for the weekend? ## What is going on ### Taking a certificate back [Revocation](https://pkizerotohero.com/handbook/glossary/#revocation) is how a CA declares a certificate untrustworthy before it expires. There are two ways to publish that news: - A [certificate revocation list](https://pkizerotohero.com/handbook/glossary/#crl) (CRL): a signed list of the serial numbers of revoked certificates, published by the CA. - [OCSP](https://pkizerotohero.com/handbook/glossary/#ocsp): the client asks the CA about one certificate and gets a signed answer. With [OCSP stapling](https://pkizerotohero.com/handbook/glossary/#ocsp-stapling), the server fetches that answer itself and attaches it to the handshake. ### Why revocation is a weak brake In practice, most browsers **soft-fail**: if they cannot get a revocation answer quickly, they accept the certificate anyway. Failing hard would break sites every time a revocation service was slow or unreachable. But someone who can intercept traffic can often block the check too. Some browsers instead push compact lists of revoked certificates to their users ahead of time. The trend is away from live checks: Let's Encrypt has shut down its OCSP service (since 6 August 2025). *Diagram: A timeline: the certificate is issued, then the key leaks, then the certificate is revoked, then it expires. Clients that learn of the revocation are at risk only between the leak and the revocation, then protected, marked with a tick. Clients that soft-fail stay at risk from the leak until the certificate expires, marked with a cross. Shorter lifetimes shrink that window.* Revocation protects only the clients that hear about it. Expiry is the hard stop. So, for the situation: you did the right things in the right order. But until the old certificate expires, anyone holding the leaked key who can get between users and your site could still impersonate it to clients that never learn of the revocation. That is why shorter certificate lifetimes matter (lesson 9), and why protecting the key in the first place matters most. The full response to a leaked key, in order: generate a new key and certificate, deploy them, revoke the old certificate, search the Certificate Transparency logs (below) for other certificates for your names, and find out how the key leaked so it cannot happen again. ### Everyone can see: Certificate Transparency [Certificate Transparency](https://pkizerotohero.com/handbook/glossary/#certificate-transparency) (CT) means CAs record publicly trusted certificates in public, append-only logs. Chrome requires Certificate Transparency for publicly trusted TLS certificates (since April 2018). Anyone can search those logs. CT does not stop a CA from issuing a wrong certificate. It makes the mistake **visible**. If you monitor the logs for your own domain names, you can spot a certificate you never asked for, often within hours. ### When a CA itself fails Any publicly trusted CA can technically issue for any domain, so one failing CA puts everyone at risk. Root programs respond by distrusting it: - In 2011, DigiNotar was breached, issued fraudulent certificates and was removed from browser trust stores. The attackers’ certificates were for well-known sites. - In 2018, Chrome and Firefox stopped trusting TLS certificates from Symantec's old CA infrastructure after a long record of issuance problems. - More recently, Chrome stopped trusting new Entrust TLS certificates (those first logged in Certificate Transparency after 11 November 2024), citing a pattern of compliance failures. Distrust is usually phased in with a date, so sites have time to move. Sites that know which CAs they use, and can switch, barely notice. Why it matters to the business Ask your team If one of our private keys leaked tonight, who replaces it, who revokes the certificate, and how long would it take? Do we monitor Certificate Transparency logs for our domains? Could we switch to another CA within a week? ## Try it *Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))* Revocation lists and OCSP identify a certificate by its issuer and its serial number. Find both in this certificate. Then find its “not after” date: whatever happens to revocation, that is when clients stop accepting it. ## Check Check yourself Why might some clients still accept a certificate after it has been revoked? 1. Revocation only takes effect after the certificate expires 2. Revocation only works for certificates from private CAs 3. Many clients soft-fail: if they cannot get a revocation answer, they carry on Show answer Answer C Many clients soft-fail: if they cannot get a revocation answer, they carry on What happened Clients that cannot reach, or are not given, revocation information usually accept the certificate anyway. Why Hard-failing would break the web whenever a revocation service was slow. The price is that revocation is advisory, and an attacker who can intercept traffic may block the check. The rule Browser revocation checking is largely soft-fail; expiry is the stop you can count on. Check yourself What does Certificate Transparency do? 1. It puts publicly trusted certificates in public append-only logs, so wrong ones can be spotted 2. It prevents CAs from issuing wrong certificates 3. It encrypts certificates so only their owner can read them Show answer Answer A It puts publicly trusted certificates in public append-only logs, so wrong ones can be spotted What happened CT makes issuance public and auditable: every publicly trusted TLS certificate that browsers accept appears in logs that anyone can search. Why Before CT, a wrongly issued certificate could stay unnoticed. Logging does not block issuance, but monitoring the logs makes mistakes and attacks visible quickly. The rule CT detects mis-issuance; it does not prevent it. Monitor the logs for your own names. Check yourself Browsers announce that they will stop trusting a CA your company uses. What should you be able to do? 1. Stop using HTTPS until the issue is solved 2. Find every certificate from that CA and replace it with one from another CA before the distrust date 3. Buy certificates with a longer validity from the same CA Show answer Answer B Find every certificate from that CA and replace it with one from another CA before the distrust date What happened You find the affected certificates in your inventory and move them to another CA in time. Why Distrust is usually phased in with a date. Organisations with an inventory and automation switch quietly; others discover affected certificates through outages. The rule Know which CAs issue your certificates, and keep a second CA ready. ## Takeaways - Revoke a compromised certificate, but do not rely on it: most clients soft-fail, and expiry is the stop you can count on. - Certificate Transparency makes every publicly trusted TLS certificate visible; monitor it for your names. - CAs that fail are removed from trust stores. Know your CAs and be ready to switch. ## Go further - Handbook: [Taking it back: CRLs, OCSP and stapling](https://pkizerotohero.com/handbook/revocation/) - Handbook: [Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/) - Handbook: [Famous failures and what changed](https://pkizerotohero.com/handbook/famous-failures/) - Next lesson: [Running PKI](https://pkizerotohero.com/course/running-pki/) **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/course/when-trust-breaks/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 16: Taking it back: CRLs, OCSP and stapling](https://pkizerotohero.com/handbook/revocation/) - [Chapter 17: Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/) - [Chapter 18: Famous failures and what changed](https://pkizerotohero.com/handbook/famous-failures/)