Dr.Who

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

info
Open standalone →

querying 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

  1. enter a bare domain — public fqdn only. apex domain, not a subdomain.
  2. 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.
  3. 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.
  4. 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

example 1 — large SaaS platforms with ACME automation produce many certs. the cap of 100 subdomains in the free view reflects the scale.
input
github.com
output
100+ subdomains discovered (cap hit), certCount > 500, wildcards include *.github.com
example 2 — smaller domains often reveal the whole hostname set in one query — staging and internal names included.
input
small-startup.io
output
subdomains: [api.small-startup.io, staging.small-startup.io, app.small-startup.io], certCount: 12

Common 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.

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.

References

  1. RFC 6962 — Certificate Transparency
  2. crt.sh — CT log search
  3. certificate.transparency.dev — the CT project
ad slot · tool-ct-log-lookup