Certificate Transparency logs and how sites return an error without one

Certificate Transparency is a public record of every TLS certificate issued by the certificate authorities the ecosystem trusts. Its purpose is to make mis-issued certificates visible, so a certificate no one noticed is far less likely. To that end, modern browsers require publicly trusted certificates to be accompanied by proof that they appear in a CT log, and they will refuse to load a site whose certificate cannot prove it.

What CT is

CT is a set of tamper-evident, append-only logs run by independent operators. When a CA issues a certificate, it submits the certificate to these logs, and each log returns a signed certificate timestamp, or SCT, as proof of inclusion. A certificate carries SCTs with it, either embedded by the CA or delivered separately during the TLS handshake.

An SCT is the core piece: a signed promise from a log that the certificate was accepted on a certain date. Because the logs are public and the timestamps are signed, a certificate issued for a domain the owner did not ask for can be found and audited, which is what makes Certificate Transparency a deterrent against bad issuance.

How SCTs are judged

Chrome maintains a list of logs it considers qualified and evaluates every SCT against it. For a certificate to validate, it must present a minimum number of SCTs from distinct, recognised logs. The exact requirement is:

• Certificates valid for 180 days or less need SCTs from at least two distinct CT logs.
• Certificates valid longer than 180 days need SCTs from at least three distinct CT logs.
• In both cases at least two of the SCTs must come from distinct log operators, so two logs run by the same operator do not count as two independent proofs.

Chrome enforces CT only while its installed CT log list is fresh, typically within a few weeks. If a browser cannot refresh that list for long enough, enforcement pauses rather than failing closed, to avoid breaking every site during a component failure.

When a site fails

This enforcement applies only to certificates that chain to a publicly trusted root. If a site uses a private or locally installed CA, CT does not apply. For ordinary public certificates, missing the SCT requirement produces a full-page certificate warning and the connection is blocked with the code ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

That error almost always means the issuing CA did not obtain valid SCTs for the certificate, which is a CA or provisioning problem rather than something the site owner can fix locally. The practical remedy is to obtain a new certificate from a CA that embeds the required SCTs. Let's Encrypt and the other major public CAs log automatically, which is why this error is rare in practice. See free Let's Encrypt certificate and the SSL certificate types guide for how renewal and issuance avoid this surface.

The takeaway for site owners: prefer a CA that logs by default, renew before expiry, and treat a CT error as a certificate-integrity issue to fix at the source rather than in the browser.