Skip to content

SYSTEM Cited by 1 source

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.

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.

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

Last updated · 200 distilled / 1,178 read