The problem CT solves
Before Certificate Transparency existed, a certificate authority could issue a certificate for any domain without the domain owner knowing. Browsers had no mechanism to detect this. The only check was whether a CA in the browser's trust store had signed the certificate — and there were hundreds of trusted CAs globally, each with the technical ability to sign for any domain.
The DigiNotar incident in 2011 made the consequences concrete. A Dutch CA was compromised and issued fraudulent wildcard certificates for *.google.com and hundreds of other domains. These certificates were used in active man-in-the-middle attacks against Iranian users. The certificates were valid — signed by a trusted CA — and browsers had no way to detect the fraud until users reported anomalies. DigiNotar was removed from all trust stores and went bankrupt within weeks.
The underlying problem remained: the CA ecosystem gave any trusted CA unilateral power over any domain. Certificate Transparency was designed to make mis-issuance detectable, not to prevent it directly, but to ensure that any fraudulently issued certificate would leave a permanent, public, auditable record.
How CT logs work
A CT log is an append-only, cryptographically verifiable record of certificates. It is structured as a Merkle hash tree: each leaf node contains a certificate (or pre-certificate), and each internal node is a hash of its children. The root hash — called the tree head — is signed by the log operator and published periodically. Because the tree is append-only and each root hash commits to all previous entries, it is mathematically impossible to silently remove or alter a certificate once logged.
When a CA issues a certificate, it can submit either a pre-certificate (a certificate with a special poison extension, submitted before the final cert is signed) or the final certificate itself to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT) as proof of inclusion. The CA embeds SCTs from multiple logs into the final certificate before delivering it to the domain owner.
Multiple independent log operators exist — Google, Cloudflare, DigiCert, and others run logs. Requiring SCTs from multiple logs means there is no single point of failure: even if one log is compromised or goes offline, other logs maintain the record.
SCTs explained
An SCT is a signed promise from a log operator that a certificate has been (or will be within a defined time, called the Maximum Merge Delay or MMD) added to the log. The SCT contains the log's ID, a timestamp, and a cryptographic signature over the submitted data.
This is described as a "promise of logging" model: the SCT proves the log has accepted the certificate, not necessarily that it is already visible in the public tree. Logs commit to merging accepted certificates within their MMD, typically 24 hours. Monitors watching the logs can therefore detect any certificate within a day of issuance.
SCTs can be delivered to browsers via three channels:
- Embedded in the certificate — the CA includes SCTs directly in the TLS certificate as an X.509 extension. No TLS extension or OCSP required; works with any server.
- TLS extension — the server sends SCTs in the
signed_certificate_timestampTLS extension during the handshake. Requires server-side support but does not increase certificate size. - OCSP staple — SCTs are embedded in an OCSP response that the server staples to the TLS handshake. Requires both OCSP stapling and CT-aware CAs.
Embedded SCTs are the most common delivery method for public CAs, including Let's Encrypt, because they require no server configuration and work transparently.
Browser enforcement
Chrome enforces CT for all publicly trusted certificates issued after April 2018. A certificate must carry SCTs from at least two independent logs that are currently trusted by Chrome's CT policy. If a certificate lacks sufficient SCTs, Chrome displays a hard error — the connection is blocked, not just flagged.
The specific requirements depend on certificate lifetime. For certificates with validity of 180 days or less, two SCTs are required. Longer-lived certificates require additional SCTs. Chrome's CT log list is maintained as part of the browser's update mechanism, and logs can be disqualified if they fail to uphold their commitments.
Safari (Apple) implements CT enforcement through its own policy. Apple requires CT for certificates issued after October 2018, with similar two-SCT requirements. Apple also maintains its own trusted log list independently of Google's.
Firefox does not currently enforce CT independently but relies on the operating system or Mozilla's own mechanisms. This means CT enforcement is primarily driven by Chrome and Safari's combined market share.
Let's Encrypt and CT
Let's Encrypt automatically submits all issued certificates to multiple CT logs before delivery. Every LE certificate includes embedded SCTs from at least two logs. This happens transparently — there is nothing to configure and no extra steps required.
LE submits to logs operated by Google (Argon, Xenon), Cloudflare (Nimbus), and others. Because LE uses pre-certificate submission, the SCTs are embedded directly in the certificate. The result is that all LE-issued certificates fully satisfy Chrome's and Safari's CT policies out of the box.
This is one reason CT compliance is often taken for granted in modern deployments: if you are using any major public CA with ACME automation, CT is handled for you. The cases where CT becomes a hands-on concern are older deployments, internal CAs, or certificates issued by smaller CAs that do not submit to logs automatically.
How to check CT compliance
The most direct check is inspecting the certificate itself for embedded SCTs. A TLS inspection tool will report the SCT count and, for each SCT, the log ID and timestamp. Two or more SCTs from logs on the browser trust lists is the passing bar.
For historical issuance monitoring — checking whether any unexpected certificates have been issued for your domain — crt.sh indexes CT log data and allows searching by domain name. Querying %.example.com returns all certificates logged for any subdomain. This is valuable for detecting shadow IT, misconfigured staging environments, or fraudulent certificates.
Regular CT monitoring is a low-cost security control. RSS feeds and automated queries against crt.sh can alert you within hours of unexpected issuance. Several commercial tools offer this as a service, but crt.sh query automation via cron or CI is sufficient for most organizations.
CT and CAA records
CT and CAA records are complementary controls that operate at different points in the issuance lifecycle. CAA records (Certification Authority Authorization) tell CAs which authorities are permitted to issue for a domain — they are checked before issuance and act as a preventive control. CT logs record what was actually issued — they are a detective control, providing an audit trail after the fact.
Neither is sufficient alone. CAA restricts which CAs may issue but relies on CAs honoring the record; a compromised or rogue CA might ignore it. CT cannot prevent mis-issuance but ensures any violation is publicly visible. Together, they form a practical defense: CAA raises the bar for mis-issuance, CT ensures any violation leaves a permanent record that domain owners and auditors can find.
For high-value domains, configure both: a CAA record allowing only your chosen CA, and automated monitoring of CT logs for your domain. The combination makes unauthorized issuance both harder to execute and impossible to hide.