Certificate Transparency logs create a public, auditable record of certificates issued for websites. They help domain owners, browsers and researchers spot certificates that should not exist. They do not stop a certificate authority from making a mistake, and they do not replace browser validation, revocation or a domain owner’s monitoring.

The current standard is RFC 9162, published in December 2021 as Certificate Transparency version 2.0. It replaces the original RFC 6962 design. The practical model is straightforward: certificate authorities submit certificates or precertificates to public logs, the logs promise to include them, and monitors check what appears.

The short answer

A Certificate Transparency (CT) log is an append-only list backed by a Merkle tree. Each new batch of entries changes the tree’s signed root. Anyone can request cryptographic proofs that a certificate is present and that the log grew without rewriting earlier history.

The first useful artifact is usually a Signed Certificate Timestamp, or SCT. A log issues the SCT after accepting a certificate or precertificate. It is a signed promise to add that entry within the log’s Maximum Merge Delay. CT documentation says this delay is commonly 24 hours, while RFC 9162 treats the value as a fixed parameter declared by each log.

An SCT is not an approval of the certificate. It says a named log accepted the entry and promised to make it auditable.

Why CT exists

A browser can verify that a certificate chains to a trusted root, matches the requested hostname and is within its validity period. Those checks can still succeed for a certificate that a trusted authority issued to the wrong party.

CT addresses that visibility gap. A domain owner can monitor log entries for its names and investigate an unexpected certificate. Browsers can also require proof that a certificate was logged before accepting it.

Chrome’s CT policy applies to publicly trusted TLS server certificates. When Chrome enforces the policy, a certificate that does not provide enough valid SCT evidence fails CT compliance and certificate validation fails. The exact requirements depend on factors such as certificate lifetime, log state and the delivery method for SCTs.

That browser policy is an enforcement layer built on top of the public logs. The log itself remains a record, not a gate that blocks issuance.

How a certificate enters a log

A certificate authority commonly submits a precertificate before issuing the final certificate. The precertificate contains the names and other information that will appear in the final certificate, plus an extension marking it for CT.

The log checks the submitted chain against its accepted roots and, if it accepts the entry, returns an SCT. That SCT can then reach a browser in several ways, including being embedded in the final certificate or delivered during the TLS connection.

The log must merge the accepted entry into its tree before the Maximum Merge Delay expires. Once merged, a monitor can request an inclusion proof that links the entry to a signed tree root.

The Certificate Transparency project describes the participating roles as loggers, monitors and auditors. A single system can perform more than one role, but the distinction is useful:

  • Loggers accept entries and publish the append-only trees.
  • Monitors watch logs for names or patterns that matter to them.
  • Auditors check proofs and compare signed tree states for consistency.

What the cryptographic proofs establish

An inclusion proof shows that one entry belongs to a particular Merkle tree represented by a signed root. A verifier does not need to download the entire log to check that proof.

A consistency proof shows that a newer tree extends an older one without changing the older entries. That is the append-only property in a form that clients can verify.

These proofs are precise but limited. They can show that a log included an entry and maintained a consistent history for the tree states being compared. They do not show that the certificate authority properly validated the applicant, that the certificate belongs to the right organization, or that every observer was shown the same tree.

RFC 9162 explicitly treats a log as a trusted third party and discusses the risk of a split view, where different clients receive inconsistent histories. Comparing signed tree heads between independent monitors helps expose that behavior.

What a domain owner can learn

Monitoring a domain’s names can reveal:

  • a new certificate issued by an expected provider;
  • a certificate created during an infrastructure migration;
  • an unexpected wildcard certificate;
  • a certificate for a forgotten subdomain;
  • a certificate issued by an authority the organization did not intend to use.

An unexpected entry deserves investigation, but it is not automatic proof of compromise. A hosting provider, content delivery network or another authorized service may have requested the certificate. The check is whether the name, issuer and timing match an approved change.

CT data is public by design. Certificate names can therefore reveal hostnames that an operator would rather not advertise. Domain owners should avoid putting confidential internal names in publicly trusted certificates and use appropriate internal trust arrangements for private services.

What CT does not solve

CT does not revoke a certificate. If a certificate is wrongly issued, the certificate authority and site operator still need to follow the relevant revocation and remediation process.

CT also does not prove that the server using a certificate is safe, that its private key has not leaked, or that the website’s software is free of vulnerabilities. It records certificate issuance, not application security.

It does not prevent phishing with a legitimately issued certificate for an attacker-controlled lookalike domain. The log may accurately record that certificate while the domain itself remains deceptive.

Finally, CT does not encrypt DNS queries or web traffic. Those protections sit elsewhere in the connection. For the name-resolution side, see our guide to DNS over HTTPS and DNS over TLS. For software supply-chain controls, how a dependency becomes a security risk covers a different trust boundary.

A practical monitoring workflow

Start with the domain names and wildcard patterns the organization actually owns. Monitor new CT entries for those names, then compare each alert with an inventory of approved certificate authorities and infrastructure providers.

For an unfamiliar entry, check the exact subject alternative names, issuer, validity period and log timestamp. Confirm whether a deployment, managed service or renewal explains it. Escalate mismatches through the certificate authority’s problem-reporting channel and the organization’s incident process.

Keep the monitoring rule broad enough to catch subdomains, but do not treat every new certificate as an incident. The useful output is a reviewed exception with an owner and evidence, not an inbox full of untriaged alerts.