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 domainposture.com domain dossier.
ct-log
infoquerying CT logs…
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 domainposture.com/mcp/mcp.
How do I find subdomains via certificate transparency logs?
every publicly trusted certificate is logged to CT and certs name their hostnames, including SANs, so searching CT by your domain reveals subdomains that ever had a certificate. search a CT aggregator such as crt.sh for your domain. it is fast passive recon and a good attack-surface check, pair it with monitoring for names you do not recognize.
what are certificate transparency logs?
certificate transparency logs are public, append-only, cryptographically verifiable records of every tls certificate a certificate authority issues, defined by rfc 6962. the original goal was accountability: because all issued certs are logged, anyone can audit a ca and spot certificates that were mis-issued for a domain they do not control. browsers now require certs to be logged to be trusted.
can i discover a domain's subdomains from ct logs?
yes, and it is one of the most useful side-effects of ct. every certificate lists its hostnames in the subject and subject-alternative-name fields, all of which are logged, so querying ct for your domain surfaces subdomains that ever had a cert issued, including forgotten dev, staging, and internal names. note that ct entries are permanent, so a name may appear long after it stopped resolving, confirm with a live dns check.
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.