The Subject Alternative Name (SAN) extension is what actually tells browsers and clients which domains, IPs, or email addresses a certificate is valid for. Get it wrong, and your users see security warnings. This guide explains how SANs work, how to configure them, and how to manage them at scale.
The Subject Alternative Name (SAN) is an X.509 certificate extension that specifies additional identities bound to the certificate. While the Subject field's Common Name (CN) historically contained the domain name, the SAN extension is now the authoritative field that browsers and clients use to verify identity.
A single certificate can contain multiple SANs, which is how multi-domain certificates work. For example, one certificate might be valid for www.example.com, api.example.com, and mail.example.com. Each of these is a SAN entry of type dNSName.
SANs are defined in RFC 5280, Section 4.2.1.6. They are a critical extension: if a certificate contains a SAN, clients must use it for identity matching and ignore the Common Name entirely.
For years, the Subject field's Common Name (CN) was the primary way to identify a certificate's intended domain. That era is over. Here's what changed and why.
| Common Name (CN) | Subject Alternative Name | |
|---|---|---|
| Location | Subject field | Extension (OID 2.5.29.17) |
| Multiple values | No (single value) | Yes (unlimited entries) |
| Types supported | Free-text string | DNS, IP, email, URI, directory |
| Browser behavior | Ignored if SAN present | Authoritative for matching |
| RFC status | Deprecated for matching (RFC 6125) | Required (RFC 5280) |
Key takeaway: Since Chrome 58 (2017), browsers ignore the Common Name if a SAN extension is present. If your certificate has a CN but no SAN, users will see ERR_CERT_COMMON_NAME_INVALID. Always include SANs.
The SAN extension supports several identity types, each suited to different use cases.
The most common type. Specifies a fully-qualified domain name the certificate is valid for.
DNS:www.example.com Binds the certificate to a specific IP address. Used for services accessed by IP rather than hostname.
IP:192.168.1.100 An email address. Used in S/MIME certificates to bind the certificate to a specific mailbox.
email:[email protected] A URI. Used in specialized contexts like SPIFFE IDs for workload identity in service meshes.
URI:spiffe://cluster.local/ns/default You can inspect the SAN entries of any certificate using the Evertrust Crypto Decoder or via OpenSSL:
openssl x509 -in cert.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com, DNS:api.example.comSANs are specified at the time you generate the Certificate Signing Request (CSR). Here's how to do it with OpenSSL.
Create a file called san.cnf with the SAN entries you need:
[req]
distinguished_name = req_dn
req_extensions = v3_req
prompt = no
[req_dn]
CN = www.example.com
O = Example Inc
C = US
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = api.example.com
IP.1 = 10.0.1.50openssl req -new -newkey rsa:2048 -nodes \
-keyout server.key -out server.csr \
-config san.cnfopenssl req -in server.csr -noout -text | grep -A1 "Subject Alternative"
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com, DNS:api.example.com, IP:10.0.1.50Both wildcard and SAN (multi-domain) certificates reduce the number of certificates you need to manage, but they work differently and have different security implications.
A wildcard like *.example.com covers all single-level subdomains: www.example.com, api.example.com, etc. It does not cover the bare domain (example.com) or multi-level subdomains (sub.api.example.com).
A SAN certificate lists each identity explicitly. It can include completely different domains, IP addresses, and even mix wildcards with specific names. This provides fine-grained control over what the certificate covers.
The most common mistake. A certificate with a CN but no SAN extension will trigger ERR_CERT_COMMON_NAME_INVALID in Chrome, Firefox, and Safari. Always include the primary domain as both CN and a SAN entry.
Including www.example.com but not example.com (or vice versa). Users access both, and a missing SAN means a certificate warning for one of them.
Public CAs cannot issue certificates with internal names like server01.corp.local. Use a private PKI for internal hostnames and reserve public certificates for publicly routable domains.
IP addresses in SANs must use the IP: prefix, not DNS:. Writing DNS:192.168.1.1 will cause validation failures because the client expects an IP type match, not a DNS lookup.
Adding dozens of SANs to one certificate creates a large blast radius: if that key is compromised, all domains are affected. It also creates operational coupling. Balance consolidation with risk management.
In enterprise environments with thousands of certificates, SAN management becomes a governance challenge. Here's how to keep it under control.
Use certificate templates in your CA to restrict allowed SAN types and patterns. For example, only permit *.yourcompany.com DNS names and block IP address SANs in production certificates.
Integrate domain ownership validation into your issuance workflow. Before a certificate with a SAN for api.example.com is issued, verify the requester actually owns that domain or subdomain.
Use certificate discovery to detect certificates with unexpected SANs. A certificate covering domains you don't recognize is a red flag for either misconfiguration or compromise.
Rather than cramming 50 domains into one certificate, use automated certificate management to issue individual certificates per service. This reduces blast radius and simplifies rotation.
SAN policy enforcement: Evertrust PKI lets you define certificate templates that restrict allowed SAN types, patterns, and counts. Prevent misconfigured certificates before they're issued.
Full SAN visibility: Evertrust CLM discovers every certificate across your infrastructure and indexes all SAN entries. Search by domain, IP, or email to find every certificate covering a specific identity.
Automated issuance with SANs: Use ACME, EST, or REST APIs to request certificates with the exact SANs your services need. No manual OpenSSL configuration required.