Overview
The Subject Alternative Name (SAN) field lists the domains a certificate covers — often many, revealing subdomains. This lesson covers SANs in OSINT.
Learning objectives
- Define the SAN field.
- Explain how SANs reveal multiple domains/subdomains.
- Connect SANs to subdomain discovery.
Core concept
The Subject Alternative Name (SAN) field of a TLS certificate lists all the domain names the certificate is valid for — frequently multiple names, since one certificate often secures several domains/subdomains. This makes SANs a rich OSINT source: examining a certificate's SAN field reveals the set of names the organization secured together — often surfacing subdomains (and related domains) that other discovery methods miss. SANs are a key reason certificates are powerful for subdomain discovery.
How it works
The practitioner examines a certificate's SAN field to extract all the domain names it covers. Because organizations often use multi-domain (SAN) certificates securing several subdomains or related domains at once, one certificate's SAN list can reveal a cluster of names — including internal-sounding or non-obvious subdomains not found via DNS guessing. These names, gathered from public certificates (live or via CT logs), expand the known domain footprint. As always, discovered names are verified (do they resolve/are they live?) before treating them as active assets, and combined with other domain intelligence. SAN analysis is a high-yield subdomain-discovery technique.
Practical example
Examining a certificate's SAN field, the practitioner finds it covers not just the main domain but several subdomains — including one with an internal-sounding name not found through DNS enumeration. This SAN list revealed a cluster of the organization's names in one place. The practitioner adds these to the domain footprint, then verifies which resolve/are live before treating them as active assets. The SAN field surfaced subdomains other methods missed — the high-yield value of SAN analysis.
Cybersecurity relevance
The SAN field is a high-yield OSINT source for subdomain/related-domain discovery: multi-domain certificates list several names, often revealing subdomains DNS enumeration misses (connecting to the ethical-hacking and bug-bounty certificate/subdomain lessons). For defenders, it underscores that a certificate's SAN list publicly discloses all the names it secures — so naming and certificate practices can inadvertently reveal internal or staging subdomains (footprint exposure). SAN-derived names are public (via the certificate/CT logs), verified before use, and combined with DNS/WHOIS. Analyzing SANs is one of the most productive certificate-based discovery techniques.
Common mistakes
- Only reading the main subject, ignoring the SAN field's fuller list of names.
- Treating SAN-listed names as active without verifying they resolve/are live.
- Overlooking that SANs publicly disclose all covered names (defender exposure).
Key takeaways
- The SAN field lists all domain names a certificate is valid for — often multiple, since one certificate frequently secures several subdomains/related domains.
- Examining SANs reveals clusters of an organization's names, often surfacing subdomains DNS discovery misses — a high-yield discovery technique.
- SAN-derived names are public (via certificates/CT), verified before use, and combined with other domain data; SANs publicly disclose all covered names (defender exposure).
Check your understanding
- What does the SAN field list, and why does it often reveal subdomains?
- Why should SAN-discovered names be verified before treating them as active assets?