Certificate Transparency Monitoring is now generally available¶

Summary¶

Cloudflare's Certificate Transparency (CT) Monitoring — a feature that emails a domain owner whenever a new TLS certificate for one of their hostnames appears in a public CT log — moved from 2019 public beta to general availability. The GA-blocking problem was not availability or scale (it already ran for 650,000+ customer domains) but alert noise: Cloudflare itself issues a large, continuous volume of certificates on customers' behalf (Universal SSL renewals, Advanced Certificate Manager, Total TLS, backup certificates), all of which are logged to public CT logs by design — an unlogged certificate is not trusted by Chrome or Safari. Every routine renewal generated an alert, so the alert that actually mattered (a certificate you didn't expect, that Cloudflare didn't issue) was buried. The GA change: filter out Cloudflare-managed certificates before an alert is sent, so only externally-issued certificates surface. The engineering core of the post is how two independent asynchronous systems were made to agree on whether a given logged certificate was "ours" — a cross-system correlation-key selection problem solved by recording spki_sha256 (SHA-256 of the DER-encoded SubjectPublicKeyInfo) at key-generation time.

Key takeaways¶

Two independent systems, never sharing state at the same moment. Certificate management (the ordering service — knows internal issuance data) and CT alerting (parses public CT logs) are "two independent systems built to serve separate products." When the alerting flow decides 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." This is the reconciliation-of-two-async-flows shape, canonicalised as cross-system-correlation-key. (Source: sources/2026-08-13-cloudflare-certificate-transparency-monitoring-ga)
A certificate is logged twice — the pre-certificate / final certificate pair. Per RFC 6962, issuance happens in two stages: (1) the CA creates a pre-certificate, writes it to logs, and receives SCTs (Signed Certificate Timestamps); (2) the CA embeds those SCTs into the final certificate and logs that. So the alerting service sees two log entries per certificate order.
An existing dedup key (stripped_fingerprint) lives only inside the alerting flow. To avoid alerting twice per pair, the alerting service already stores a stripped_fingerprint — the hash of the DER-encoded TBSCertificate (to-be-signed certificate), consistent and unique across the pre-cert/final-cert pair. But it "sits entirely inside the alerting flow" — the ordering service never receives the pre-certificate, so it cannot compute this value.
The obvious fix loses a race. Copying stripped_fingerprint into the ordering service fails: the ordering service only sees the final certificate, so it can only record the fingerprint after the final cert is logged. In the window between the pre-cert and final-cert log entries, the alerting service looks up stripped_fingerprint(precert) in the ordering service's database, finds nothing, and fires a spurious alert. Canonical race condition: "the match key with which this information was being uniquely identified is not winning the race." The problem reframed itself — not where to store the fingerprint but what identifier can be persisted from order creation through to the final logged certificate.
The right key is early, consistent, reproducible, and unique. The four criteria the correlation key had to satisfy:
Early — recorded before anything reaches the log (present at key generation).
Consistent — identical across all stages (CSR → pre-cert → final cert).
Reproducible — the alerting service can recompute it independently, from the log entry alone.
Unique — to each certificate order. The public key (inside SubjectPublicKeyInfo, SPKI) satisfies all four. Cloudflare generates a fresh keypair per issuance, so the public key is effectively unique; only Cloudflare holds the private key, so a matching SPKI must have come from a Cloudflare issuance; collision is astronomically unlikely and no outsider can forge a valid CSR without the private key. The recorded identifier is spki_sha256 — a SHA-256 hash of the DER-encoded SPKI, a short fixed-length value cheap to index. The ordering service computes it straight off the CSR at key generation, before issuance begins.
Both flows agree by recomputation, not by messaging. The ordering service records spki_sha256 early. When the alerter sees a log entry it recomputes spki_sha256 from the certificate's public key and looks it up: match → suppress the alert (it's ours); no match → alert, exactly as before. Because the public key is identical in the pre-certificate and the final certificate, "it no longer matters which one arrives first" — the race is dissolved. Canonical reproducible-shared-key-for-async-reconciliation.
The change also silences abandoned pre-certificates. Sometimes a pre-certificate is logged but issuance never completes; those used to look like unexplained certificates and now match a recorded key and stay quiet. Custom certificates a customer uploads still alert — Cloudflare didn't generate those keys, so there's no record to suppress against, which is exactly the mis-issuance case CT monitoring exists for.
The hard part was understanding, not coding. "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."

Systems / concepts / patterns extracted¶

Systems: systems/certificate-transparency (the public-audit log framework this monitoring feature sits on top of); systems/cloudflare-universal-ssl and Advanced Certificate Manager / Total TLS / Backup Certificates (the Cloudflare issuance sources whose renewals drove the noise).
Concepts: cross-system-correlation-key (the central design lesson); precertificate-final-certificate-pair (the CT lifecycle detail that creates the double log entry); concepts/race-condition (the failure mode of the too-late key); concepts/idempotent-operations (sibling — a per-operation identifier making retried/duplicate events indistinguishable); verified-bots-adjacent "is this ours?" provenance question (structurally the same as distinguishing self-issued from externally-issued events).
Patterns: reproducible-shared-key-for-async-reconciliation (record an early, reproducible identifier at the source flow so a downstream flow can recompute-and-match without any cross-flow messaging).

Operational numbers¶

650,000+ customer domains had CT Monitoring turned on at GA.
A single Universal SSL certificate can renew as often as every 60 days, up to ~6 times a year.
The CA/Browser Forum voted to cut the maximum certificate lifetime to 47 days by 2029 — multiplying routine renewals flowing through CT logs (more noise over time, raising the value of the filter).
spki_sha256 = SHA-256 of the DER-encoded SubjectPublicKeyInfo; stripped_fingerprint = hash of the DER-encoded TBSCertificate.

Caveats¶

The post is framed as a product-GA announcement; its architectural substance is the ~60% of the body describing the correlation-key design (well over the 20% threshold — in scope per borderline rule).
Filtering is provenance-based: it suppresses only certificates whose public key Cloudflare generated. It does not suppress a Cloudflare-proxied certificate that a customer generated the key for and uploaded — by design, that is exactly the alertable case.
No throughput / latency numbers for the alerting pipeline are disclosed; the spki_sha256 lookup is described as "cheap to index" but no index-size or lookup-latency figures are given.
Roadmap (not shipped): routing CT alerts to Cloudflare Notifications (webhooks, PagerDuty, additional email destinations) beyond today's email-only channel.

Source¶

systems/certificate-transparency — the public CT-log framework this monitoring feature is built on; extended by this source with the monitoring-product + spki_sha256-filtering surface.
cross-system-correlation-key — the central design lesson (early/consistent/reproducible/unique key that lets two independent async systems agree).
precertificate-final-certificate-pair — why a single certificate order produces two CT log entries.
reproducible-shared-key-for-async-reconciliation — the engineering pattern (record an early reproducible key, recompute downstream, match without messaging).
concepts/race-condition — the failure mode of the too-late stripped_fingerprint key.
concepts/idempotent-operations — sibling identifier-for-dedup concept.