When trust breaks

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 is how a CA declares a certificate untrustworthy before it expires. There are two ways to publish that news:

• A certificate revocation list (CRL): a signed list of the serial numbers of revoked certificates, published by the CA.
• OCSP: the client asks the CA about one certificate and gets a signed answer. With 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).

Swipe sideways to see the whole diagram.

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 (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.

Try it

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

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
• Handbook: Certificate Transparency
• Handbook: Famous failures and what changed
• Next lesson: Running PKI

In the gameLevel 16: Taking it backWatchtower, Keystone. In development