SAN (Subject Alternative Name)

Why it exists

A single certificate often needs to cover more than one name: example.com, www.example.com, api.example.com. The subject’s common name (CN) can only hold one value. The SAN extension is a list, so one certificate can cover many hostnames.

Browsers and other TLS clients now match the hostname you asked for against the SAN list only. Chrome stopped falling back to the common name in 2017, and a certificate that carries its hostname only in the CN is rejected. The modern service-identity rules in RFC 9525 say the same.

Entry types

Type	Example
DNS name	example.com, *.example.com
IP address	192.0.2.10, 2001:db8::1
Email address	[email protected]
URI	https://example.com/

For websites, DNS names and IP addresses are what matter. Email and URI entries appear mostly in S/MIME and service-to-service certificates.

Wildcards

A wildcard covers exactly one label, and only in the leftmost position.

• *.example.com matches www.example.com and api.example.com.
• It does not match example.com itself.
• It does not match a.b.example.com, which has two labels before the domain.

Adding a SAN to a certificate you create

With OpenSSL, for a self-signed development certificate:

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem \
  -days 30 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Common pitfalls

• Forgetting the bare domain. A certificate for www.example.com does not cover example.com. List both.
• Expecting a wildcard to match too much. See the rules above.
• Internationalized names. DNS SAN entries hold the ASCII punycode form (xn--...), not the Unicode text.
• Internal names and private IPs. Public CAs do not issue certificates for names like server.local or addresses like 10.0.0.5. Use a private CA for those.
• Reading only the subject. When debugging a name-mismatch error, look at the SAN list first. That is where the answer is.