Cybersecurity glossary
What is a Subject Alternative Name (SAN)?
Learn what certificate SANs are, why browsers match hostnames against SAN DNS names, how multi-domain certificates work, and which issuance mistakes cause outages.
Definition
Subject Alternative Name (SAN) is an X.509 certificate extension that lists additional identities—most commonly DNS names or IP addresses—that the certificate is authorized to represent, and it is the primary hostname identity field for modern public TLS validation.
Why SANs are the real hostname list
Operators still talk about “the CN on the cert,” but browsers decide trust for HTTPS names by reading Subject Alternative Name (SAN) entries. Incomplete SAN inventories cause production outages even when the chain is perfect.
Common SAN types
DNS names
FQDNs and permitted wildcards clients match against SNI/host headers.
IP addresses
Literal endpoint identity when clients dial by IP.
URIs and emails
Used in client certs, document signing, and specialized PKI profiles.
Multi-name coverage
One leaf can authorize several hostnames to simplify inventory.
How SAN matching works in TLS
Client dials a reference identifier
For example api.example.com via DNS and SNI.
Server presents a leaf certificate
The certificate includes a SAN extension.
Client extracts SAN identities
DNS and IP names are parsed from the extension.
Match against the reference
Exact DNS match or applicable wildcard rules are applied.
Fail closed on mismatch
No match means identity validation fails despite a trusted chain.
SAN planning mistakes vs fixes
Most SAN incidents are inventory problems, not crypto breaks.
| Mistake | Symptom | Fix |
|---|---|---|
| Forgot www or apex | Browser errors on one hostname | Include both names in SANs |
| Staging hostname omitted | Preview URLs break HTTPS | Automate SAN lists from inventory |
| CN-only issuance | Modern clients reject identity | Require SANs in issuance policy |
| Stale names left forever | Larger attack/monitoring noise | Remove unused names on renew |
Operational checklist
- Treat SAN DNS as the authoritative public hostname list.
- Generate CSRs from a maintained inventory of client-facing names.
- Include every load-balancer alias users actually type or are redirected to.
- Prefer automation (ACME) so renewals cannot silently drop names.
- Monitor certificate transparency and scanners for unexpected SANs.
- Use private PKI for internal names instead of public multi-SAN sprawl.
- Document wildcard scope boundaries to avoid over-broad trust.
- Test hostname validation in CI with the exact names production serves.
More SANs are not always better
Giant SAN lists increase blast radius if a private key leaks and complicate least-privilege hosting. Split certificates by environment or application when operationally feasible, especially across unrelated domains.
The practical takeaway
Subject Alternative Name (SAN) is the hostname identity surface modern TLS clients trust. Build SAN lists from real client destinations, automate issuance, and stop treating CN as sufficient.
Related security terms
Common Name (CN)
The legacy subject field that SANs effectively supersede for public HTTPS identity.
X.509 Certificate
The certificate format that carries the SAN extension.
Wildcard Certificate
Certificates that use SAN patterns such as *.example.com.
Certificate Signing Request (CSR)
Where applicants request the SAN list before issuance.
HTTPS
HTTPS clients verify the connected hostname against SANs.
Frequently asked questions
What is a SAN in simple terms?
A SAN is a list of names on a certificate saying which websites or IPs it covers, such as example.com and www.example.com.
Why are SANs required for public HTTPS?
Modern browsers validate hostnames using the SAN extension. A CN alone is not a reliable public TLS identity.
Can one certificate have many SANs?
Yes. Multi-domain certificates list multiple DNS names. Limits vary by CA and operational practice.
Do wildcards belong in SANs?
Yes. A DNS SAN can be *.example.com to cover one label under that domain, subject to CA policy.
What about IP addresses?
Use SAN iPAddress entries for literal IP identity. Putting an IP only in CN is outdated practice.
What causes a SAN mismatch error?
The hostname or IP you connected to is not present in the certificate’s SAN list (or not covered by an allowed wildcard).
Should internal names appear on public certificates?
Public CAs generally will not issue internal-only names. Use private PKI for internal hostnames.
References
Explore authoritative guidance and frameworks related to subject alternative name (san).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.