What Is Certificate Transparency? CT Logs Explained

Certificate Transparency (CT) is a system that requires every publicly trusted TLS certificate to be recorded in public, append-only logs before browsers will accept it. The goal is simple: make it impossible for a certificate authority to issue a certificate for your domain — by mistake, coercion, or compromise — without that certificate becoming visible to you and everyone else watching the logs.

Before CT, a mis-issued certificate could sit undetected for months. A compromised or careless certificate authority (CA) could issue a valid certificate for yourbank.com to someone who isn’t your bank, and unless you happened to notice, an attacker with that certificate could impersonate the site convincingly to any browser, since HTTPS trust is built on the assumption that a valid certificate means a legitimate CA vouched for it.

How the logs work

CT logs are append-only, cryptographically verifiable structures built on a Merkle tree — the same structure used to make blockchains and version-control systems tamper-evident. Each entry is a submitted certificate; once added, an entry cannot be modified or removed without invalidating the tree’s root hash, which is regularly published and independently checked. If a log operator tried to quietly alter or delete an entry, anyone who had recorded the old root hash would detect the mismatch.

Anyone can submit a certificate to a log, and anyone can query a log to see what’s been submitted. Certificate authorities submit every certificate they issue as a condition of it being trusted by major browsers. In return, the log gives back a Signed Certificate Timestamp (SCT) — cryptographic proof that the certificate was logged at a specific time.

Why browsers require SCTs

Modern browsers won’t fully trust a publicly issued TLS certificate unless it carries valid SCTs from a sufficient number of independent, recognized logs. This is enforced in one of three ways:

• Embedded directly in the certificate as an X.509 extension.
• Delivered via a TLS extension during the handshake.
• Stapled alongside an OCSP response.

The effect is that CA mis-issuance without a paper trail is no longer practically possible for certificates trusted by mainstream browsers — a certificate without adequate SCTs simply won’t be accepted, regardless of whether the CA itself is legitimate. This closes a gap in the trust model that predates CT: a CA making a mistake, or being compromised, or being pressured by a government to issue a certificate it shouldn’t, used to be undetectable until damage was already done.

What site owners actually do with it

Because logs are public and searchable, domain owners can monitor them for any certificate issued for their domain — including subdomains they didn’t request. Several free CT-log search tools let you enter a domain and see every logged certificate, issuer, and validity window. Site owners use this to catch:

• Mis-issuance. A CA issues a certificate for your domain to the wrong party, whether through a validation bug or social engineering.
• Forgotten shadow IT. A certificate for a subdomain nobody remembers spinning up, which can indicate an unmanaged or abandoned service still reachable on the internet.
• Early signs of a targeted attack. An unexpected certificate for a domain that closely resembles yours — a component in some phishing setups — though CT alone doesn’t stop a man-in-the-middle attack from happening, it makes the certificate involved easier to spot after the fact.

This is a detection mechanism, not a prevention mechanism — CT doesn’t stop a CA from mis-issuing a certificate in the first place. It ensures that if one is issued, it’s discoverable rather than silent.

Certificate Transparency vs related mechanisms

	Certificate Transparency	HSTS	Certificate pinning
Protects against	Undetected mis-issuance by any trusted CA	Downgrade to plain HTTP	Any CA except the pinned one(s)
Enforcement point	Browser rejects certs without valid SCTs	Browser refuses HTTP for the domain	Browser refuses certs that don’t match the pin
Site owner action needed	Monitor logs (optional but recommended)	Send an HSTS header	Maintain and rotate pins carefully
Failure mode if misused	None — it’s largely automatic	Domain becomes unreachable if misconfigured	Site becomes unreachable if pins expire and rotation fails

CT is complementary to HSTS and to the TLS handshake process described in our guide on how the TLS handshake works — CT governs whether a certificate should have been trusted at all, while HSTS and the handshake govern how a trusted certificate is used in a live connection.

The takeaway

Certificate Transparency turns certificate issuance from a private transaction between a domain owner and a CA into a public, auditable record. Every publicly trusted certificate now carries proof it was logged, browsers reject certificates that lack that proof, and anyone can monitor the logs for their own domains to catch mis-issuance early. It doesn’t prevent a compromised or careless CA from issuing a bad certificate, but it guarantees that certificate can’t stay hidden.