Subject Alternative Names (SAN) in SSL

Learn how Subject Alternative Names (SAN) allow a single SSL certificate to cover multiple domains and IP addresses. Understand SAN types, wildcard SANs, and modern browser requirements.

Certificate Fields

Detailed Explanation

What Are Subject Alternative Names?

The Subject Alternative Name (SAN) extension is an X.509 v3 certificate extension that specifies additional identities (domain names, IP addresses, email addresses) bound to the certificate's public key. In modern TLS, the SAN field is the primary way browsers and clients verify the server's identity.

SAN vs Common Name (CN)

Historically, the Common Name (CN) field in the Subject was used to identify the domain. However, RFC 6125 and all modern browsers now use the SAN extension as the authoritative source for identity matching. If a certificate has SANs, the CN is ignored for validation purposes.

Since 2017, Chrome does not accept certificates that rely solely on the CN — the SAN extension must be present.

SAN Types

X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:api.example.com
    DNS:*.staging.example.com
    IP Address:203.0.113.50
    email:admin@example.com
SAN Type Description Example
DNS Fully qualified domain name DNS:example.com
IP Address IPv4 or IPv6 address IP:203.0.113.50
email Email address (S/MIME) email:user@example.com
URI Uniform Resource Identifier URI:https://example.com

Multi-Domain Certificates (UCC/SAN Certificates)

A single certificate with multiple DNS SANs is called a Unified Communications Certificate (UCC) or Multi-Domain Certificate. This is commonly used for:

  • Covering both example.com and www.example.com
  • Protecting multiple domains: example.com, example.org, example.net
  • Microsoft Exchange environments with multiple service URLs

Wildcard SANs

A SAN entry can include a wildcard: DNS:*.example.com. This matches any single-level subdomain of example.com (e.g., www.example.com, api.example.com) but does not match example.com itself or multi-level subdomains like a.b.example.com.

SAN Limits

There is no hard limit in the X.509 standard on the number of SANs, but CAs typically impose practical limits:

  • Let's Encrypt — up to 100 SANs per certificate
  • Commercial CAs — varies, often 25–250 SANs
  • Certificate Transparency logs record all SANs, so they become public information

Checking SANs

openssl x509 -in cert.pem -noout -ext subjectAltName

This prints only the SAN extension from the certificate, making it easy to verify which domains are covered.

Use Case

Review the SAN extension to confirm which domains and IP addresses a certificate covers, especially when troubleshooting TLS errors where the certificate does not match the requested hostname.

Try It — SSL Certificate Decoder

Open full tool