ct-log lookup
discover subdomains via Certificate Transparency logs — queries crt.sh (with certspotter fallback) and returns unique hostnames seen in issued certificates. part of the drwho.me domain dossier.
Overview
Certificate Transparency (RFC 6962) is a public audit mechanism that requires CAs to log every issued certificate to append-only, cryptographically verifiable logs. the goal was CA accountability — anyone can audit what certs a CA has issued. the useful side-effect for security and recon work: because every certificate's Subject Alternative Names (SANs) are logged, you can query CT logs to discover every hostname a CA has ever issued a cert for under a given domain. this reveals subdomains the owner has never explicitly advertised: dev, staging, internal, and deprecated hostnames that may have lax security controls. this tool queries `crt.sh` (the industry-standard CT log aggregator operated by Sectigo) with a wildcard match (`%.domain`), deduplicates the SAN entries across all returned certs, and splits them into apex/plain subdomains and wildcard entries (e.g. `*.api.example.com`). results are capped at 100 subdomains in the free view — the Country Risk Pack exposes full enumeration. the `certCount` field shows how many distinct certificates were found, giving a sense of certificate hygiene (many short-lived certs = ACME automation; a few multi-year certs = manual management).
How to use
- enter a bare domain — public fqdn only. apex domain, not a subdomain.
- read the subdomain list — each entry is a hostname seen in at least one CT log entry. presence in CT doesn't mean the subdomain is currently live — certs expire and DNS can be removed. use dns-records-lookup on interesting entries to confirm they still resolve.
- note wildcard entries — a `*.example.com` cert means ANY subdomain under that level could be in use. wildcards tell you about the TLS strategy (a single wildcard cert vs per-hostname certs) but don't enumerate specific names.
- use certCount as a cert-hygiene signal — a high cert count with short validity periods suggests ACME automation (healthy). a small number of long-lived certs suggests manual management — check expiry dates with tls-certificate-checker.
Examples
input
github.comoutput
100+ subdomains discovered (cap hit), certCount > 500, wildcards include *.github.cominput
small-startup.iooutput
subdomains: [api.small-startup.io, staging.small-startup.io, app.small-startup.io], certCount: 12Common mistakes
CT records outlive the certificate— once a cert is logged, the CT entry is permanent — crt.sh will return it forever. a subdomain that resolved 3 years ago and is now decommissioned will still appear in results. always cross-reference with a live DNS check before acting on a finding.wildcards don't enumerate the actual hostnames— a `*.example.com` wildcard cert tells you one cert covers all subdomains at that level, but not which ones are actually in use. to enumerate under a wildcard you need additional signals (DNS brute-force, crawl, other CT entries with specific names).crt.sh can be slow or rate-limited— crt.sh is a free community service. under high load it returns slowly or times out. this tool falls back to certspotter's API when crt.sh is unavailable. the `source` field in the result indicates which backend was used.the 100-subdomain cap is on unique names, not certs— certCount reflects all certs found; the subdomain list is deduplicated and capped at 100 names. a domain with 1000 certs may have far fewer than 100 unique hostnames (if most certs cover the same set of SANs), or many more (if every cert has unique names). the pack removes the 100-name cap.
FAQ
what are Certificate Transparency logs for?
RFC 6962's goal was CA accountability — browsers require that certs be logged so anyone can audit a CA's issuance history and spot misissued certs. the reconnaissance use case (finding subdomains) emerged because the logs are public and contain every SAN ever issued.
why does crt.sh return subdomains I've never created?
wildcards. if your CA issued `*.example.com`, crt.sh may store literal `*.example.com` as a SAN. separately, some CAs or verification providers issue short-lived validation certs under your domain (e.g. for DV challenge tokens) — these show up in CT as subdomains like `_acme-challenge.example.com`.
is CT log lookup the same as a DNS subdomain brute-force?
no. CT lookup finds names that have had a certificate issued; brute-force guesses names from a wordlist and tests DNS resolution. CT is faster, quieter, and more authoritative for TLS-served hostnames. brute-force finds names that never got a cert (internal services, non-HTTPS hostnames). they're complementary.
how do I get the full subdomain list beyond 100?
the Country Risk Pack (or full dossier access) removes the 100-name cap and surfaces the complete deduplicated list. for manual exploration, crt.sh's search UI at https://crt.sh/?q=%25.yourdomain.com shows the raw cert log.
can ai agents call this?
yes — dossier_ct_log on the mcp endpoint at drwho.me/mcp/mcp.
Related tools
whois lookup— registrar, creation date, expiry date, and registry statuses for a domain.dns records lookup— resolve A, AAAA, NS, SOA, CAA, and TXT records for a domain in one go.tls certificate checker— inspect a domain's TLS certificate: subject, issuer, validity, SANs, fingerprint.