Engineers face alert fatigue from routine certificate renewals. By filtering out managed certificates using SPKI hashes, Cloudflare improves the signal-to-noise ratio for CT monitoring. This allows security teams to focus on actual mis-issuances and potential domain hijacking attempts.
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.
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.
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.
As shown above, certificate issuance happens in two stages:
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.
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.
The right key had to check these boxes:
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. Since only Cloudflare has the private key, a certificate with a matching SPKI must have come from a Cloudflare issuance only. A collision is astronomically unlikely, and no outsider could create a valid signing request without the private key.
So the identifier we record is spki_sha256 — an SHA-256 hash of the DER-encoded SPKI, a short fixed-length value that's cheap to index. The ordering service computes it straight off the CSR and writes it at key generation, before issuance begins.
Recording the key early solves this in the certificate ordering. With that in place, the alerting flow performs an extra step. When the alerter sees a log entry, it recomputes spki_sha256 from the certificate's public key and looks it up to see if the ordering service has recorded this value in its database – on:
Because the key is identical in the pre-certificate and the final certificate, it no longer matters which one arrives first.
Three things follow, all toward less noise:
Most of the work here wasn't writing the fix; it was understanding both flows well enough to see that the key connecting them was a field we'd been carrying the whole time. Once we picked the identifier that's early and shared, the rest was bookkeeping.
CT alerting should fire only on issuance we can't account for. With this change, it does.
Updated emails identify the affected hostname in the subject line, include certificate details in the message, and link to the certificate in the Cloudflare dashboard, so you can review it and take action as needed.
We plan to bring Certificate Transparency Monitoring to Cloudflare Notifications. This would let teams route CT alerts to webhooks, PagerDuty, or additional email destinations, just as they manage other Cloudflare alerts, instead of relying on today’s email-only channel.
Already using Certificate Transparency Monitoring? There is nothing you need to do. Filtering is already enabled. Starting today, you will only be notified of certificates issued outside of Cloudflare's automated systems.
Not using it yet? In the Cloudflare dashboard, go to SSL/TLS → Edge Certificates → Certificate Transparency Monitoring and turn it on. Available on every plan at no extra cost, with unified settings across plan tiers, so you can manage alert recipients in one consistent view.
If you have thoughts on how Certificate Transparency Monitoring should evolve, let us know through your account team or the Cloudflare Community. That input will shape the customization controls we build next.
Continue reading on the original blog to support the author
Read full articlePost-quantum DNSSEC is vital to prevent future quantum computers from forging DNS records. This update addresses the technical hurdles of large signature sizes and transport reliability, ensuring the long-term integrity of the global DNS hierarchy against emerging cryptographic threats.
Automatic Key Exchange significantly reduces handshake latency by eliminating unnecessary round trips while transparently upgrading origin connections to post-quantum security. This balances performance with future-proof encryption without requiring manual intervention from developers.
Route leaks cause massive internet outages. RFC 9234 replaces manual, error-prone routing policies with protocol-level enforcement. Understanding its adoption and the challenges of attribute stripping is crucial for engineers managing global network stability and security.
The massive surge in hyper-volumetric attacks and the shift toward DNS-based reflection require engineers to prioritize automated, always-on mitigation. With attacks often lasting only seconds but causing hours of instability, manual response is no longer a viable defense strategy.
