News

Cloudflare's CT Monitoring Goes GA with Noise-Killing SPKI Filter

Cloudflare's Certificate Transparency Monitoring is now generally available, with a key fix: filtering out Cloudflare-issued certificates using SPKI hashes to eliminate alert fatigue.

August 13, 2026· 3 min read· Source: Cloudflare Blog
Cloudflare's CT Monitoring Goes GA with Noise-Killing SPKI Filter

Cloudflare has announced that its Certificate Transparency (CT) Monitoring service is now generally available, and the headline change is a long-overdue fix for alert fatigue. The service, which emails customers whenever a new TLS certificate appears in a public CT log for their domain, was drowning in noise — most of it from Cloudflare's own automated certificate issuance.

The problem was fundamental: Universal SSL renewals, Advanced Certificate Manager, and backup certificates all get logged to public CT logs by design (unlogged certs aren't trusted by Chrome or Safari). With certificates renewing as often as every 60 days, and the CA/Browser Forum pushing to cut maximum certificate lifetime to 47 days by 2029, the volume of routine renewals was exploding. Customers were tuning out, with one community forum user describing disabling the feature entirely because they were 'tired of regularly getting spammed with tons of completely normal certificate renewals.'

The technical fix: SPKI as the shared identifier

The core challenge was that two independent systems — the certificate ordering service and the CT alerting service — handled the same certificate but never shared a common identifier at the right time. The alerting service only saw log entries, while the ordering service had issuance data but no way to correlate it.

The obvious candidate, stripped_fingerprint, failed because it's derived from the pre-certificate, which the ordering service never sees. By the time the final certificate arrives, the alerting service has already processed the pre-cert log entry and potentially fired an alert.

The solution: use the public key, specifically an SHA-256 hash of the DER-encoded SubjectPublicKeyInfo (SPKI), called spki_sha256. This identifier checks all the boxes:

  • Early: recorded at key generation, before anything hits the log.
  • Consistent: identical across CSR, pre-cert, and final certificate.
  • Reproducible: the alerting service can recompute it from log entries alone.
  • Unique: Cloudflare generates a fresh keypair per issuance, making collisions astronomically unlikely.

Now, when the alerting service sees a log entry, it recomputes spki_sha256 and checks the ordering service's database. A match means the certificate is Cloudflare-managed and the alert is suppressed. No match means it's external — and the alert fires as before.

What this means in practice

The filtering covers Universal SSL, Advanced Certificate Manager, Total TLS, and backup certificates. It also silences abandoned pre-certificates — those logged but never completed — which previously looked like unexplained certificates. Custom certificates you upload still trigger alerts, since Cloudflare didn't generate those keys.

The email alerts themselves have been improved too: subject lines now include the affected hostname, and the body links to the certificate in the Cloudflare dashboard for quick review.

What's next

Cloudflare plans to integrate CT Monitoring with its Notifications system, allowing teams to route alerts to webhooks, PagerDuty, or additional email destinations. The feature is available on all plans at no extra cost, and existing users need to do nothing — filtering is already enabled.

The alerts that reach your inbox are the ones that deserve your attention: a certificate you didn't expect, that Cloudflare didn't issue.
Manul X Editorial