Cloudflare Reaches General Availability for Certificate Transparency Monitoring by Filtering Internal Renewals

Cloudflare Reaches General Availability for Certificate Transparency Monitoring by Filtering Internal Renewals Cloudflare has announced the general availability of its Certificate Transparency (CT) Monitoring tool, introducing a deduplication and filtering mechanism that eliminates noisy alerts generated by its own automated certificate issuances and renewals. Certificate Transparency Monitoring has reached general availability and is enabled on over 650,000 customer domains. Previously, routine renewals from Universal SSL, Advanced Certificate Manager, and backup certificates flooded customers with unnecessary alerts. Cloudflare resolved the issue by indexing the SHA-256 hash of the SubjectPublicKeyInfo (SPKI) during CSR generation to match certificates seen in CT logs against internal orders. Future updates plan to integrate CT alerts into Cloudflare Notifications for routing via webhooks, PagerDuty, and custom email destinations. Alert Noise from Routine Renewals Since its public beta launch in 2019, CT Monitoring notified domain owners whenever a new TLS certificate appeared in public logs. However, because Cloudflare automatically renews certificates—sometimes as frequently as every 60 days, with validity periods dropping further by 2029—customers received repeated notifications for expected, internal operations. This noise led some users to ignore or disable the feature entirely. The Technical Race Condition Filtering internal certificates was complicated by the separation of the certificate ordering service and the CT alerting service. During issuance, certificates generate two log entries: a pre-certificate and a final certificate. The existing deduplication fingerprint could only be produced once the ordering service received the final certificate, creating a timing window where pre-certificates in the alerting flow lacked matching internal records and triggered false alerts. Filtering via Public Key Identification To bridge the systems early, Cloudflare selected the SubjectPublicKeyInfo (SPKI) structure, which remains consistent across the CSR, pre-certificate, and final certificate. Because Cloudflare generates unique keypairs for every order, the ordering service computes and stores an SHA-256 hash of the DER-encoded SPKI (`spki_sha256`) immediately upon key generation. When the alerting service detects a new log entry, it calculates the same hash to confirm if Cloudflare issued the certificate, suppressing alerts for internal certificates regardless of which log entry appears first. Availability and Future Integration The filtering mechanism is active automatically for existing users across all plan tiers at no extra charge. Updated email alerts now display the hostname in the subject line, provide certificate details, and link directly to the Cloudflare dashboard. Moving forward, Cloudflare plans to integrate these alerts into Cloudflare Notifications to support destinations like webhooks and PagerDuty.

Cloudflare 证书透明度监控正式商用：引入公钥哈希过滤自身证书告警 Cloudflare 宣布证书透明度监控（Certificate Transparency Monitoring）正式进入通用可用阶段（GA），通过将系统自动签发的证书进行静默过滤，彻底解决客户因常规证书轮换而面临的告警轰炸问题。 自 2019 年公测以来，该功能已覆盖超过 65 万个客户域名，但频繁的自动续签常导致正常告警淹没在海量通知中。 为区分内部与外部签发，Cloudflare 采用基于 SubjectPublicKeyInfo 的 spki_sha256 作为统一标识符，在预证书与正式证书入库前消除竞态问题。 系统即日起自动对所有用户启用过滤功能，仅在检测到非 Cloudflare 签发的证书时触发提醒，并在所有套餐级别免费提供。 解决频繁轮换带来的告警噪音 Universal SSL 证书最快每 60 天轮换一次，加之 CA/浏览器论坛投票决定在 2029 年前将证书最长有效期缩短至 47 天，合规证书的公共日志记录量激增。此前，监控系统无法识别日志中的证书是否由 Cloudflare 自身自动化系统签发，导致用户因收到过多常规续签提醒而疲劳，甚至关闭告警，增加了漏报真正异常签发的安全风险。 基于 SPKI 哈希的技术打通方案 签发服务与日志监控服务彼此独立。针对证书签发阶段存在的预证书（pre-certificate）和最终证书两次记录问题，早期去重使用的 stripped_fingerprint 存在时间差和竞态条件。Cloudflare 最终选用公钥结构 SubjectPublicKeyInfo（SPKI），在生成密钥和 CSR 时即计算出定长的 spki_sha256 存入数据库。当监控模块从公共 CT 日志解析出证书时，会重新计算该哈希并进行匹配，从而可靠地识别并静默过滤自身签发的证书。 体验升级与后续支持计划 优化后的告警邮件将在主题中明确受影响的主机名，并附带证书细节和控制面板直达链接。现有监控用户无需手动操作即可直接享受过滤机制；新用户可在全线套餐中免费启用。此外，Cloudflare 计划将该监控接入 Cloudflare Notifications，未来支持向 Webhook、PagerDuty 等多渠道分发告警。

Since we launched [Certificate Transparency Monitoring in public beta](https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/) in 2019, we've been emailing subscribers whenever a new TLS certificate appears in a public [Certificate Transparency](https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/) (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](https://developers.cloudflare.com/ssl/reference/certificate-validity-periods/), up to about six times a year. That cadence is set to increase, with the [CA/Browser Forum](https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods) 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](https://datatracker.ietf.org/doc/html/rfc6962?cf_target_id=FB76C3BCC6BDA462922440973DD1A472) 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](https://developers.cloudflare.com/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](https://dash.cloudflare.com/), 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](https://community.cloudflare.com/top?period=daily). That input will shape the customization controls we build next.