Certificate Transparency logs: what they catch, and how to monitor your own domain
Certificate Transparency (CT) is an open framework, defined in RFC 6962, that requires publicly trusted certificate authorities to publish every TLS certificate they issue into append-only, publicly auditable logs — so a domain owner, a browser, or anyone else can later discover that a certificate for their domain was issued, even one they never requested themselves.
By AdminKit team, Netbase JSC · Updated October 24, 2026
Why certificates needed a public paper trail
Before Certificate Transparency, the trust placed in a TLS certificate rested entirely on the issuing CA getting its validation right, with no independent way to check its work after the fact. If a CA issued a certificate for a domain it shouldn’t have — through a validation bug, a compromised account, or an insider mistake — the only way anyone found out was if the rogue certificate was actually observed in the wild, usually too late to matter. RFC 6962 was written directly in response to real mis-issuance incidents in the CA ecosystem, and it fixes the visibility gap rather than the issuance process itself: every certificate a participating CA issues must be submitted to one or more public, append-only logs before browsers will trust it.
How a CT log actually works
A CT log is built as a Merkle tree, a cryptographic structure that lets anyone verify two things efficiently: that a given certificate really is included in the log, and that the log hasn’t silently rewritten its own history to remove or alter an earlier entry. When a CA submits a certificate, the log returns a Signed Certificate Timestamp (SCT) — a promise, cryptographically signed by the log operator, that the certificate will appear in the log within a defined window. Browsers that enforce CT policy (see certificate.transparency.dev for the current list of participating logs and policy details) check for a valid SCT, embedded in the certificate itself or delivered alongside it, before trusting the connection without a warning.
What CT logging does not do
It’s easy to overstate CT’s guarantees, so it’s worth being precise about the boundary. CT does not validate domain ownership, does not replace a CA’s own issuance checks, and does not block a mis-issued certificate from being logged — it only guarantees that the mis-issuance becomes visible after the fact. A certificate can be perfectly well-formed, correctly logged, and still have been issued to the wrong party if the underlying domain-validation step was tricked or compromised; CT turns that into a discoverable event instead of an invisible one, nothing more. It’s a detection and accountability layer, not a prevention mechanism.
Monitoring your own domain
Because every publicly trusted certificate for your domain ends up logged, you can treat the logs as a free early-warning system. crt.sh offers a public search interface over the logs — querying your domain surfaces every certificate issued for it, including subdomains, the issuing CA, and the issuance date, with no account or tooling required. Run this check periodically, and treat an unexpected CA name or an unfamiliar subdomain certificate as the signal worth investigating; a certificate from your own CA for a subdomain you actually operate is normal and expected. Pairing this with a CAA record (see our guide on what CAA records do) narrows which CAs can legitimately issue for your domain in the first place, which makes an unexpected entry in the logs even easier to spot as out of policy.
Related checks
CT logs tell you a certificate was issued; they don’t tell you whether the certificate currently in use is healthy. Once AdminKit’s SSL/TLS check ships, it will complement CT monitoring by checking the live certificate chain, expiry and protocol configuration a domain is actually serving today — see our guide on reading a TLS/SSL certificate check result for what that check covers, and HSTS and HSTS preload explained for the companion protection that stops a browser from ever accepting a plain HTTP connection to your domain in the first place.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What is Certificate Transparency in plain terms?
It's a public record-keeping system for TLS certificates. RFC 6962 defines a log format where any publicly trusted certificate authority (CA) submits every certificate it issues to one or more independently operated CT logs before the certificate is considered valid by modern browsers. Each log is append-only and cryptographically verifiable — entries cannot be quietly removed or edited after the fact — so the existence of a certificate becomes a matter of public record rather than something only the CA and the certificate's holder know about.
What problem does CT actually solve?
It solves detection, not prevention: before CT, a CA could mis-issue a certificate for a domain it doesn't control — by mistake, through a compromised validation process, or under coercion — and the domain's real owner would have no way to find out unless they happened to encounter the rogue certificate directly. CT doesn't stop a CA from mis-issuing; it guarantees that if a publicly trusted CA does issue a certificate for your domain, a record of it becomes publicly visible in the logs, which is what makes monitoring possible in the first place.
Does a certificate appearing in CT logs mean it's safe or legitimate?
No. CT logging is neutral — it doesn't judge whether an issuance was authorized, it just makes the issuance visible and auditable. A correctly issued certificate for your own domain and a mis-issued certificate obtained by someone else both end up in the logs; the logs don't flag which is which. The security benefit only materializes when someone — you, a monitoring service, or a browser vendor's own detection tooling — actually reviews what's logged for a given domain.
How do I monitor CT logs for my own domain?
Search a public CT log aggregator such as crt.sh, which lets you query by domain name and see every logged certificate, including the issuing CA and issuance date, without needing to run your own log client. Review the list periodically for certificates you didn't request — an unfamiliar CA name or an unexpected subdomain is the signal worth investigating, not the mere presence of an entry.
Is CT logging mandatory for every certificate?
In practice, yes for any certificate that needs to be trusted by Chrome, Safari, or other major browsers that enforce a CT policy: certificates issued since the policies took effect must carry proof of logging (an embedded Signed Certificate Timestamp) or the browser will not treat the connection as valid. See Chrome's and the wider Certificate Transparency project's own policy documentation, linked below, for the current enforcement details, since specifics (log count requirements, grace periods) have evolved since RFC 6962 was first published.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.