Subject Alternative Names: Protecting Multiple Domains with One Certificate

One of the most important extensions in a modern SSL certificate is the Subject Alternative Name (SAN). It's the authoritative list of every domain, IP address, or email address the certificate protects — and understanding it is key to diagnosing hostname mismatch errors.

Why SANs Replaced the Common Name

In early SSL, the Common Name (CN) field was used for domain matching. But CN was designed for a single value, and web servers increasingly needed to cover multiple names. The SAN extension solved this by allowing an arbitrary list of DNS:, IP:, email:, and URI: entries.

RFC 2818 (published in 2000) deprecated CN for domain matching in favor of SANs. Browsers enforced this in 2017 — Chrome 58 stopped checking CN entirely. Today, a certificate that lacks a SAN entry for the domain you're visiting will fail validation even if the CN matches. See our SAN vs CN comparison for the full story.

SAN Entry Types

• DNS: — a fully qualified domain name, optionally with a wildcard (e.g. *.example.com)
• IP Address: — a literal IPv4 or IPv6 address
• email: — used in S/MIME certificates
• URI: — used in code signing and some device certificates

Wildcards in SANs

A wildcard SAN entry like DNS:*.example.com matches any single-level subdomain — www.example.com, api.example.com — but not sub.api.example.com. Wildcards don't cross dot boundaries. For broader multi-domain coverage, see wildcard certificates and multi-domain certificates.

How Many SANs Can a Certificate Have?

The X.509 standard doesn't impose a hard limit, but most CAs cap it at around 100 SANs per certificate. Let's Encrypt allows up to 100 SANs. DigiCert and Sectigo support larger counts on request.

Reading SANs in the Decoder

Our SSL Certificate Decoder shows every SAN entry with its type and value. If a hostname mismatch error is occurring, check whether the domain in question appears in the SAN list — not the CN field.