Subdomain Finder
Find subdomains from certificates that were actually issued.
Certificate Transparency changed subdomain discovery. Since browsers began requiring it, every certificate a public CA issues is written to an append-only public log — including the hostnames it covers. That makes the logs an authoritative, permanent, freely searchable record of names that genuinely existed, with none of the false positives a brute-force wordlist produces.
The security consequence cuts both ways, and it is worth being clear about. Requesting a certificate for secret-staging.example.com publishes that hostname to the world within minutes. Anyone can read it. This is a deliberate trade — the logs are what make certificate misissuance detectable — but it means a hostname is not a secret, and anything relying on an unguessable name for protection is already exposed.
For defenders this is the fastest honest inventory of an attack surface. Run it against your own domain and the results are frequently uncomfortable: a forgotten staging environment, a legacy application nobody owns, a subdomain pointing at a decommissioned cloud resource. Those are exactly what an attacker enumerates first, from the same public source.
What this tool does
Evidence, not guesses
Every name came from a real certificate in a public log, so there are no false positives from a wordlist.
Finds what you forgot
Staging, admin and legacy hosts get certificates too, and the log remembers them long after the team has.
Dated
Each name shows when it was last seen in a new certificate, which separates live infrastructure from history.
Passive
Nothing is sent to the target domain. This reads a public log, so the domain owner sees no traffic from it.
Frequently asked questions
How does this find subdomains?
It queries Certificate Transparency logs, which record every certificate issued by a publicly trusted CA along with the hostnames it covers. Any subdomain that has ever had a certificate appears there permanently, whether or not it still resolves.
Why do some results not resolve?
Because CT logs are historical. A name that had a certificate two years ago is in the log forever, even if the host was decommissioned. That history is useful — a name that no longer resolves but still has a DNS record pointing at a deleted cloud resource is exactly the subdomain-takeover setup.
Will this find every subdomain?
No. It only finds names that appear in publicly logged certificates. Internal hosts, names using a private CA, and anything covered only by a wildcard certificate are invisible to it. A wildcard tells you nothing about which hosts exist beneath it, and this tool does not invent them.
Is running this against a domain I do not own legal?
It reads a public log and sends nothing to the domain. Certificate Transparency is published deliberately, and querying it is no different from reading any public record. Acting on what you find against someone else's infrastructure is a separate question entirely.
How do I keep a subdomain out of the logs?
You cannot, for a publicly trusted certificate — logging is mandatory and browsers reject certificates without it. The options are a wildcard certificate, which hides the specific hostname, or an internal CA for hosts that never face the public internet. The right conclusion is that hostnames are not secrets.
Why is the tool sometimes slow or unavailable?
It reads crt.sh, a free public service run by Sectigo that aggregates the logs. It is generously provided and frequently under load. A timeout means the log service did not answer, which is reported as itself rather than as "no subdomains found".
Monitor it, don't just check it
One-off checks catch what is broken today. CertNotify watches your certificates, domains, DNS and code continuously and tells you before something breaks.