Certificate Transparency (CT)

Certificate Transparency (CT), defined in RFC 6962 and revised as CT v2 in RFC 9162, requires CAs to submit certificates to public CT logs built as Merkle trees, which can be appended to but not rewritten. Each log returns a Signed Certificate Timestamp, a promise to include the entry, which is embedded in the certificate or delivered during the handshake. Monitors watch the logs continuously, and anyone can search them.

Why it matters

Before CT, a CA could issue a certificate for your domain and nobody would know unless it was used in an attack. Now browsers refuse certificates that lack valid SCTs: Chrome requires CT for certificates issued after 2018-04-30, and Apple for those issued after 2018-10-15. That makes misissuance visible, gives root programs evidence when they decide whether to keep trusting a CA, and lets domain owners detect certificates they did not request.

Example

Check that a certificate carries embedded SCTs:

openssl x509 -in cert.pem -noout -text | grep -A3 "CT Precertificate SCTs"

To list every certificate ever logged for example.com and its subdomains, query a CT search tool. Researchers and attackers use the same technique to enumerate hostnames.

Common misconceptions

• CT prevents misissuance. It only makes issuance public and detectable; prevention relies on CAA, validation rules and audits.
• Internal hostnames stay private if the certificate is only used internally. Every publicly trusted certificate is logged, so the names in its SAN become public. Use a wildcard certificate or a private CA for names you do not want disclosed.
• Only CAs need to care about CT. Domain owners benefit most, by monitoring logs for certificates they did not expect.