Cloudflare's CT alerts only became useful once it stopped alerting on itself

Cloudflare has taken Certificate Transparency Monitoring out of the public beta it started in 2019 and now runs it on more than 650,000 customer domains ^[1][2]. The change that earned it the general availability label is a filter that strips out certificates Cloudflare issued on the customer's behalf before an alert goes out ^[3], which is another way of saying the beta spent years emailing people about Cloudflare's own automation.

The mechanics are not mysterious. Cloudflare issues a large volume of certificates for customers: Universal SSL renewals, Advanced Certificate Manager certificates, and backup certificates ^[4]. All of them are written to public CT logs by design, because a certificate that is not logged will not be trusted by Chrome or Safari ^[5]. The same transparency that lets you watch for mis-issuance therefore surfaces every certificate your provider issues for you ^[6], and every one of those renewals generated an alert ^[7]. A single Universal SSL certificate can renew as often as every 60 days, up to roughly six times a year ^[8]. The CA/Browser Forum has voted to cut the maximum certificate lifetime to 47 days by 2029 ^[9], which on the same arithmetic is closer to seven or eight routine renewals per certificate per year ^[10]. Cloudflare's own framing is blunt: at its issuance scale, a genuinely suspicious certificate could look just like a routine renewal, and the alert that mattered was easy to miss ^[11].

Customers reached the obvious conclusion first. Cloudflare quotes a community forum user who turned the feature off across all their sites, "tired of regularly getting spammed with tons of completely normal certificate renewals," and added, "I wasn't even actually reading them by the end" ^[12]. Cloudflare says that noise came from its own certificates ^[13].

The reason this took until now is worth more than the announcement. Certificate management and CT alerting are two independent systems built for separate products, and when the alerting flow decides whether to email you, all it has is what it pulled from the public log, with no signal from the issuance side saying that the ordering service just created this one ^[14]. Issuance is also two-staged: the CA creates a pre-certificate, logs it, and receives SCTs, then embeds those SCTs in the final certificate and logs that ^[15]. So the alerter sees two log entries per order ^[16] and already deduplicates them using an internal identifier, stripped_fingerprint, a hash of the DER-encoded TBSCertificate that is stable across a pre-certificate and final certificate pair and lives entirely inside the alerting flow ^[17]. The intuitive fix, copying that identifier into the ordering service so the alerter can look it up, fails because the ordering service never receives the pre-certificate and cannot compute the value at the moment the alerter needs it ^[18]; it can only record it once the final certificate arrives ^[19].

That is the general lesson for anyone building monitoring on public data: the log tells you a certificate exists, not who asked for it. Distinguishing your own automation from someone else's issuance requires a join back to internal state, and the join is the hard part, not the email.

Two things to watch. First, the 47-day lifetime schedule means the noise floor rises for everyone running their own CT alerting on provider-fronted zones ^[9], and the filtering problem Cloudflare just solved for its customers is one those teams still own. Second, the filter is defined by exclusion of Cloudflare-issued certificates ^[3], so anything issued through that pipeline no longer produces an alert by construction ^[20]. The published excerpt describes why the obvious fix fails but stops before the working design, so how the gap between pre-certificate and final certificate is actually closed is the part to read carefully when the full write-up is in front of you ^[19].