<b>What actually is a Signed Certificate Timestamp, and what does it prove?</b>

<b>What actually is a Signed Certificate Timestamp, and what does it prove?</b>

Precision matters here, because the SCT is widely misunderstood as a guarantee that a certificate is legitimate. It is not.

Certificate Transparency (CT, RFC 6962) was built after the 2011 DigiNotar and Comodo breaches, where rogue certificates were issued without the domain owner knowing. CT's premise: make every issued certificate publicly auditable by appending it to an append-only Merkle tree log.

A Signed Certificate Timestamp is the log's signed promise: "I received this certificate and will incorporate it into my tree within the Maximum Merge Delay (typically 24 hours)." Browsers like Chrome require a certificate to carry SCTs from multiple independent logs, delivered via an X.509 extension, the TLS extension, or stapled OCSP.

What the SCT proves is narrow but powerful: that the certificate is publicly visible. It does not prove the certificate was authorized — a misissued cert still gets an SCT. The value is detection, not prevention. Domain owners running CT monitors (or services like crt.sh) can spot certificates they never requested and act.

The Merkle structure is what makes the log trustworthy: anyone can verify an inclusion proof and a consistency proof showing the log never retroactively edited history.

Further reading: RFC 6962, RFC 9162 (CT 2.0); Chrome CT policy.

Bottom line: an SCT proves publication, not authorization — CT shifts the model from preventing misissuance to making it impossible to hide.