Overview
TLS certificate data is a surprisingly useful passive-recon source, revealing domains and subdomains an organization uses. This lesson covers certificates as reconnaissance information.
Learning objectives
- Explain what certificate data reveals.
- Describe certificate transparency as a recon source.
- Connect certificate recon to subdomain discovery.
Core concept
Public TLS certificates contain the domain names they are issued for, including in the Subject Alternative Name (SAN) field, which often lists multiple domains and subdomains. Moreover, Certificate Transparency (CT) logs are public records of issued certificates, searchable to find certificates (and thus domain/subdomain names) associated with an organization. Because certificates and CT logs are public, mining them is passive and can surface subdomains that other methods miss.
How it works
When an organization obtains certificates for its services, those certificates (and their listed names) are recorded in public CT logs. A tester can search these public logs for the target's domain to discover certificates issued for it and the names they cover — frequently revealing subdomains, including ones not easily found otherwise. These names expand the asset inventory. Because it queries public certificate/CT data rather than the target's systems, it is passive and undetectable, and it complements DNS-based subdomain discovery.
Practical example
For an authorized target, the tester searches public Certificate Transparency logs for the organization's domain and finds certificates covering several subdomains — some already known, others new (e.g. an internal-sounding or staging subdomain that was certificate-protected). These newly discovered names are added to the in-scope inventory for consideration, expanding the known attack surface. All of this came from public certificate records, without touching the target.
Cybersecurity relevance
Certificate/CT-log mining is a standard passive technique for subdomain and asset discovery, often revealing hosts that DNS enumeration alone misses — valuable for both testers and attackers. For defenders, it highlights that obtaining a certificate makes the covered names publicly visible via CT logs, so naming conventions and certificate practices can inadvertently disclose infrastructure (e.g. staging. or internal. subdomains). Testers use it within scope to enrich the inventory; defenders account for CT-log visibility when planning their footprint.
Common mistakes
- Overlooking certificate/CT data as a subdomain-discovery source.
- Assuming certificate-listed names are private — CT logs make them public.
- Treating out-of-scope names found via certificates as testable rather than noting them excluded.
Key takeaways
- Public TLS certificates (esp. SAN fields) and Certificate Transparency logs reveal domains/subdomains an organization uses.
- Mining CT logs is passive and can surface subdomains other methods miss, expanding the asset inventory.
- It complements DNS subdomain discovery; defenders should note that certificates make covered names publicly visible via CT logs.
Check your understanding
- How can Certificate Transparency logs reveal an organization's subdomains?
- Why should defenders be aware that obtaining a certificate makes the covered names public?