Cloudflare's Certificate Transparency (CT) Monitoring, in public beta since 2019, is now generally available across more than 650,000 customer domains. The core fix suppresses alerts for certificates Cloudflare itself issued on a customer's behalf (Universal SSL, Advanced Certificate Manager, Total TLS, backup certificates), which previously flooded inboxes with noise since Cloudflare certificates renew as often as every 60 days and CA/Browser Forum rules will cut max certificate lifetime to 47 days by 2029. The engineering fix relies on recording spki_sha256, a hash of the certificate's SubjectPublicKeyInfo, at key generation time in the ordering service, then having the CT alerting service recompute and match it against logged certificates to decide whether to suppress an alert. Custom uploaded certificates still trigger alerts since Cloudflare never generated those keys. Updated alert emails now include the hostname in the subject line and a dashboard link. Cloudflare plans to route CT alerts through its Notifications system (webhooks, PagerDuty) in the future.
Table of contents
Copy link Filter out the certificates Cloudflare managesCopy link Alerts are now easier to reviewCopy link What's nextCopy link Try itQuestions this post answers
Why did Cloudflare's Certificate Transparency Monitoring email me so many alerts for normal certificate renewals?
Because the CT alerting system had no way to distinguish certificates Cloudflare issued on your behalf from external ones, so every renewal of Universal SSL, Advanced Certificate Manager, Total TLS, or backup certificates triggered an alert. Since Cloudflare certificates can renew every 60 days, this created constant noise that made genuinely suspicious certificates easy to miss. Track infrastructure changes like Cloudflare's alerting fixes on daily.dev before noisy alerts erode trust in your monitoring.
How does Cloudflare's Certificate Transparency Monitoring now decide whether to suppress an alert for a new certificate?
It computes spki_sha256, a SHA-256 hash of the certificate's SubjectPublicKeyInfo, and checks it against a database the ordering service populated at key generation time. If the hash matches a Cloudflare-generated key, the certificate is confirmed as Cloudflare's own and the alert is suppressed; if there's no match, the alert fires because the certificate was issued outside Cloudflare's systems. Developers debugging certificate alerting pipelines can follow implementation details like this on daily.dev.
Will Certificate Transparency Monitoring still alert me about certificates I upload myself to Cloudflare?
Yes, custom certificates you upload continue to trigger alerts because Cloudflare never generated the keys for them, so there's no matching record in the ordering service to suppress the notification. This is exactly the scenario CT monitoring exists to catch, and it remains unaffected by the new filtering logic introduced with general availability. Teams relying on CT alerts for custom certificates can stay current on changes like this via daily.dev.