How to find every subdomain of any domain (CT log method)
Certificate Transparency logs reveal subdomains that ever got a TLS cert. Here's how to query them and why this is the most reliable subdomain enumeration method.
Need to know every subdomain a company has? Forget brute-forcing wordlists. The fastest reliable method is querying Certificate Transparency logs - every TLS certificate ever issued is publicly logged, and certificates name their hosts. So every subdomain that ever got a cert is discoverable.
Why CT logs work
Since 2018, Chrome (and now every other major browser) requires that all publicly-trusted TLS certificates be logged in append-only Certificate Transparency logs. CAs submit each cert; logs publish them; researchers and tools index them.
The result: a global database of every (domain, certificate, issued-at) tuple. Searching for %.example.com returns every cert ever issued for any subdomain of example.com - and therefore every subdomain anyone ever bothered to put behind HTTPS.
How to query it
The simplest interface is crt.sh. Direct URL:
https://crt.sh/?q=%25.example.com&output=json&exclude=expiredReturns a JSON array of certificate entries. Each entry has name_value (the SAN list, one host per line) and not_before (issuance date). Deduplicate, filter wildcards, sort.
Or paste any domain into our CT Log Subdomain Finder - it does this for you.
What it catches that wordlists miss
- Internal subdomains with non-obvious names:
jenkins-eu-canary-2.example.com,billing-api-staging.example.com - Hosts that aren't in DNS anymore - old certs are still in the logs even if the host is decommissioned
- Forgotten dev/staging hosts that operations forgot to take offline
What it misses
CT logs only see hosts with publicly-trusted certificates. They miss:
- Hosts on private CAs (internal infrastructure)
- Hosts using self-signed certs (unusual outside dev)
- HTTP-only hosts (rare in 2026)
- Wildcard-covered hosts where individual hostnames were never explicitly included
For a complete picture combine CT + DNS brute-force + passive DNS (e.g., SecurityTrails, RiskIQ).
Practical use cases
Security audits
Find shadow IT before attackers do. Every forgotten dev environment with credentials in env vars is a breach waiting to happen. CT enumeration is one of the first steps a red team runs.
Asset inventory
"What does my company actually have on the internet?" - corporate IT teams ask this constantly. CT enumeration gives a baseline that's hard to argue with: certs were issued at these hosts, here are the dates.
Competitive intelligence
A new app-eu.competitor.com appearing in CT logs is a strong signal of an EU launch. New enterprise.competitor.com = enterprise tier coming. Watch CT logs to see infrastructure decisions before press releases.
Phishing investigation
When a phish targets your brand, CT logs reveal whether the attacker registered cousin domains: example-login.com, secure-example.com, etc. Take them down faster.
Don't be the source
If you don't want a host enumerated this way: don't put a publicly-trusted cert on it. Use a private CA for internal services. Or use name-redacted certs (some CAs support precertificates with hidden hostnames, though browsers may not honor them).
The best assumption: anything you HTTPS-protect publicly is permanently logged. Use our tool to see what's already logged about your own domain.