Certificate transparency logs are one of the fastest ways for a security team to find subdomains it didn’t know it had, and attackers know this as well as defenders do. This guide covers how CT logs work as a subdomain discovery source, how to query them, what they miss, and how to turn raw certificate data into an accurate list of DNS records that actually resolve. If you look after a domain with more than a handful of hostnames, a single query will probably surprise you.
Why Certificate Transparency Logs Expose Your Hostnames
Certificate Transparency was standardized in RFC 6962 in 2013 and updated as RFC 9162. The idea is simple. Every publicly trusted certificate gets submitted to append-only public logs, so anyone can audit what certificate authorities issue.
Chrome began requiring CT for all newly issued certificates in April 2018. Apple’s platforms enforce a similar policy. In practice, any certificate from Let’s Encrypt, DigiCert, Sectigo, or Google Trust Services ends up in public logs within seconds of issuance. Each logged certificate lists its hostnames in the Subject Alternative Name field.
The consequence matters for domain security. A developer who requests a certificate for staging-payments.example.com on a Friday afternoon has published that hostname to the world, whether or not the subdomain is ever linked anywhere.
Querying CT Logs for Subdomain Discovery
The fastest starting point is crt.sh, run by Sectigo. A query for %.example.com returns every logged certificate that matches the domain, and adding output=json makes the results easy to parse. For large domains the web interface often times out. An experienced practitioner then switches to crt.sh’s public PostgreSQL endpoint, which handles heavy queries much better.
Censys and Google’s Transparency Report offer alternative views. Open-source tools like subfinder and OWASP Amass pull from CT sources automatically. For live coverage, certstream-style feeds stream new log entries as they appear, so you can flag a new hostname under your domain within minutes rather than at the next quarterly review.
A workable process looks like this:
1. Pull every SAN entry for your apex domain and all known secondary domains from crt.sh or Censys.
2. Normalize the results: lowercase everything, strip leading “*.” prefixes, and deduplicate.
3. Resolve each hostname against your authoritative nameservers and record A, AAAA, and CNAME answers.
4. Classify each result as live, NXDOMAIN, or pointing at a third-party service you need to verify.
5. Diff the list weekly against your previous snapshot and investigate every new entry.
On a mid-sized SaaS domain, step one typically returns 400-2,000 unique names. Usually only 30-50% of them still resolve. Those numbers show both how useful CT data is and how noisy it can be.
A Realistic Scenario: The Campaign Page Nobody Remembered
Consider a typical find. A security engineer runs a CT sweep during an annual review and spots spring-promo.example.com, issued a certificate in 2022 and never renewed. The marketing team that ran the campaign has since reorganized.
The DNS record still exists. It’s a CNAME pointing to a Heroku app that was deleted 18 months ago. That is a textbook dangling DNS entry. Anyone who registers an app with the same name on Heroku could serve content on a subdomain of a trusted brand.
The certificate had expired long ago, so it showed up in no certificate monitoring dashboard. Only the CT history connected the hostname to the organization. Mapping certificate history to live DNS is the core of certificate inventories mapped to active subdomains, and it explains why expired entries deserve as much attention as current ones.
Myth: CT Logs Show Every Subdomain You Have
They don’t. CT logs only contain hostnames that appeared on publicly trusted certificates, and that leaves real gaps.
Wildcard certificates are the biggest blind spot. A certificate for *.example.com reveals nothing about the 60 hostnames sitting behind it. Internal services signed by a private CA, such as Active Directory Certificate Services or HashiCorp Vault PKI, never touch public logs. Neither do hostnames served only over plain HTTP, mail-only records, or TXT-based verification entries.
The opposite assumption is just as wrong. A hostname appearing in CT doesn’t mean it’s live, owned by you, or even created on purpose. CT is one input. Pair it with passive DNS, zone data, and active enumeration, as described in why passive DNS discovery matters for organizational security.
Common Mistakes When Using CT Data
The first mistake is treating CT results as an inventory instead of a lead list. Teams export crt.sh output into a spreadsheet and call it their asset register. Half the entries are dead, and the wildcard-covered hosts are missing completely.
The second is ignoring expired certificates. Teams filter for valid certificates to cut noise, which throws away exactly the forgotten hostnames most likely to have stale DNS pointing at cloud resources that have since been decommissioned.
The third is switching everything to wildcard certificates to “hide” hostnames. It reduces exposure in CT, but a single compromised private key then covers every subdomain. Attackers also still find the names through DNS brute-forcing and passive DNS datasets. That trade-off rarely favors the defender.
Edge Cases and When the Standard Advice Changes
Regulated environments sometimes push back on public certificates for internal systems entirely. Banks and healthcare providers often run private PKI for anything not customer-facing, so CT-based discovery will undercount their footprint by design. For them, internal DNS zone exports matter more.
Small teams with under 10 people and one domain can usually get by with a monthly crt.sh check. Organizations that have acquired other companies should run CT queries against every domain they acquired. Inherited brands are where most surprises turn up.
Certificate lifetimes are also getting shorter. Under CA/Browser Forum Ballot SC-081, maximum validity dropped to 200 days in March 2026 and falls further to 47 days by 2029. More renewals mean more log entries and faster visibility, but also more noise to filter.
FAQ
Can I remove my subdomains from certificate transparency logs?
No. CT logs are append-only by design, and entries can’t be deleted. Your options are to use wildcard certificates or private PKI for future issuance, with the trade-offs described above.
How often should CT logs be checked for new subdomains?
Continuous monitoring through a streaming feed is ideal, because attackers watch the same feeds. At a minimum, run a weekly diff so that a new hostname is reviewed within 7 days of its certificate being issued.
Do CT logs reveal anything besides hostnames?
Yes. They show the issuing CA, issuance dates, and validity periods. Unexpected issuers can point to shadow IT or a mis-issued certificate. A CAA record limits which CAs are allowed to issue certificates for your domain.
Summary
Certificate transparency logs give you a free, public, and surprisingly complete history of hostnames that have used public TLS. Use them as the first step in subdomain discovery, not the last. Resolve every result, chase down the CNAMEs pointing at services you no longer control, and fill the wildcard and private-PKI gaps with other sources. For a broader approach that combines CT with brute-forcing and passive data, see subdomain enumeration techniques.