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.
Create a file called san.cnf with the SAN entries you need:
The most common type. Specifies a fully-qualified domain name the certificate is valid for.
Binds the certificate to a specific IP address. Used for services accessed by IP rather than hostname.
An email address. Used in S/MIME certificates to bind the certificate to a specific mailbox.
A URI. Used in specialized contexts like SPIFFE IDs for workload identity in service meshes.
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.
| 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) |
openssl x509 -in cert.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com, DNS:api.example.com[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.50SAN 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.