What Is Certificate Transparency?

At a glance

Certificate Transparency helps domain owners and researchers discover misissued or unexpected certificates. Logging improves visibility but does not automatically prevent all incorrect issuance.

Making certificate issuance auditable

Certificate Transparency places public certificates in public, append-only, auditable logs. A log returns a Signed Certificate Timestamp, or SCT, promising inclusion. Browsers use these signals under their policies, while owners and researchers monitor unexpected issuance.

CT does not publish private keys or guarantee that every certificate is correct. It makes issuance, previously visible mainly to the CA and applicant, observable and easier to investigate. Revocation, remediation and account protection still require follow-up.

How an append-only log is verified

• A Merkle Tree organizes certificate entries. A signed tree head commits to an entry count and root hash at a particular time.
• An inclusion proof demonstrates that a certificate is in the tree. A consistency proof shows that a newer tree extends an earlier one rather than silently rewriting history.
• SCTs can be embedded in certificates, TLS extensions or OCSP responses. Browser policies check log eligibility, timing and the required number of SCTs.
• Monitors download and inspect logs while auditors verify proofs. Independent observers improve the chances of detecting dishonest logs or split views.

Using CT to discover domain assets

Certificate-name searches can reveal subdomains, third-party certificates and brand-lookalike names. Historical logs also contain retired hosts, unsuccessful deployments and names that never served public traffic. Not every entry is a current asset.

Organizations can monitor primary domains and similar names, then investigate unexpected certificates against applicants, DNS control and suppliers. Responses may include revocation, account repairs, tighter validation permissions and investigation of a wider compromise.

Practical use and interpretation

A log entry establishes that a certificate or precertificate was submitted, with clues about issuance, CA and SAN names. It alone cannot prove that a host exists now, the certificate was deployed or the domain belongs to a particular business.

Valid SCTs on a current certificate provide evidence of CT submission. Missing SCT data may reflect incomplete connection evidence, client-policy differences or private trust; the state can remain unknown. Distinguish precertificates, final certificates and current deployments instead of describing a historical entry as a continuously online service.

Points to consider

CT supports certificate monitoring and asset discovery. A logged hostname does not prove that the host is currently online or managed by the same team.

Frequently asked questions

Do CT logs expose private keys?

No. They record public certificate or precertificate data. Private keys should remain under their holder's control.

Does a logged subdomain have to be accessible now?

No. Historical and precertificate entries may refer to retired, never-launched or internally named hosts.

Does CT automatically revoke an unexpected certificate?

No. It provides visibility. Owners must contact the CA, investigate validation and carry out revocation and remediation.