Subject Alternative Name (SAN)

The SAN extension, defined in RFC 5280, holds a list of typed names: dNSName for hostnames, iPAddress for IPv4 or IPv6 addresses, rfc822Name for email addresses (used by S/MIME) and uniformResourceIdentifier for URIs. TLS clients compare the hostname they connected to with the DNS or IP entries; the Common Name is no longer consulted. A single certificate may carry many SAN entries, which is what makes multi-domain certificates possible.

Why it matters

If a name is not in the SAN, the certificate is not valid for it. Wildcard entries such as *.example.com match exactly one label: www.example.com, but neither example.com nor a.b.example.com. That is why most certificates list example.com together with www.example.com or *.example.com. Every SAN entry must be validated by the CA, and the list is fixed at issuance; adding a name means getting a new certificate.

Example

Create a key and a CSR with two SAN entries:

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

The -addext option requires OpenSSL 1.1.1 or later.

Common misconceptions

• *.example.com also covers example.com. It does not; the bare domain needs its own entry.
• SAN entries can be added to an existing certificate. Any change would break the CA's signature; you must request a new certificate.
• A "SAN certificate" is a special product. Nearly every TLS certificate has a SAN extension; the marketing term just means one with several names.