What actually stops a Certificate Transparency log from quietly rewriting its own history?

What actually stops a Certificate Transparency log from quietly rewriting its own history?

The answer is the consistency proof, and it is the cryptographic spine of CT's trust model (RFC 6962).

A CT log is an append-only Merkle tree: each certificate is a leaf, and every node hashes its two children. The root hash is a fixed-size fingerprint of the entire tree. The log periodically signs its current root as a Signed Tree Head (STH).

Two proofs make the structure trustworthy. An inclusion proof shows a specific certificate is in the tree under a given STH, by supplying the sibling hashes along the path to the root — logarithmic in the tree size. A consistency proof is the stronger guarantee: given an older STH and a newer one, it provides the minimal set of hashes proving the new tree is a strict superset of the old, append-only, with nothing removed or altered.

Why this matters: a malicious or compromised log could otherwise present one view to a domain owner (cert absent) and another to a victim (cert valid) — a split-view attack. Auditors and monitors gossip STHs and demand consistency proofs between them, making any divergent history detectable.

The property is detection, again, not prevention — but a log caught failing a consistency proof loses trust and is removed from browser lists.

Further reading: RFC 6962 §2.1.2, RFC 9162; the "gossip" drafts on STH sharing.

Bottom line: append-only is enforced socially via consistency proofs between signed tree heads — a log cannot rewrite history without producing detectable, non-repudiable evidence.