Here is a failure your monitoring is built to miss. Somebody — an attacker who briefly controlled your DNS, a subdomain you forgot you delegated, an ex-vendor whose access was never revoked, or a phishing operator standing up login.yourbrand.com on infrastructure you don't own — gets a certificate authority to issue a valid, publicly-trusted TLS certificate for a name under your domain. It is a real certificate. Browsers trust it. And it is never served on your origin, so nothing you watch will ever connect to it: your uptime check gets a 200 from your real server, your SSL-expiry monitor reads your real certificate's notAfter, and every dashboard stays green while a certificate you never ordered is out in the world with your name on it.
The one place that certificate is guaranteed to appear is a system most teams don't watch at all — the Certificate Transparency logs. Watching them is the difference between finding out from a log and finding out from a customer who got phished.
What Certificate Transparency Actually Is
Certificate Transparency (CT), specified in RFC 6962, is a public, append-only, cryptographically-verifiable record of certificates. When a CA issues a certificate, it submits it to a set of independent CT logs, each of which returns a signed certificate timestamp (SCT) — a promise that the certificate has been publicly recorded.
