CT Monitoring cuts through renewal noise
Since Certificate Transparency (CT) Monitoring launched in public beta in 2019, Cloudflare has emailed subscribers whenever a new TLS certificate shows up in a public CT log for one of their domains. The service now covers more than 650,000 customer domains and serves as an early warning system for potentially mis-issued certificates.
But the signal came with noise — much of it generated by Cloudflare itself. Universal SSL renewals, Advanced Certificate Manager certificates, and backup certificates are all logged to public CT logs by design, since major browsers won't trust certificates that aren't logged. With certificates renewing as often as every 60 days — and the CA/Browser Forum voting to cut maximum certificate lifetime to 47 days by 2029 — routine renewals flood the logs. Every one of those renewals triggered an alert, making genuinely suspicious certificates easy to miss.
Customers noticed. On Cloudflare's community forum, one described disabling the feature across all their sites because they were "tired of regularly getting spammed with tons of completely normal certificate renewals," adding, "I wasn't even actually reading them by the end."
That noise came from Cloudflare's own certificates. The fix: CT Monitoring now filters out certificates Cloudflare issued on your behalf before sending an alert. With that in place, the feature is generally available.
Connecting two independent flows
The core problem was architectural. Two separate systems handle certificates: the certificate management flow, which deals with internal issuance data, and the CT alerting service, which parses public CT logs.
The two flows handle the same certificate, but never at the same moment and never with the same information. When the alerting flow decides whether to email you, it only has what it pulled from the log — no signal from the issuance flow saying "the ordering service just created this one."
Certificate issuance happens in two stages:
- The Certificate Authority (CA) creates a pre-certificate, writes it to logs, and receives Signed Certificate Timestamps (SCTs).
- The CA embeds those SCTs into the final certificate and logs it.
The alerting service thus sees two log entries per certificate order: pre-certificate and final certificate. To avoid alerting twice per pair, the service stores an internal identifier called stripped_fingerprint — a hashed value of the DER-encoded TBSCertificate. This value is consistent and unique for a pre-certificate/final certificate pair within the same order.
The obvious fix — copying stripped_fingerprint into the ordering service — failed because the ordering service doesn't receive the pre-certificate. It can't produce the value when the alerting service receives it. In the window between pre-cert and final cert log entries, a lookup for stripped_fingerprint(precert) in the ordering service's database would find nothing, triggering another alert.
The real question became: what identifier can persist from order creation to the final logged certificate?
The public key as the missing link
The right key had to meet four criteria:
- Early: recorded before anything reaches the log, present at key generation.
- Consistent: throughout all stages from pre-certificate to final certificate.
- Reproducible: the CT alerting service can recompute it independently from log entries alone.
- Unique: to each certificate order.
The public key fits all four. It travels inside SubjectPublicKeyInfo (SPKI), which appears in the CSR, pre-certificate, and final certificate identically. Cloudflare generates a fresh keypair for every issuance, making the public key effectively unique. Since only Cloudflare holds the private key, a certificate with a matching SPKI must be a Cloudflare issuance. A collision is astronomically unlikely, and no outsider could create a valid signing request without the private key.
The identifier recorded is spki_sha256 — an SHA-256 hash of the DER-encoded SPKI. This short, fixed-length value is cheap to index. The ordering service computes it directly from the CSR at key generation, before issuance begins.
How filtering works now
When the alerting service sees a log entry, it recomputes spki_sha256 from the certificate's public key and checks whether the ordering service has recorded that value:
- Match → the certificate is Cloudflare's. The alert is suppressed.
- No match → the key isn't found. The alert fires as before.
Because the key is identical in pre-certificate and final certificate, arrival order no longer matters.
Three categories of noise are eliminated:
- Cloudflare-managed certificates — Universal SSL, Advanced Certificate Manager, Total TLS, and Backup Certificates all match a recorded key and pass silently.
- Abandoned pre-certificates — when a pre-cert is logged but issuance never completes, it now matches a record and stays quiet. The event is still recorded on Cloudflare's side.
- Custom uploaded certificates — these still alert. Cloudflare didn't generate those keys, so there's no issuance-side record to suppress them. That's exactly the case CT monitoring exists for.
Alert emails have also been improved. The subject line identifies the affected hostname, the message includes certificate details, and a link points to the certificate in the Cloudflare dashboard for review.
What's ahead
Cloudflare plans to bring CT Monitoring into Cloudflare Notifications, letting teams route alerts to webhooks, PagerDuty, or additional email destinations instead of relying on the current email-only channel.
Getting started
Existing CT Monitoring users don't need to do anything — filtering is already enabled. Notifications will only arrive for certificates issued outside Cloudflare's automated systems.
For new users, the feature is under SSL/TLS → Edge Certificates → Certificate Transparency Monitoring in the Cloudflare dashboard. It's available on every plan at no extra cost.
