Subdomain Finder

Discover the subdomains of any domain from public Certificate Transparency logs. Enter a domain and this tool searches crt.sh for every TLS certificate ever issued under it, then extracts and de-duplicates the hostnames into a clean list you can copy. It is passive: it reads the public certificate record and never scans or probes the target, so it is fast, quiet and finds subdomains that brute-force wordlists miss.

How to use the Subdomain Finder

Enter a domain and press Find subdomains. The tool reports:

• A de-duplicated list of every subdomain seen in a logged certificate, sorted, with a Copy all button.
• Any wildcard certificates (like *.example.com) listed separately.
• A short summary: how many certificates were seen and the date range they span.

Because crt.sh has to scan a large public dataset, a query can take a few seconds, and very large domains may be capped. The results are the hostnames that appeared on publicly-logged certificates, which in practice is almost every internet-facing subdomain that uses HTTPS.

How Certificate Transparency reveals subdomains

Certificate Transparency (CT) is a public, append-only logging system that every trusted Certificate Authority must submit issued certificates to. Browsers refuse certificates that are not logged, so in practice every publicly-trusted TLS certificate ends up in the CT logs, where anyone can search it. crt.sh, run by Sectigo, is the most popular search front-end for those logs.

This turns CT into an excellent passive subdomain discovery source. When someone issues a certificate for api.example.com or staging.internal.example.com, the hostname is recorded in the log forever. By searching the logs for %.example.com and collecting the unique names, you reconstruct a large part of a domain's footprint without sending a single packet to the target. That is why it is quiet and safe: you are reading a public ledger, not scanning anyone.

It is honest to know the limits, because no single technique finds everything:

• Only certificated names appear. A subdomain that never received its own public certificate will not show up. Names hidden behind a *.example.com wildcard certificate are also invisible individually.
• Internal-only names are usually absent. Hosts that only use a private CA or no TLS at all are not in the public logs.
• History includes dead names. CT records are permanent, so the list can include subdomains that were retired years ago and no longer resolve.

For complete coverage, CT search is normally combined with DNS-based techniques (wordlist brute force, zone transfers where allowed) and with checking which names still resolve. But as a first, no-touch sweep, CT logs give the broadest results for the least effort, which is why it is the standard opening move for asset inventory and reconnaissance.

Common use cases

• Attack-surface mapping — enumerate an organisation's internet-facing hosts before a penetration test or audit.
• Asset inventory — find forgotten or shadow-IT subdomains that should be decommissioned or secured.
• Bug-bounty recon — quickly scope the subdomains in a program without touching the target.
• Takeover hunting — list subdomains to check for dangling DNS that points at unclaimed cloud resources.
• Monitoring growth — track which new subdomains a domain has stood up over time.

What CT-based discovery does and does not show

Reading the results well means knowing what the data can and cannot tell you:

• A listed subdomain may be dead. CT is a permanent history. Before treating a name as live, confirm it resolves — run it through the A Record Lookup or DNS Lookup.
• Wildcards hide the children. A *.example.com certificate covers any single-label subdomain, so individual names under it may never appear. The wildcard itself is listed so you know to look deeper with DNS methods.
• Absence is not proof. A subdomain missing from CT may simply use a private certificate or none at all. CT search complements, rather than replaces, active DNS enumeration.
• The certificate view tells you more. If you want issuers, validity dates and per-certificate detail rather than just the hostname list, use the Certificate Transparency Search, which runs on the same data.

A practical workflow: take the list here, confirm which names still resolve, then check the live ones for HTTP responses, dangling CNAMEs and certificate health. The CNAME Lookup and SSL Certificate Checker are useful next steps.