// Subdomain Finder · Certificate Transparency

Find a domain's subdomains.

Enter a domain and get the subdomains that have appeared in public TLS certificates — collected from Certificate Transparency logs. Passive: no port scanning, no DNS brute-force, nothing sent to the target.

Please enter a valid domain name (e.g. example.com).
[ 01 ] — How it works

Subdomains from CT logs.

Certificate Transparency
Every publicly-trusted TLS certificate is logged to public, append-only CT logs. Those certificates name the hostnames they cover — which is where the subdomains come from.
Passive & free
We query crt.sh server-side and dedupe the results. No scanning of the target, no API key — just the certificate record.
Honest scope
This finds subdomains seen in CT logs — the large majority of internet-facing hosts. It won't find internal-only names, hosts behind wildcard certs, or subdomains that never had a public certificate.

Looking for the full certificate history (issuers, validity, expiry) rather than just the subdomain list? Use the Certificate Transparency log search. For DNS records of a specific host, try the DNS lookup.

Why subdomains are findable at all

There is no way to ask DNS for a list of a domain's subdomains. The protocol has no such query, and zone transfers have been locked down almost everywhere for decades. Historically the only options were guessing from a wordlist or scanning, both of which are noisy and touch the target directly.

Certificate Transparency changed that as a side effect. After a series of misissued certificates in the early 2010s, browsers began requiring that every publicly trusted TLS certificate be recorded in a public, append-only log before it would be accepted. The logs exist so anyone can audit what certificate authorities issue. Because a certificate names the hostnames it covers, those logs are also a permanent public record of hostnames that have ever been given a certificate.

So the subdomains are not discovered by probing. They are read out of a public ledger the domain's own certificates were published to, which is why this lookup is silent from the target's point of view.

What this is useful for

  • Knowing your own attack surface. Most organisations run more hostnames than anyone has written down. A staging environment, an old marketing microsite, a forgotten admin panel: all of them got a certificate at some point, and all of them are in the logs whether or not anyone remembers deploying them.
  • Finding what is no longer maintained. A hostname whose certificate stopped renewing years ago is a strong hint of something abandoned but possibly still running.
  • Spotting infrastructure you did not authorise. Certificates issued for names on your domain that nobody on your team requested are worth investigating.
  • Understanding a vendor before you rely on it. The naming patterns in a company's certificates say a good deal about how their infrastructure is arranged.

Reading the results

Each row gives a hostname and a first-seen date, which is the earliest certificate issuance recorded for that name. Wildcard entries are normalised by dropping the *. prefix, so a certificate covering *.api.example.com is recorded as api.example.com. A wildcard issued on the apex itself, *.example.com, is left out, because it names no subdomain: it tells you a certificate exists without revealing a single host behind it.

An old first-seen date on a hostname you do not recognise is usually the most interesting row on the page. It means the name has existed for a while, which makes it more likely to be running software nobody has looked at recently. Names like dev, staging, test, vpn, jenkins or git deserve a check that they are meant to be reachable from the public internet at all.

Appearing in the list does not mean a host is live. Take anything interesting to the DNS lookup to see whether it still resolves, and to the SSL checker to see what it is presenting today.

Common questions

Is this legal, and will the target notice?

Certificate Transparency logs are public by design, and reading them is the activity they were built for. No traffic reaches the domain you look up, so there is nothing for it to log or notice.

Why are some subdomains missing?

Only hostnames that have appeared in a publicly trusted certificate are in the logs. Internal names on a private CA, hosts covered solely by a wildcard certificate, and anything that has never had HTTPS will not show up.

Why did the lookup time out?

The search runs against crt.sh, which is a free public service and slow under load. A timeout is that service being busy. Nothing was sent to the domain you entered, so retrying is safe.

Do you cap the results?

Yes. Very large domains are truncated, and the page says so when it happens. Content delivery networks and hosting providers can hold hundreds of thousands of certificate entries, which is more than a single page should try to render.

Limitations and honest caveats

  • This is a certificate history, not a live inventory. A name in the logs may have been decommissioned years ago, and the logs never forget.
  • Wildcard certificates hide detail. An organisation using *.example.com everywhere reveals almost nothing here, which is one reason wildcards remain popular.
  • One log search is not every log. crt.sh aggregates broadly but is not a guarantee of completeness.
  • Absence proves nothing. A quiet result means no public certificates were found, not that the domain has no subdomains.

Corrections welcome — see our editorial policy.