A publicly trusted certificate can be syntactically valid, correctly signed, and still be unexpected. A certificate authority might issue one for the wrong subject, an account might be compromised, or an authorization process might fail. Certificate Transparency (CT) adds public observability to certificate issuance so that such certificates do not have to remain invisible to the affected domain operator.
RFC 9162 specifies Certificate Transparency Version 2.0. Its central mechanism is an append-only public log backed by a Merkle tree. Certificate authorities and other submitters can send certificates or precertificates to a log, and monitors can inspect logged entries for certificates relevant to domains they watch.
CT does not decide whether an issuance was authorized. It makes issuance visible and supplies cryptographic structures that support auditing of log behavior.
An SCT is a promise from a log
When a CT log accepts a valid certificate or precertificate submission, it returns a Signed Certificate Timestamp (SCT). The SCT is signed by the log and commits the log to incorporate the corresponding entry into its Merkle tree within the log’s Maximum Merge Delay (MMD).
That distinction matters. An SCT is not itself proof that the entry is already present in a particular tree state. It is a signed commitment that the accepted submission will be incorporated within the stated bound.
A simplified sequence is:
certificate / precertificate
|
v
CT log
|
+----> SCT
|
v
append-only Merkle treeA client can verify an SCT using the relevant log parameters. Monitors and auditors can later check whether the promised entry appears in the log.
Merkle trees make log history auditable
A CT log is organized as a binary Merkle tree. Leaf hashes commit to individual log entries, while internal hashes combine child nodes until a single root hash commits to the tree state.
This structure supports two distinct proofs.
An inclusion proof demonstrates that a specific leaf belongs to a tree represented by a particular root hash. The verifier combines the leaf hash with the supplied path nodes and checks whether the computed root equals the expected root.
A consistency proof links an older tree state to a newer one. It allows a verifier to check that the earlier tree is a prefix of the later tree rather than a history that has been rewritten.
The proofs are compact relative to downloading every entry solely to verify one inclusion or one transition between tree states.
Signed Tree Heads commit to a log state
A CT log periodically signs information describing its current Merkle tree. In RFC 9162 this Signed Tree Head (STH) includes the log identity, tree size, root hash, timestamp, and the log signature over the tree-head data.
The tree size and root hash identify a particular state of the append-only structure. A later STH can be checked against an earlier state with a consistency proof.
This does not make a log incapable of misbehavior. A dishonest log could attempt to present inconsistent views to different parties. RFC 9162 explicitly treats split views as a concern. Comparing observed tree states and auditing consistency are therefore separate from merely verifying a single valid log signature.
Monitoring targets unexpected issuance
The public log is useful because domain operators and independent monitors can search for certificate entries associated with names they care about. An unexpected certificate can then trigger investigation and existing remediation processes, such as working with the issuing CA on revocation.
The log does not label a certificate as legitimate or malicious. It records accepted submissions and exposes them for inspection. Authorization decisions remain outside the CT log.
This boundary keeps CT focused on transparency rather than policy enforcement. Visibility can reveal an issuance that deserves attention, but the surrounding PKI processes determine what action follows.
Inclusion and consistency answer different questions
It is easy to treat all Merkle proofs as interchangeable, but their security statements differ.
An inclusion proof answers whether a particular entry is committed by a given tree root. A consistency proof answers whether a newer tree extends an older tree without changing the older prefix.
Neither proof, by itself, establishes that a certificate should have been issued. Likewise, an SCT only establishes a signed commitment from the log under the protocol rules; it does not certify the authorization behind the certificate.
Keeping these statements separate avoids assigning CT guarantees that belong to certificate validation, CA policy, or domain-control checks.
Transparency complements certificate validation
Normal certificate validation and CT address different failure surfaces. Path validation checks properties such as signatures, trust anchors, names, and validity constraints. CT provides a public record and audit mechanisms around issuance.
That combination is useful because a certificate can pass ordinary cryptographic validation while still being operationally unexpected. CT gives affected parties a place to observe the issuance and cryptographic tools for checking the log’s append-only history.
The result is not prevention of every bad issuance. It is a verifiable publication layer that makes public-certificate activity easier to monitor and makes a log’s historical commitments subject to cryptographic audit.