Since we launched Certificate Transparency Monitoring in public beta in 2019, we've been emailing subscribers whenever a new TLS certificate appears in a public Certificate Transparency (CT) log for one of their domains. Today, it's turned on for more than 650,000 customer domains. It's an early warning that someone, somewhere, has issued a certificate for a hostname in your zone, giving you a chance to spot a mis-issued certificate early.
It's a useful signal, but it had a noise problem, and we felt it ourselves. Cloudflare issues a large volume of certificates on your behalf: Universal SSL renewals, certificates from Advanced Certificate Manager, and backup certificates. All of them are logged to public CT logs by design, because a certificate that isn't logged won't be trusted by major browsers like Google Chrome and Apple's Safari.
So the same transparency that lets you monitor for mis-issuance also surfaces every certificate we issue for you. And issuance isn't a one-time event. Certificates are short-lived and renew automatically: a single Universal SSL certificate can renew as often as every 60 days , up to about six times a year.
That cadence is set to increase, with the CA/Browser Forum having voted to cut the maximum certificate lifetime to 47 days by 2029, multiplying the routine renewals that flow through those logs. Every one of those renewals generated an alert. But at the scale Cloudflare issues certificates, a genuinely suspicious one could look just like a routine renewal, and the alert that mattered was easy to miss.
We heard the same thing from customers. On our 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.
Today, we're changing that. Certificate Transparency Monitoring now filters out the certificates Cloudflare issued on your behalf before an alert is sent. The alerts that reach your inbox are the ones that deserve your attention: a certificate you didn't expect, that Cloudflare didn't issue.
With that fix in place, Certificate Transparency Monitoring is generally available. Filter out the certificates Cloudflare manages The goal is to identify and eliminate noisy alerts for routine, Cloudflare-managed certificate issuances and renewals while ensuring we catch all external certificates managed outside our system. Why couldn't we just identify and filter these out previously?
There are two independent systems built to serve separate products: certificate management, which deals with internal certificate issuance data, and CT alerting service, which parses data from 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 is deciding whether to email you, all it has is what it pulled from the log.
It has no signal from the issuance flow saying "the ordering service just created this one." That missing link was the problem. What is the lifecycle of a certificate?
As shown above, certificate issuance happens in two stages: Certificate Authority (CA) creates a pre-certificate, writes to logs and receives SCTs (Signed Certificate Timestamps). CA embeds those SCTs into the final certificate and logs it. Thus, the alerting service sees two log entries for a single certificate order: 1) pre-certificate and 2) final certificate.
To avoid alerting twice per pair, an internal identifier called stripped_fingerprint is stored for deduplication purposes. This fingerprint is the hashed value of DER (Distinguished Encoding Rules)-encoded TBSCertificate (to be signed certificate). This value is consistent and unique for a pre-certificate/final certificate pair that belongs to the same certificate order.
Therefore, this is one identifier which is already present, and it sits entirely inside the alerting flow. Why does the obvious fix fail? The intuitive shortcut is to copy stripped_fingerprint into the ordering service so the alerter can look it up.
But that doesn't work because the ordering service doesn’t receive the pre-certificate, so it can't produce this value when the alerting service receives it. So even if this is used as an identifier, it can only be recorded after the final certificate is received by the ordering service. In that window between pre-cert and final cert log entries, if the alerting service looks up stripped_fingerprint(precert) in the ordering service’s database, then it is not going to find any information matching this identifier to confirm that it is issued by us — and this leads to an extra alert again.
Although the certificate ordering service is the right system to answer “Is this ours?” , the match key with which this information was being uniquely identified is not winning the race. So the problem reframed itself.
The question was no longer where to store the fingerprint, but what is that one identifier which can be persisted from order creation to the final logged certificate. What is the right key? The right key had to check these boxes: Early : recorded before anything reaches the log, i.
e. , present at key generation. Consistent : throughout all stages from pre-certificate to final certificate.
Reproducible : the CT alerting service can recompute it independently, from the log entries alone. Unique : to each certificate order. The public key is one such identifier that checks all those boxes.
It travels inside a structure called SubjectPublicKeyInfo (SPKI). Consistency : As the diagram above shows, SubjectPublicKeyInfo (SPKI) is present from the first step and stays the same through the CSR (Certificate Signing Request), pre-certificate, and final certificate. Uniqueness and Safety : Cloudflare generates a fresh keypair for every issuance, so the public key is effectively unique.
Originally published at blog.cloudflare.com
