SCT (Signed Certificate Timestamp)
Definition
An SCT is a CT log's signed promise to add a certificate to its public log, which browsers require as proof that the certificate was submitted for logging.
An SCT (Signed Certificate Timestamp) is a small data structure returned by a CT log when a CA submits a certificate or precertificate. It contains the log ID, a timestamp and the log's signature, and promises that the entry will appear in the log within the maximum merge delay. Clients verify the signature using the log's public key from their CT policy list. SCTs reach clients in three ways: embedded in the certificate (by far the most common), in a TLS extension during the handshake, or inside a stapled OCSP response.
Why it matters
Chrome and Apple reject publicly trusted certificates without enough valid SCTs; Chrome requires CT for certificates issued after 2018-04-30 and Apple for those issued after 2018-10-15. Their policies demand SCTs from multiple distinct log operators, with the required number depending on certificate lifetime. SCT timestamps are also used in distrust decisions: Chrome 131+ distrusts Entrust TLS certificates whose earliest SCT is after 2024-11-11, a cut-off a CA cannot backdate because the log, not the CA, signed the time.
Example
openssl x509 -in cert.pem -noout -text | grep -A12 "CT Precertificate SCTs"
Each entry lists Version, Log ID, Timestamp and Signature. A certificate from a public CA typically carries two or three entries from different logs.
Common misconceptions
- An SCT proves the certificate is in the log. It is a signed promise; an inclusion proof from the log confirms it later.
- Site operators have to configure SCTs. With embedded SCTs the CA handles everything; only the TLS-extension method needs server support.
- An SCT vouches for the certificate's validity. Logs do not check whether issuance was proper; they only record it.