Famous failures and what changed

PKI rests on a few promises. CAs check before they sign. CAs protect their keys. And someone renews every certificate before it expires. When one of these promises breaks, trust breaks with it, for one website or for millions.

This chapter looks at real failures that the organisations involved, or official investigators, documented in public. For each one we ask three questions:

1. What went wrong?
2. How was it noticed?
3. What changed afterwards?

The failures fall into three groups:

• A CA is broken into. An attacker uses the CA to issue certificates for names that are not theirs (DigiNotar).
• A CA keeps breaking the rules. The browser makers stop trusting it. This is called distrust (Symantec, Entrust).
• Something expires. Either a root certificate that many devices relied on (DST Root CA X3), or an ordinary server certificate that nobody renewed.

In web PKI, the browser and operating-system makers act as referees. They decide which root certificates go into their trust stores, and removing a CA from a trust store is the strongest penalty there is.

The dramatic failures are break-ins. The ordinary one is an expired certificate, and it has taken down services at some of the largest technology companies in the world. The lessons are less about clever attackers and more about missing checks, missing inventories and manual processes.

How did one hacked CA threaten everyone? DigiNotar

DigiNotar was a Dutch CA, trusted by all major browsers and also used by the Dutch government. In 2011, attackers broke into its network and reached the systems that issued certificates. The investigation commissioned by the Dutch government, Fox-IT’s Black Tulip report, gives “a non-exhaustive list of 531 rogue certificates”.

How it was noticed. DigiNotar’s own staff found the intrusion when a routine automated check, which had stopped working, was restored and flagged certificates that did not match the company’s records. The company revoked the rogue certificates it knew about. It did not tell the browser makers. Mozilla later wrote that DigiNotar “detected and revoked some of the fraudulent certificates 6 weeks ago without notifying Mozilla” (Mozilla Security Blog). The public found out when a Gmail user in Iran posted a warning: Chrome had rejected a certificate for a Google domain, because Chrome checked Google’s own certificates against a built-in list of expected keys (certificate pinning). From the OCSP requests for the rogue *.google.com certificate, the final report counted 298,140 unique IP addresses as likely victims, 95% of them in Iran, and calls that number only “a very rough approximation” of the people affected.

What changed. DigiNotar was breached, issued fraudulent certificates and was removed from browser trust stores. Google, Mozilla, Microsoft and Apple all removed trust within weeks. The Dutch government revoked its own trust in DigiNotar and took over its operations, and the company was declared bankrupt.

Two lessons stayed. Any trusted CA can issue for any name, so one breach endangers everyone. And a CA that hides an incident loses trust completely. Certificate Transparency, standardised in June 2013 and December 2021, now makes rogue certificates visible to every domain owner, not only to companies that pin their own keys.

What happens when a CA keeps breaking the rules? Symantec and Entrust

Symantec: what went wrong. In January 2017, a public post on Mozilla's security-policy forum “drew attention to a series of questionable website authentication certificates”, in the words of Google’s later announcement. The Chrome team found that Symantec “had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight”, and called it “part of a continuing pattern of issues over the past several years”. In Chrome’s public discussion, the count grew from “reportedly 127 certificates” to “at least 30,000 certificates” (blink-dev).

What changed. Browsers withdrew trust in phases, by issue date: Chrome 66 distrusted Symantec certificates issued before 1 June 2016, and Chrome 70 removed trust in the rest (April and October 2018). Mozilla followed a matching plan. Symantec sold its CA business to DigiCert, and every site owner with an affected certificate had to replace it before the deadline.

Entrust: what went wrong. In Google’s words: “Over the past six years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports.” It was noticed the way most CA problems are noticed today: through public incident reports and the root programs’ scrutiny of them.

What changed. Chrome stopped trusting new Entrust TLS certificates (those first logged in Certificate Transparency after 11 November 2024). Certificates issued before the cut-off kept working until they expired. Apple, Mozilla and Microsoft set their own cut-off dates: 15 November 2024, 30 November 2024 and 16 April 2025.

Chrome’s cut-off uses the date of the certificate’s earliest SCT. Certificate Transparency gives a trustworthy, public issue date, which makes this kind of partial distrust possible.

Swipe sideways to see the whole diagram.

Distrust is rare, slow and public, and it always comes with a deadline. Organisations that can switch CA quickly barely notice. Those that renew by hand have to find and replace every affected certificate in a few months.

Why did a root expiry break working sites? DST Root CA X3

What went wrong. Let’s Encrypt’s own root, ISRG Root X1, was young and missing from many older devices. So for years the default Let’s Encrypt chain also included a cross-signature from IdenTrust’s older DST Root CA X3, which those devices already trusted. On 30 September 2021, DST Root CA X3 expired. Let’s Encrypt had announced it well in advance. Two kinds of client failed:

• devices that never received ISRG Root X1, because “some older devices won’t ever trust it because they don’t get software updates”;
• clients built on OpenSSL 1.0.2, even when they did trust ISRG Root X1. The OpenSSL project explained that OpenSSL 1.0.2 “always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.”

Swipe sideways to see the whole diagram.

How it was noticed. This failure was planned and announced. It surfaced on the day as certificate errors in old phones, embedded devices and servers running old OpenSSL versions, while up-to-date browsers carried on.

What changed. Let’s Encrypt kept old Android devices working with a trick: a cross-signature that outlived the DST root, which works because “Android intentionally does not enforce the expiration dates of certificates used as trust anchors” (Let’s Encrypt). Later, Let's Encrypt's cross-signed chain for old Android devices expired (30 September 2024). The lasting lessons: every certificate in a chain has an end date, not only yours; TLS libraries and trust stores need updates too; and old clients deserve a test before a root change.

Why do expired certificates still cause outages?

Expiry is the most ordinary failure in PKI, and big operators are not immune. These four cases come with public post-mortems or official reports:

The Equifax case is the starkest. In the words of the US Government Accountability Office: “the misconfiguration was due to an expired digital certificate”, meaning “that encrypted traffic was not being inspected”, and “the attack lasted for about 76 days before it was discovered”. The expired certificate did not break the business; it silently switched off a security control.

Microsoft’s Azure post-mortem names the pattern behind most expiry outages: “a breakdown in our procedures for maintaining and monitoring these certificates was the root cause.” Epic Games found the same gap in its own monitoring: “the configuration for this internal zone was missing”.

Which CAs and roots does your service depend on?

Look at the whole chain your server sends, not only the first certificate. This is the real output for letsencrypt.org:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null

Certificate chain
 0 s:CN=letsencrypt.org
   i:C=US, O=Let's Encrypt, CN=YE2
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  4 14:34:32 2026 GMT; NotAfter: Dec  3 14:34:31 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=YE2
   i:C=US, O=ISRG, CN=Root YE
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
---

Entries 2 and 3 are cross-signatures: Root YE signed by ISRG Root X2, and ISRG Root X2 signed by ISRG Root X1. It is the same pattern as with DST Root CA X3: a newer root reaches older trust stores through an older one. Write down the NotAfter of every entry, and know which CA and which root each of your services depends on. Paste a chain into the chain checker to see the path:

Try it: Chain checkerOpen the full tool

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

Paste the chain

Try a sampleChoose a sample…A complete chain: leaf, intermediate and rootA server that forgets its intermediateA chain in the wrong orderA self-signed root CA

-----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----- -----BEGIN CERTIFICATE----- MIIE2TCCAsGgAwIBAgIQPh9PeiGf4STnEQriHxExjDANBgkqhkiG9w0BAQsFADB7 MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UE CxMeU2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSgwJgYDVQQDEx9QS0kg WmVybyB0byBIZXJvIFNhbXBsZSBSb290IENBMB4XDTI1MDEwMTAwMDAwMFoXDTQw MDEwMTAwMDAwMFowfjELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEFBLSSBaZXJvIHRv IEhlcm8xJzAlBgNVBAsTHlNhbXBsZXMgLSBub3QgcHVibGljbHkgdHJ1c3RlZDEr MCkGA1UEAxMiUEtJIFplcm8gdG8gSGVybyBTYW1wbGUgSXNzdWluZyBDQTBZMBMG ByqGSM49AgEGCCqGSM49AwEHA0IABBFqObJ/j93aHrAuebO5+KWnj0xRFzUS8/Jh Idj6jR/p4zqaNT8+gOqxZ+zhpNO/weIpz/nzXjQ7RJS+EebYRNijggEfMIIBGzAS BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggr BgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFN+ph37v40SN23r6Fg/zOvSNjJqe MB8GA1UdIwQYMBaAFIVx1Hy1TuED0pMkxEcdM+DWWPGiMEUGCCsGAQUFBwEBBDkw NzA1BggrBgEFBQcwAoYpaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtcm9v dC1jYS5jcnQwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3BraS5leGFtcGxlLmNv bS9zYW1wbGUtcm9vdC1jYS5jcmwwEwYDVR0gBAwwCjAIBgZngQwBAgEwDQYJKoZI hvcNAQELBQADggIBAFa8c1kEzTTPW2aPDRPb3+OQc8GTgwpZV0pWNR3e6X8mJi7A D/RGrz4t354IwGzTts+tX23sY3fORKST3/BkqeHZwAZHvGNWi0+Co342eo2BySxo bcyy31AJBSSHOC2b7KJ11coMX++bvaHgtwOloy6DnHRDYIFwWRHg91wo1MKJGNVb OQH0vmqn6YPDLZ4BYL8VHOVtlRddBwd6bKyyp3Lw0MEMgfmg87Yd/U0yRZFaLKNb b5vgDg7n+J1ozFwvumQlN6WVEyPsQdvI73K5bgMHkUeeUQ6j9KOeDMZMjbqQSC8x 1khcyT/qhqZLDJIHvmWS11FcYaLQUuvQiAzQieTNIuOM8WJw95LlxYSNIkZeOuLf f+JboiuT1cmqmvdbngAXtBIWRJ+Byeqdq2Z0d8Xfln6gWhHmm93+DO5uTaTxBwTr DayFTdTFxBZydXs48S+I/rVQvQtwkRh3rOcZpwTMsGzfoiCsOhEaiBOFk0C5FEKi um55SDXCMR6yXDhWqFPBIdle4izj5g2YmuZ3YD4G3PlcX5okW7aKTNU3RGWEOMk3 Ob9bkPnCsY7Ei4OqDqTBt/8HH/2kA4om4RzKGLw5Zc/Y+KhpbFhT52gtL7WDEEVZ NqFHgi6fdHgsczFNpCKhC8vM+mAM/gBiVR8hYIpt5lPFyXpFJO5Wn5BcEkv3 -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFxDCCA6ygAwIBAgIQV3/H8mpwNp5raCafwOtSezANBgkqhkiG9w0BAQsFADB7 MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UE CxMeU2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSgwJgYDVQQDEx9QS0kg WmVybyB0byBIZXJvIFNhbXBsZSBSb290IENBMCAXDTI1MDEwMTAwMDAwMFoYDzIw NTAwMTAxMDAwMDAwWjB7MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8g dG8gSGVybzEnMCUGA1UECxMeU2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVk MSgwJgYDVQQDEx9QS0kgWmVybyB0byBIZXJvIFNhbXBsZSBSb290IENBMIICIjAN BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnYTGHkYMca54QPkZcZENin3BHB3t uKdHkDZeKZvJHWqpfXpcZfusLvtJFeTrwWlEDBJuV20vmhaLeV29QeYKaIkm1Ul2 qCkrLUpWn/W9CPosfVqMd1nOrd+Ka9iPSeKlW3YX1P5WqQEjieJhBzT9comdj8qN /PynceTDcLa2mgYw7QhU8trBoLzhYqIJFfoUBk+7lahae8b9G5wKCbDicRM8/ATt 0dO9jCxi6RxJpkKl24ULgNOuFP9gG4nubWA8+BaMeM0LU64wNciFofgM2g/3iHHn zmcoe1z80C7WN+GuzNkWkN8D/tcqrbua0O5fREKKw6PyyxwQsjeMghpxLb0h1KeA ihpQMVgpWbhRkkpvF5odkF9vTJP89Z2y+8cgnUMyTpXATrt8KgC5LdWo5mlTNXC/ MvbCUb1Vz9bvcEx2y29tUeLIAUmyBzhF7zgMUPAOtDbLLCuxgR78T2TWaXB/8WBT XL44Wk5rOe7U+KuBr/t12AcZjaq0AGiNsvfd1P+IFbRivElegpdrM+S3arjOjptP M9sUl9Hc+cszaTpEVcQFFxcIyvq5HVjTlZr4vLKdqlhSkQB9hZUFuWNpnUZEYEnA 1vn/GkHNTJ6pv8XxdNXkFeRaUv3ajCn7CQ3UP/EXJqzBw5fl6aa9lqKTS5kF9rgw EIhwNaSd2O557KUCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFIVx1Hy1TuED0pMkxEcdM+DWWPGiMA0GCSqGSIb3DQEB CwUAA4ICAQBMdaOOM84aoItvumQ/sNzOhXvmLwboTb3oe67wda9TvPMSf2aP3JtP UWsR/9UbZgNE9M41p2+XZlVpsGP1BLEvi5ZwfMWmR876Mw1Zkt8ouY3DWN08egnm IdV2vKwDHhDE93IQ12fjNc8iuMCasoYiXTsmXx3R/+PkNbeBAupZEk6EwTr75PCY IJ2cheL7jQ06xeCCZv815rG+63jGk3tys7A+nUXKqOp9oN/dkEhi+YWiHG9UJ2w/ BDZCFUUoJBia7C3+hcXZAVxtWwTy0A5T/plEsqGcdfCMFA4cOFstthyS/Wnnuw8y cpSiXdUAQbLkJ+CGavr6MXVmDicmnV9p3Pv9EbpGPV8UlxwvoQMf+ajEE4EAaJkN Gc85wOC7Y7wwWkBnzjiyLztqRqOFdHEdM13V+2Gw2545Jk8o2gRizBQ6Ey6rlt2u YdYFqFFQhe2H+VqvJiLKefkN1mVQhvhfAvuoxZWIsDtyJWGs12L06xMj3wG98kne mUJjPzze3swZU39eiaC1MBs6U0oLZE6ZqubmjJd/ppmGyK+7o2SMi0juouvw6rcA J9eUJQLNpiVKmiwzKvPejASpunK5B5JO3Y7NAb4SVU22ItR73bBiRAugPwVajlBN RGcjMkDSiW07/dhN6GgjsNAzXHcTR7/nbILOAWbhBstNFK1mgejlbQ== -----END CERTIFICATE-----

Every certificate the server sends, leaf first. The output of openssl s_client -showcerts -connect example.com:443 works as it is: we ignore the text around the certificates.

Check the chainClearChoose a file

Are you ready for a distrust?

• Know your CAs. Your inventory should say which CA issued each certificate (see Inventory, expiry and renewal). Certificate Transparency searches show what was issued for your names.
• Follow the root programs. Chrome, Mozilla, Apple and Microsoft announce distrust decisions publicly, months ahead.
• Be able to switch CA in weeks. With ACME, switching is mostly a change of directory URL and a test run. With manual renewals, it is a project.

Are your old clients ready for root changes?

Servers that call other services are clients too. Check the TLS library and the CA bundle on old hosts, containers, appliances and embedded devices:

openssl version

OpenSSL 3.2.3 3 Sep 2024 (Library: OpenSSL 3.2.3 3 Sep 2024)

Java applications use their own trust store, and many appliances have one you can only update with firmware. When a client fails after a root change, the error pages explain the symptoms: certificate has expired and NET::ERR_CERT_AUTHORITY_INVALID.

What do the expiry post-mortems teach?

• Monitor what clients see, the live endpoint, not only the certificate store (Azure).
• Cover internal names and security devices, not only public websites (Epic Games, Equifax).
• Automate renewal, and give each service its own certificate so that one expiry cannot take down everything.
• Alert on a share of the lifetime, not a fixed number of days. Azure’s rule after its outage was an incident for any certificate with “less than 3 months until the expiration date”. With certificates limited to 47 days from 15 March 2029, that rule would fire from the day of issue.

An expired certificate looks like this in the decoder, and like NET::ERR_CERT_DATE_INVALID in Chrome:

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----- MIIC1jCCAnygAwIBAgIQNPchftz8jn6EE0nYthv4IzAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI1MTEwMTAwMDAwMFoXDTI2 MDEzMDAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEnFxMTbSS6N//zfTxXpHxlwQXb/vUy+GJ0VD/hV2T qh4hwe8YIotO6LTc8gcoN7U/lzWAxB0YGCQNdl3ZkaeNC6OCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FLePvyuDFGAE/tNEqDYHGxSlxoD9MB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSAAwRQIhAM8HGMZHERBn faVlrjwlVBfFzLIBiMhxHlwupcIdsXYfAiBjweZeZ9ch63PQ3YYp81rY4QHX1y9Q vdp9yJS+yypzgg== -----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

Common mistakes

• “One CA was hacked, so PKI is broken.” The system reacted: browsers removed DigiNotar within weeks, and Certificate Transparency now exposes rogue certificates to everyone. One CA failing is a reason for monitoring, not for giving up on PKI.
• “Distrust kills every certificate at once.” Browsers usually distrust by issue date. Certificates issued before the cut-off keep working until they expire, which gives owners time to move.
• “Only my own certificate can expire.” Roots, intermediates and cross-signatures expire too, as DST Root CA X3 showed.
• “Expiry outages only happen to small companies.” Microsoft, Google and Epic Games published their own post-mortems.
• “Our monitoring covers every certificate.” Epic’s monitoring missed an internal zone, and Equifax’s expired certificate sat on a security device. Check what your monitoring actually covers.

Check yourself

Check yourself

A browser announces that it will distrust a CA. Your site uses a certificate from that CA, issued last month. What usually happens?

1. The site breaks on the announcement day
2. The certificate keeps working until it expires; the next one must come from another CA
3. Nothing ever changes for existing customers

Show answer

Answer B The certificate keeps working until it expires; the next one must come from another CA

What happened

Distrust usually applies to certificates issued after a cut-off date.

Why

Root programs set cut-offs so that site owners can move to another CA without a sudden outage.

The rule

Distrust comes with a deadline. Be able to switch CA within weeks.

Check yourself

When DST Root CA X3 expired, why did some clients fail even though they trusted ISRG Root X1?

1. Their OpenSSL 1.0.2 picked the path to the expired root
2. Let's Encrypt revoked all its certificates
3. Browsers stopped supporting RSA

Show answer

Answer A Their OpenSSL 1.0.2 picked the path to the expired root

What happened

OpenSSL 1.0.2 preferred the chain the server sent, which led to the expired DST root.

Why

Path building differs between TLS libraries, and old libraries can choose an expired path.

The rule

Every certificate in a chain can expire. Keep TLS libraries and trust stores up to date.

Check yourself

At Equifax, what did an expired certificate on a traffic-inspection device cause?

1. A website outage that customers reported
2. Encrypted traffic went uninspected, so an intrusion was missed for about 76 days
3. Browsers showed a warning on the company's site

Show answer

Answer B Encrypted traffic went uninspected, so an intrusion was missed for about 76 days

What happened

The device stopped inspecting encrypted traffic while its certificate was expired.

Why

A security device with an expired certificate can fail silently, without any visible outage.

The rule

Monitor certificates on security devices and internal systems, not only on public websites.

Go deeper

• Black Tulip: the DigiNotar investigation: the official report on how the breach happened and was found.
• Chrome’s plan to distrust Symantec: the reasons and the phased timeline.
• Entrust certificate distrust: Chrome’s decision and how the SCT-based cut-off works.
• Let’s Encrypt: DST Root CA X3 expiration: which clients were affected and why.
• OpenSSL: the Let’s Encrypt root expiry: why OpenSSL 1.0.2 chose the expired path, and the workarounds.
• GAO-18-559: the US Government Accountability Office report on the Equifax breach.

In the gameLevel 18: Famous failuresOld Archive, Keystone. In development

The crash course covers these failures in lesson 8, When trust breaks.