A TLS certificate can be valid under normal chain validation and still deserve public scrutiny. Certificate Transparency (CT) adds that visibility by placing certificates or precertificates in public logs designed for auditing. The security model is more precise than a simple claim that a certificate has been logged: CT separates a log’s signed promise from later evidence that the promised entry actually reached the log’s Merkle tree.
RFC 9162 describes CT version 2.0. A conforming log is an append-only Merkle tree. When it accepts a certificate or precertificate submission, it returns a Signed Certificate Timestamp (SCT). That SCT is a signed commitment associated with the accepted submission and a timestamp. It is not, by itself, a Merkle inclusion proof.
An SCT is a commitment with a deadline
After issuing an SCT, a log is required to incorporate the corresponding entry within its Maximum Merge Delay (MMD). The MMD is a log parameter, so the promise has a bounded time window rather than an indefinite future date.
This distinction matters during verification. An SCT can be checked cryptographically against the corresponding log key and certificate material, but successful SCT validation establishes that the log signed the commitment. It does not establish that a particular later tree contains the entry.
A client or monitor can audit that second property after enough time has passed. If the log cannot provide evidence that the entry was incorporated as promised, the signed SCT becomes evidence tied to the log’s failure to satisfy its commitment.
CT therefore creates two separate questions:
- Did the named log issue a valid SCT for this certificate or precertificate?
- Did the promised entry appear in a later authenticated tree within the required interval?
Treating those checks as identical discards an important part of the protocol’s accountability model.
Inclusion proofs connect an entry to a tree root
A Merkle inclusion proof shows that a specific entry contributes to a particular Merkle tree root. The proof contains the sibling hashes needed to recompute the path from the selected leaf to the root. The verifier combines the entry hash with that path and compares the resulting root with the authenticated tree state.
In CT v2, the relevant tree state is represented by a Signed Tree Head (STH). An STH binds a tree size and root hash to a log signature. An inclusion proof only has security value in relation to the correct authenticated tree state; an arbitrary root supplied without the expected log authentication is not enough.
This gives the verifier a concrete statement: the selected certificate or precertificate entry is included in the tree represented by that STH.
The proof is compact because the verifier does not need every other log entry to check membership. Merkle tree structure reduces the evidence to a logarithmic path of hashes relative to the tree size.
Consistency proofs protect append-only history
Inclusion answers a membership question at one tree state. It does not establish that the log preserved its prior history while growing.
CT uses Merkle consistency proofs for that separate check. Given an older tree and a newer tree, a valid consistency proof shows that the newer tree extends the older one without changing or removing the older entries. A monitor can therefore compare authenticated tree states over time instead of trusting a log’s statement that its history is append-only.
The distinction between inclusion and consistency is operationally important. A log could place an entry in one tree view yet still misbehave by presenting incompatible histories. Inclusion checking and consistency checking cover different failure modes.
RFC 9162 also notes a harder problem: a dishonest log could present inconsistent views to different parties. Comparing observations across independent clients or monitors is relevant to detecting that class of behavior. The core CT data structures make contradictory signed states useful evidence, but a verifier isolated from every other observer cannot automatically detect every split-view strategy.
CT exposes issuance; it does not approve it
A public log records accepted certificate material. The log does not decide that a certificate was legitimately requested by the domain owner, and inclusion does not convert a misissued certificate into an authorized one.
This property is central to CT. Visibility allows monitors to inspect new entries and flag certificates associated with domains they watch. Remediation remains outside the logging mechanism: a domain operator may need to work with a certification authority, certificate consumers, or other PKI participants after suspicious issuance is detected.
Normal certificate validation also remains separate. RFC 9162 explicitly keeps SCT validation distinct from validation of the server certificate and its chain. A valid SCT does not repair an expired certificate, a hostname mismatch, an untrusted chain, or another failure in ordinary certificate validation.
CT adds auditability to the PKI; it is not a replacement for PKI validation.
Delivery and auditing are separate paths
CT information can reach TLS clients through protocol mechanisms associated with the certificate or handshake. The protocol also permits later retrieval of inclusion evidence from a log.
Direct retrieval has a privacy cost. If a TLS client asks a log for an inclusion proof for a certificate it has just encountered, the request can reveal which server the client contacted. RFC 9162 therefore notes the privacy benefit of having the TLS server provide inclusion proofs rather than requiring each client to query a log directly.
That tradeoff illustrates a broader deployment point: cryptographic verifiability does not remove metadata exposure. The source of proof material and the timing of retrieval remain part of the privacy design.
The useful boundary is accountability
Certificate Transparency does not promise that every logged certificate is legitimate, and an SCT alone is not proof of final inclusion. Its strength comes from a chain of independently checkable statements.
The SCT records a signed promise from a log. An inclusion proof ties the promised entry to an authenticated tree. Consistency proofs tie successive tree states into an append-only history. Monitoring makes unexpected issuance visible, while ordinary TLS certificate validation continues to enforce its own rules.
Keeping those roles separate makes CT’s security boundary explicit: the system turns certificate issuance and log behavior into public, cryptographically auditable events without treating transparency as authorization.