Subdomain Finder

What Certificate Transparency tells us

Every TLS certificate issued by a public Certificate Authority since 2018 is logged to a public, append-only ledger called Certificate Transparency. The logs were created to detect mis-issuance after a series of high-profile incidents (DigiNotar 2011, Comodo 2011, Symantec 2017), and they have an unintended side effect: every internal subdomain you've ever requested a certificate for is now searchable by anyone, forever.

This tool queries crt.sh — Sectigo's free Certificate Transparency aggregator — for every certificate ever issued under the domain you enter. From those certificates, we extract the Subject Alternative Names (SAN) and Common Name fields, deduplicate, and present the unique subdomain list.

What you'll see

• Subdomain name — the canonical hostname found in at least one certificate.
• First seen / Last seen — the earliest and most recent certificate issuance dates we have for that name. "First seen" approximates when the subdomain went live; "Last seen" tells you whether it's still being renewed.
• Cert count — how many distinct certificates have covered the name. High numbers (10+) usually mean it's a long-lived production service. Low numbers mean it's transient or recent.
• Issuer — which CA issued the certificate. Let's Encrypt for most modern setups; DigiCert / Sectigo for legacy enterprise; Cloudflare for sites behind their proxy.
• Wildcard flag — entries like *.example.com tell you a wildcard cert exists, but not which specific subdomains use it. If you only see wildcards in the results, the operator deliberately uses wildcards to keep the subdomain list private.

What this is good for

1. Security review. If you're a security researcher with permission, the subdomain list is the starting map for any external assessment. Subdomains running outdated software (a forgotten Jenkins, a dev environment with default credentials, an admin panel never reached by intended users) are how attackers get in. Companies who run their own bug bounty often publish their CT-derived subdomain lists as a baseline so researchers don't waste time finding what's already known.
2. Engineering discovery. When you join a new team or take over a domain, this is the fastest way to see what services exist. Internal docs are usually outdated; CT logs are not.
3. Marketing / SEO audit. Forgotten subdomains running orphaned content can hurt your overall SEO if they're indexed and broken. The list helps you find what to redirect.
4. Competitive research. If a competitor uses subdomains for product environments (app., api., admin., staging., v2.), you can infer roughly what stack they have. Don't probe the URLs without permission.
5. Compliance / SOC2 evidence. Many auditors ask for an exhaustive list of internet-facing assets. CT-derived subdomain enumeration is a standard input.

Important caveats

• Not all subdomains have certificates. Internal-only services using self-signed certs, plain HTTP services, or services on private CAs won't show up. CT logs only cover public CAs.
• Wildcards hide the real list. If a domain only ever issues wildcard certs (*.example.com), the actual subdomains using that wildcard are not enumerable from CT alone. Combine with other techniques (DNS brute force, passive DNS, search engine recon) for a fuller picture.
• Names appear even if the service is gone. A subdomain that issued a cert in 2020 and was decommissioned in 2021 still appears in our list. Use the Last Seen column to filter to currently-renewed services.
• Test certificates leave traces. Internal "staging" or "test" subdomains that someone briefly experimented with are visible. Embarrassing if you don't expect it; relevant for security reviews.
• This is not active reconnaissance. We are reading public logs, not scanning your servers. The information was already public the moment a cert was issued.

How to interpret the output

A few patterns to look for:

• www. only → small operator, single web property.
• www., api., app. → typical SaaS structure (web, API, app).
• Many *.tenant. entries → multi-tenant SaaS, each customer gets a subdomain.
• Random hex strings (abc123def.) → ephemeral environments, preview deploys (Vercel, Netlify, Heroku review apps).
• internal., vpn., jira., jenkins. → publicly resolvable internal tools. These are the most common security findings.
• old., legacy., v1. → deprecated systems still online. Frequent source of CVEs because no one is patching them.

Combining with DNS resolution

A subdomain in the CT log doesn't guarantee the subdomain still resolves. To check liveness:

1. Export the list (CSV button at the top of results).
2. Run each through DNS resolution. Our Domain to IP Lookup handles single domains; for bulk, scripting dig or using a tool like dnsx is faster.
3. For HTTP service detection, use httpx or similar.
4. Triage by status: 200 (live), 301/302 (redirected), 404 (orphaned), connection refused (decommissioned).

Defensive: how to make CT enumeration harder

You can't opt out of Certificate Transparency for public CA certs — major browsers require CT inclusion to trust the cert. But you can reduce the leak:

• Use wildcard certs for sensitive subdomains. A wildcard *.internal.example.com protects the specific names from being enumerated, although the parent internal.example.com still appears.
• Use a private CA for internal-only services. Tools like step-ca or AWS Private CA issue trusted certs that don't go to public CT logs.
• Don't put credentials in subdomain names. "customer-acme-corp-prod" leaks both the customer and the environment.
• Audit before merging. Code review for new subdomain registrations, especially in CI/CD pipelines that auto-create preview environments.

Rate limits and reliability

crt.sh is a free public service maintained by Sectigo. It is occasionally slow or rate-limited under heavy load. Our backend caches results at the edge for 5 minutes to reduce upstream pressure. If you get a 502 error, try again in a minute or query crt.sh directly via curl 'https://crt.sh/?q=%25.example.com&output=json'. For high-volume programmatic enumeration, consider running your own CT log monitor with Axeman or paying for a commercial CT API.