SYSTEM Cited by 4 sources

Certificate Transparency¶

What¶

Certificate Transparency (CT, RFC 6962) is a public-audit-log framework for TLS certificates: every certificate issued by a participating CA is appended to a public, append-only Merkle-tree log, and CT-capable clients (browsers) refuse to trust certificates not present in at least one trusted log. Original motivation (circa 2013): make CA mis-issuance detectable — any fraudulently-issued cert for amazon.com by a compromised CA would appear in the public log where Amazon's security team would observe it.

CT is a mature, widely-deployed system: Chrome requires SCTs (Signed Certificate Timestamps) from qualifying CT logs since 2018 for all publicly-trusted certificates; all major CAs participate; public log operators include Google, Cloudflare, DigiCert, Sectigo, Let's Encrypt.

Relevant to this wiki via its second application surface that emerged with the 2026 PQ-migration discussion: CT-as-downgrade-protection. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

How it works (core mechanism)¶

1. CA issues a certificate.
2. CA submits the certificate (or its pre-cert) to CT log(s).
3. Log returns a Signed Certificate Timestamp (SCT) — a promise
   to include the cert in a future Merkle tree head.
4. CA delivers cert + SCT to the subject (domain owner).
5. Server presents cert + SCT during TLS handshake.
6. Browser verifies:
   - cert chains to a trusted root, and
   - SCT is from a trusted CT log, and
   - SCT is valid for this cert.
7. Browser may also query the log for inclusion proof.

Independently, domain owners and security researchers monitor
public CT logs for certs issued for their domains — any
unexpected cert surfaces as immediate evidence of CA compromise
or mis-issuance.

The Merkle-tree-append-only structure makes the log tamper- evident: once a cert appears, it cannot be retroactively removed without the tamper being mathematically detectable via inclusion / consistency proofs.

The PQ-downgrade-protection use¶

Cloudflare's 2026 PQ post names CT alongside PQ HSTS as the feasible-for-federated- systems mechanism for blocking post-quantum downgrade attacks:

However, downgrade protection for HTTPS is still achievable using "PQ HSTS" and/or certificate transparency. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Cited elaboration: Bas Westerbaan (Cloudflare Research) RWPQC 2026 talk.

The insight: if an origin has PQ signature certs issued for it (visible in public CT logs), a browser observing a handshake offering only classical signatures for that origin has evidence of a likely downgrade attack. The detection logic:

During TLS handshake for origin O:
  - Server offers only classical signatures.
  - Client checks CT logs: does origin O have PQ certs in any
    log?
  - If yes → this is an attack, reject the handshake.
  - If no → accept classical (origin hasn't migrated yet).

The mechanism is detective, not preventive. It relies on the CT log being accessible to the browser and the browser being configured to enforce the check. False positives during migration transitions (cert issued but not yet actively used) require careful rollout.

CT's pre-existing trust assumptions make PQ use subtle¶

CT was designed before PQ was in scope; its own integrity guarantees depend on:

Log operators' signatures over tree heads — these must be PQ-secure themselves, or an adversary with a CRQC could forge alternate log histories.
SCTs carried in TLS certs — these must use PQ-secure signatures going forward.
Consistency / inclusion proofs — rely on a PQ-secure hash function (SHA-2 survives Grover with some security-margin degradation; most CT implementations are SHA-256 today and remain workable).

So the CT system itself requires PQ migration of its signing infrastructure before it can be a load-bearing downgrade- protection surface for PQ. This is in-scope for Cloudflare (a major CT log operator) and for the other log operators as part of the overall 2029 roadmap.

MTCs invert CT: "issue by logging"¶

The 2026-09-29 MTC-CA deep dive reframes CT's relationship to issuance. Today, transparency is an add-on: a CA signs a certificate and then submits it to logs, so certificates are frequently logged multiple times, in different forms, across multiple logs — forcing monitors to download and process every log and making a diverse set of log operators hard to sustain (Cloudflare estimates PQ signatures will grow the data CT logs must store by ~40×). Merkle Tree Certificates invert this with the principle "don't log what you issue, issue by logging" — the CA's issuance log is the source of truth, so transparency becomes a requirement for operation rather than an add-on. (Source: sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr)

The MTC design also changes CT's scaling properties in Cloudflare's favor: an MTC issuance log only needs to carry hashes of public keys — no per-entry signatures, and the single tree-head signature covers the whole log — which prevents the certificate-explosion problem and means log consumers fetch a single copy of each certificate.

Cloudflare's CT logs: Nimbus → Raio¶

Cloudflare has operated the Nimbus family of CT logs since 2016 and is launching Raio, a new family of static CT logs, implemented in the same Azul Rust transparency-log software that backs its MTC mirroring cosigner.

CT monitoring detects post-quantum downgrades¶

As domains upgrade to PQ authentication, CT monitoring takes on a new, higher-stakes role: detecting post-quantum downgrades. A domain owner who has moved to PQ authentication should watch CT logs for unexpectedly-issued legacy (classical) certificates, which would signal a malicious downgrade path attempting to force clients back onto forgeable classical cryptography. This is the same detective mechanism as the PQ-HSTS/CT downgrade-protection idea (below), now framed as an operational monitoring discipline for already-migrated domains.

CT vs MTC¶

Both use Merkle trees but for different purposes:

System	Purpose	Per-cert wire cost	Trust requirement
CT	Public audit log; mis-issuance detection	Full signature + SCT	Trust the CA chain + trust the log for detection
MTC	Reduce PQ signature wire cost via batching	Small inclusion proof only	Trust the PQ-signed batch root directly

CT is additive (augments existing trust); MTC is substitutive (replaces per-cert signatures with batch root signatures). They can coexist — MTC-issued certs can also appear in CT logs for audit.

CT Monitoring (the mis-issuance detection product)¶

CT's original application — the one predating the PQ-downgrade use above — is mis-issuance detection: a domain owner (or a service on their behalf) watches the public logs for any certificate issued for their hostnames, so a fraudulently- or accidentally-issued certificate surfaces as an early warning.

Cloudflare CT Monitoring productises this: it emails subscribers whenever a new certificate for one of their domains appears in a public CT log. Launched in public beta in 2019, it reached general availability in 2026 for 650,000+ customer domains. (Source: sources/2026-08-13-cloudflare-certificate-transparency-monitoring-ga)

The noise problem and the filtering fix¶

The GA blocker was alert noise, not scale. Cloudflare itself issues a large, continuous volume of certificates on customers' behalf (Universal SSL renewals, Advanced Certificate Manager, Total TLS, backup certificates), and all of them are logged to public CT logs by design — an unlogged certificate is not trusted by Chrome or Safari. Every routine renewal (a single Universal SSL cert can renew ~6× a year; the CA/Browser Forum is cutting max certificate lifetime to 47 days by 2029) generated an alert, drowning the alert that mattered: a certificate you didn't expect that Cloudflare didn't issue.

The GA fix filters out Cloudflare-managed certificates before an alert is sent. The engineering problem was reconciling two independent asynchronous systems that never share state at the same moment:

the certificate ordering service (internal issuance data), and
the CT alerting service (parses public CT logs).

Because a single order produces a pre-certificate and a final certificate — two log entries — and the alerting service only has what it pulls from the log, it needed an identifier it could recompute from a log entry and look up in the ordering service's store. The chosen key is spki_sha256 — SHA-256 of the DER-encoded SubjectPublicKeyInfo. It is early (computed off the CSR at key generation), consistent (identical across CSR → pre-cert → final cert), reproducible (recomputable from the certificate's public key), and unique (fresh keypair per issuance). The ordering service records it before issuance; the alerter recomputes it per log entry and matches — match ⇒ suppress, no match ⇒ alert. Because the public key is identical in the pre-cert and final cert, arrival order no longer matters, dissolving the race that a TBSCertificate-hash key (stripped_fingerprint, recorded only after the final cert) lost. See cross-system-correlation-key and reproducible-shared-key-for-async-reconciliation.

Provenance falls out for free: only Cloudflare holds the private key for a given SPKI, so a matching spki_sha256 must have come from a Cloudflare issuance. Customer-uploaded certificates (keys Cloudflare never generated) have no matching record and still alert — precisely the mis-issuance case the product exists for.

Raw-scope caveats¶

This wiki page is scoped to what the Cloudflare 2026 post names about CT:

CT exists as a mature public-audit system.
Cloudflare names it as a downgrade-protection mechanism for the PQ transition in federated systems.
Bas Westerbaan's RWPQC 2026 slides are cited for the detailed argument.

Specific protocol internals (RFC 6962-bis, v2 log formats, monitor-implementation details, log-operator governance) are covered in the RFC and not further detailed in the Cloudflare post.

Seen in¶

sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr — the "issue by logging" inversion. MTCs fold issuance and transparency into one append-only log (transparency as a requirement for operation, not an add-on); the log carries only public-key hashes with no per-entry signatures; Cloudflare's Nimbus (since 2016) + new Raio static CT logs; and CT monitoring as the detector of PQ downgrades (watch for unexpected legacy certs on PQ-migrated domains).
sources/2026-09-29-cloudflare-building-a-certificate-authority-for-the-whole-internet — the CA-operator side. Cloudflare's announced public CA treats CT logging as part of the Web PKI accountability baseline it must satisfy, and goes beyond CT with additional voluntary transparency — reproducible builds of the signing software, attested HSMs, and a public issuance-health dashboard — with the framing that "audits are point-in-time and tell you a CA passed, not how it runs on an ordinary Tuesday." MTC-issued certs can still be logged to CT for audit.
sources/2026-08-13-cloudflare-certificate-transparency-monitoring-ga — wiki instance of CT's original mis-issuance-detection application: Cloudflare CT Monitoring reaching GA by filtering Cloudflare-issued certificates out of alerts via the spki_sha256 correlation key.
sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — wiki instance of CT's PQ-downgrade-protection application. Cloudflare names CT alongside PQ HSTS as feasible downgrade-protection mechanisms for federated HTTPS environments that cannot outright disable classical signatures.

concepts/downgrade-attack — the threat CT-based detection addresses in the PQ context.
systems/pq-hsts — complementary downgrade-protection mechanism.
systems/merkle-tree-certificates — sibling Merkle-tree- based system for PQ cert-size reduction; MTCs invert CT via "issue by logging."
systems/azul — Cloudflare's Rust transparency-log software behind both the MTC mirroring cosigner and the new Raio static CT logs.
concepts/post-quantum-authentication — the broader migration CT-for-downgrade-protection slots into.
precertificate-final-certificate-pair — why one certificate order produces two CT log entries; the substrate of the CT-Monitoring dedup problem.
cross-system-correlation-key — the spki_sha256 key that lets the CT alerting service recognise Cloudflare-issued certificates.
reproducible-shared-key-for-async-reconciliation — the pattern CT Monitoring's filtering fix instantiates.