Overview
TLS certificates and Certificate Transparency logs are a powerful source for discovering subdomains, often revealing ones other methods miss. This lesson covers certificates in subdomain enumeration.
Learning objectives
- Explain how certificates reveal subdomains.
- Describe Certificate Transparency as a source.
- Connect certificate data to comprehensive enumeration.
Core concept
Public TLS certificates list the domain names they cover — including in the Subject Alternative Name (SAN) field, which often names multiple subdomains — and Certificate Transparency (CT) logs are public, searchable records of issued certificates. Because obtaining a certificate for a subdomain records that name in public CT logs, searching CT logs for an organization's domain reveals subdomains that were certificate-protected — frequently surfacing names (including internal-sounding or staging ones) that DNS guessing or wordlists miss. It is a largely-passive, high-yield enumeration source.
How it works
The researcher searches public CT logs for the in-scope domain to find certificates issued for it and the names they cover. Each covered name is a candidate subdomain — often revealing assets not easily found otherwise (a certificate for internal.example.com or staging.example.com discloses those names). Discovered candidates are then validated (do they resolve / are they live and in-scope) before hunting. Because it queries public certificate/CT data rather than the target, it is passive and undetectable, and it complements DNS enumeration by surfacing names that were certificate-protected but not otherwise obvious.
Practical example
Searching CT logs for example.com, the researcher finds certificates covering api, staging, and an internal-sounding admin-internal subdomain — the last not found via DNS wordlists. These certificate-revealed names are strong candidates; the researcher validates that they resolve and are in-scope, then adds the live, in-scope ones to the target set. Certificate/CT-log data surfaced subdomains other methods missed, expanding the authorized attack surface — a common high-yield outcome of this technique.
Cybersecurity relevance
Certificate/CT-log mining is a high-value, passive subdomain-discovery technique that frequently reveals assets DNS enumeration alone misses — valuable in bug bounty and mirroring attacker recon (tied to the ethical-hacking passive-recon certificate lesson). For defenders, it highlights that obtaining a certificate makes the covered names publicly visible via CT logs, so certificate and naming practices can inadvertently disclose infrastructure (e.g. staging./internal. names). Combined with DNS and passive sources, certificate mining helps build a comprehensive, in-scope subdomain picture — after validation.
Common mistakes
- Overlooking CT logs, missing subdomains other methods don't reveal.
- Assuming certificate-covered names are private — CT logs make them public.
- Not validating certificate-discovered names (resolve? live? in-scope?) before hunting.
Key takeaways
- Public TLS certificates (esp. SAN fields) and Certificate Transparency logs reveal subdomains an organization uses, often ones DNS methods miss.
- CT-log mining is passive, undetectable, and high-yield, complementing DNS enumeration; validate discovered names (resolve/live/in-scope) before hunting.
- It highlights that certificates make covered names publicly visible (a defender consideration) and helps build a comprehensive, in-scope subdomain picture.
Check your understanding
- How do Certificate Transparency logs help discover subdomains that DNS enumeration might miss?
- Why should certificate-discovered subdomain names still be validated before testing?