What is a Subject Alternative Name (SAN)?

A Subject Alternative Name (SAN) is an X.509 certificate extension listing every host name, IP address, or other identity a certificate is valid for, beyond the single Common Name field. Modern TLS clients and browsers validate a certificate’s identity against its SAN entries, not the Common Name, making SAN effectively mandatory.

Key takeaways

• SAN lists every host name and IP address a certificate secures.
• TLS clients validate identity against SAN entries, not Common Name.
• RFC 5280 defines SAN as a standard X.509v3 certificate extension.
• A single certificate can carry many SAN entries of different types.
• Versa VMS certificates require a SAN entry for every FQDN or IP used.

On this page: Why it matters · How it works · Types · SAN & Versa · FAQ

Why is SAN important?

For decades, TLS clients matched a certificate’s identity against a single field: the Common Name (CN). That worked when a server used one host name, but modern infrastructure rarely does – load-balancing across several names, a domain plus its subdomains, or a device reachable by multiple IP addresses. SAN solved this by letting one certificate declare every identity it is valid for.

The shift also matters for security. Browsers and TLS libraries stopped trusting the Common Name for identity matching years ago – Chrome deprecated it in 2017, and the CA/Browser Forum’s Baseline Requirements now mandate SAN for any publicly trusted certificate. A certificate without a matching SAN entry fails validation outright, regardless of its Common Name. Issuing or troubleshooting TLS certificates today means thinking in SAN, not CN.

What is a SAN?

The Subject Alternative Name is a certificate extension defined in RFC 5280, the standard governing X.509v3 public-key certificates. It is a list attached to the certificate, and each entry has a type: a DNS name (the most common), an IP address, an email address, or a URI, among others used less often. A single certificate can carry many entries – commonly a primary domain, several subdomains, and one or more IP addresses.

When a TLS client connects, it checks the host name or IP it dialed against every entry in the SAN list; a match on any entry is sufficient, and the Common Name is ignored even when present. Certificate authorities validate ownership of each entry before issuing, which is why adding a host name to an existing certificate means reissuing it with an updated list, not editing a field in place.

Types of SAN entries

RFC 5280 defines several SAN entry types, though a few dominate practice. DNS name (dNSName) entries are the most common, identifying a certificate by fully qualified domain name; a leading wildcard (*.example.com) covers an entire subdomain tier in one entry. IP address (iPAddress) entries identify a certificate by literal IPv4 or IPv6 address. Email address and URI entries appear in S/MIME and other non-web uses, far less common in TLS deployments.

Two deployment patterns build on these types. A multi-domain (SAN/UCC) certificate lists several unrelated domains in one certificate, useful where an organization runs many services but wants one certificate to manage. A wildcard-plus-SAN certificate combines a wildcard entry with explicit entries for hosts outside that pattern.

SAN & Versa

Versa Messaging Service (VMS) certificates are the clearest place SAN surfaces in a Versa deployment. When installing and configuring VMS, every certificate – the server certificate agents and VOS devices use, and the internal database certificate – must carry a SAN entry for each FQDN or IP the cluster answers on: the management interface, the elastic interface for agent traffic, and the southbound interface. Both the self-signed script and the CSR workflow, which prompts for five to seven SAN entries, enforce this.

High-availability clusters raise the requirement further: an HA-based VMS deployment needs SAN entries for every node’s FQDN plus the shared elastic FQDN, so the certificate stays valid regardless of which node answers. A missing SAN entry – often the elastic FQDN, added after the fact – commonly causes connectivity failures, since the handshake fails even though the network path is fine.

Frequently asked questions

What is the difference between a SAN and a Common Name?

The Common Name (CN) is a single legacy identity field in a certificate’s Subject; SAN is a list holding many identities – DNS names, IP addresses, and more. Modern TLS clients validate against SAN only; CN is ignored for identity matching even when populated.

Can a certificate have a SAN and no Common Name?

Yes. The CA/Browser Forum’s Baseline Requirements permit certificates with an empty or absent Common Name as long as SAN is present, and some certificate authorities now omit CN by default. SAN alone is sufficient for identity validation; nothing depends on CN anymore.

Why did browsers stop trusting the Common Name?

Relying on the Common Name allowed ambiguity and inconsistent parsing across different TLS libraries, which attackers exploited to obtain misleading certificates. Chrome deprecated CN matching in 2017, and the CA/Browser Forum later mandated SAN for all publicly trusted certificates industry-wide.

What happens if a certificate is missing a SAN entry for the host being accessed?

The TLS handshake fails validation – clients and browsers reject the connection with a name-mismatch error, even if the Common Name matches or the certificate is otherwise valid. The fix is reissuing with the missing host added to its SAN list.

Can one certificate’s SAN list include both DNS names and IP addresses?

Yes. A single SAN list can mix entry types – DNS names, IP addresses, email addresses, and URIs – as long as each entry is validated by the issuing certificate authority. Mixing DNS and IP entries is common for infrastructure reachable both ways.

More on SAN

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about SAN, these are worth looking at next.