What is a subject alternative name?
The subject alternative name (SAN) is an extension in an X.509 certificate that lists the identities the certificate covers. For a TLS server certificate those are DNS names and sometimes IP addresses; other certificates can carry email addresses, URIs or the user principal names used for smart card logon. When a browser connects to a site, it checks that the hostname it asked for appears in this list. If it doesn't, the connection fails with a name mismatch error even when everything else about the certificate is valid.
SAN replaced the common name
Early certificates identified a server through the common name (CN) field in the subject, which holds only one name. The SAN extension, defined in RFC 5280, holds as many names as needed and keeps each type of identity separate. Clients moved over to it: Chrome stopped accepting the common name for hostname matching in 2017, current browsers generally match only against the SAN list, and public CAs must place every name in the SAN extension. A CN may still appear, but only as a copy of one SAN entry, and a public certificate without a SAN list fails in modern browsers.
What a SAN list looks like
A request can list several names of different types in one line of OpenSSL configuration:
subjectAltName = DNS:portal.example.com, DNS:example.com, DNS:*.apps.example.com, IP:192.0.2.10
The resulting certificate covers one specific host, the bare domain, any single-label name under apps.example.com and one IP address. To see what a certificate really contains, openssl x509 -noout -ext subjectAltName -in server.crt prints just this extension. Internal CAs commonly add IP entries for appliances reached by address and UPN entries for smart card certificates. Public CAs issue only for names whose control they can verify, so internal-only names such as files.corp.local need an internal CA.
SAN, multi-domain and wildcard certificates
A certificate sold as a SAN or multi-domain certificate, often called a unified communications certificate (UCC) when used with Microsoft Exchange, is simply one whose SAN list holds several unrelated names, such as example.com, example.net and shop.example.org. A wildcard certificate is one whose SAN list includes an entry such as *.example.com, covering one label at one level. The two combine freely and share their trade-offs: every listed name uses the same private key, any change means reissuing the certificate, and anyone can read the list. That last point matters because public certificates are recorded in Certificate Transparency logs, so every hostname in a SAN list, including staging hosts and unreleased product names, becomes searchable and is regularly mined by attackers during reconnaissance.
Troubleshooting SAN problems
- The bare domain fails but www works: the list includes www.example.com but not example.com.
- A name works but the IP address fails: users or scripts connect to an address that has no IP entry.
- Errors start after a new hostname goes live: the certificate wasn't reissued with the new entry.
Chrome reports each of these as NET::ERR_CERT_COMMON_NAME_INVALID, an error name left over from the days of CN matching. The fix is a certificate whose SAN list includes the exact name clients use.
Subject alternative name on the CompTIA Security+ exam
The SAN extension is taught with the certificate types in SY0-801 objective 1.3, the cryptographic solutions objective, which include wildcard, self-signed and third-party certificates, and SAN questions appear alongside them. Wording such as "one certificate for example.com, example.net and shop.example.org" points to a SAN or multi-domain certificate, while "every subdomain of one domain, including ones added later" points to a wildcard. "The site works at www but shows a name mismatch at the bare domain" points to a missing SAN entry. Distractors include the common name, which browsers no longer use for matching, self-signed certificates, which change who trusts a certificate rather than which names it covers, and certificate revocation.