CT Log (Certificate Transparency log)

A CT log is a server, run by an independent operator, that accepts certificates and precertificates from CAs, appends them to a Merkle tree and returns a Signed Certificate Timestamp. The log periodically publishes a signed tree head (STH). Anyone can request inclusion proofs, showing that a certificate is in the tree, and consistency proofs, showing that the tree only grew and was never rewritten. Each log commits to incorporating new entries within a maximum merge delay.

Why it matters

Browsers do not accept SCTs from just any log: each log must be admitted to browser CT policies, such as Chrome's and Apple's, and is monitored for misbehavior. A log that shows different views to different parties, or misses its merge deadline, can be disqualified, after which its SCTs stop counting. Logs are usually temporally sharded, with a separate log for certificates expiring in each period, so old shards can be frozen and retired. Operators have included Google, Cloudflare, DigiCert, Sectigo and Let's Encrypt, which together make Certificate Transparency independent of any single company.

Example

Logs following RFC 6962 expose a simple HTTP API. Fetch the current tree head:

curl -s https://ct.example.com/ct/v1/get-sth

The JSON reply contains tree_size, timestamp, sha256_root_hash and tree_head_signature. Monitors poll this endpoint and download new entries with get-entries. Some newer logs, such as those running Let's Encrypt's Sunlight software, instead serve the tree as static tiles.

Common misconceptions

• There is one central CT log. There are many independent logs, and browsers require SCTs from several distinct operators.
• A CT log validates certificates. A log only checks that a submission chains to a root it accepts; judging whether issuance was correct is the job of monitors.
• Being logged means a certificate is legitimate. Logging is required for browser acceptance but says nothing about whether the CA should have issued it.