Certificate Transparency Logs Explained for Beginners
Certificate Transparency, usually shortened to CT, is one of those pieces of internet infrastructure that quietly runs in the background of every HTTPS connection you make, yet almost nobody outside security circles has heard of it. Understanding CT logs explains both why the web is safer from certain attacks today, and why they have become the single richest free source for finding subdomains.
What a CT log actually is
A Certificate Transparency log is a public, append-only ledger of TLS certificates, built using a cryptographic structure called a Merkle tree. Once a certificate is added, it cannot be secretly removed or altered without breaking the mathematical proof that ties every entry to the ones before it. Multiple independent organizations, including Google, Cloudflare, DigiCert, and Sectigo, run their own CT logs, and a certificate typically needs to be recorded in at least two of them to be trusted by modern browsers.
In practice this means every publicly trusted TLS certificate issued anywhere in the world becomes a permanent, publicly auditable record the moment it is issued, including every hostname listed on it.
Why it exists: the DigiNotar breach
CT was born directly out of a 2011 incident. DigiNotar, a Dutch certificate authority, was compromised by an attacker who issued fraudulent certificates for domains including google.com, without DigiNotar's knowledge. Those fraudulent certificates were used to intercept traffic, most notably against users in Iran, and nobody noticed for weeks because there was no public record of which certificates had actually been issued.
The incident led to DigiNotar's collapse and made clear that the certificate authority system had a structural blind spot: a compromised or malicious CA could issue certificates for any domain, and the legitimate owner would have no way to find out. Google engineers proposed Certificate Transparency shortly after as the fix.
How CAs are required to log certificates
Since 2018, Google Chrome (and subsequently other major browsers) require newly issued publicly trusted certificates to include proof of submission to CT logs, called Signed Certificate Timestamps, or the browser will refuse to trust the certificate and show a warning. This effectively made CT logging mandatory for any certificate that needs to work in a modern browser, rather than merely optional best practice.
The result is that CT logs are, functionally, a complete real-time record of nearly every publicly trusted certificate issued anywhere, which is a remarkable dataset that did not exist in any usable public form before 2013.
The mechanism that makes discovery possible
A single certificate can list many hostnames via Subject Alternative Names, for example example.com, api.example.com, and staging.example.com on one certificate. Every one of those names becomes searchable the moment the certificate is logged.
How anyone can query CT logs
Because CT logs are public by design, anyone can search them without special access. Tools like crt.sh provide a web interface over aggregated log data, letting you search a wildcard pattern like %.example.com and get back every logged certificate, and therefore every hostname, associated with that domain. This is exactly the mechanism Subdomain Finder uses as one of its primary passive sources.
No authentication, no API key, and no special tooling is required. This is also precisely why CT search is considered passive reconnaissance: you are querying a third-party log, not the target's own servers.
A goldmine, and a tradeoff
For defenders, CT logs are how you discover your own organization's forgotten subdomains, shadow IT deployments, and staging environments that should have been decommissioned years ago. For attackers, exactly the same query surfaces exactly the same information. This is the well-known tradeoff of Certificate Transparency: the openness that lets defenders audit their own exposure also lets anyone else see it.
The practical takeaway is not to avoid public certificates, since that would mean showing browser security warnings to every visitor. It is to assume anything you put a public certificate on is discoverable, and to monitor your own CT log activity so you learn about new or unexpected subdomains before someone else does.
Monitor your own CT footprint
Subdomain Finder queries Certificate Transparency logs alongside several other sources, so you can see exactly what an outsider would see about your own domain, in one scan.
Try a scan free →Frequently asked questions
What is a Certificate Transparency log?
It is a public, append-only, cryptographically verifiable record of every TLS certificate a participating certificate authority has issued, designed so that no entry can be secretly altered or removed after the fact.
Why do CT logs matter for finding subdomains?
Because a certificate lists every hostname it covers, searching CT logs for a domain reveals every subdomain that has ever had a public certificate issued for it, even ones the organization forgot existed.
Can I stop my subdomains from appearing in CT logs?
Not while using a publicly trusted certificate. Every major browser requires certificates to be logged, so the only way to avoid CT exposure is to avoid issuing a public certificate for that hostname, which usually means using an internal certificate authority instead.