SAN certificates don’t secure just one name; they secure a whole list of names, and that’s why they’re the unsung heroes of modern TLS.
Imagine you have www.example.com. A basic certificate can cover that. But what if you also need mail.example.com, api.example.com, and even example.com (the bare domain)? A SAN certificate can bundle all of these under a single identity, saving you the hassle and cost of managing multiple individual certificates.
Here’s what a SAN certificate looks like in the wild. Let’s say we’re inspecting the certificate for www.example.com on a web server.
openssl s_client -connect www.example.com:443 -servername www.example.com | openssl x509 -noout -text
(This command connects to the server, requests the certificate, and then pipes it to openssl x509 for text parsing.)
Look for the Subject Alternative Name section. It will look something like this:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:mail.example.com, DNS:api.example.com, DNS:example.com, IP Address:192.168.1.100
This tells you that this single certificate is valid for www.example.com, mail.example.com, api.example.com, example.com, and even an IP address 192.168.1.100. When your browser connects to any of these names, it will see this certificate, check if the name it’s connecting to is in this list, and if it is, the connection proceeds. If you tried to connect to ftp.example.com and it wasn’t in this list, your browser would throw a certificate name mismatch error.
The problem SAN certificates solve is the explosion of unique hostnames that need TLS protection. In a dynamic environment, or even a moderately sized one, you might have dozens or hundreds of subdomains, internal hostnames, and even IP addresses that require secure connections. Managing individual certificates for each of these becomes a nightmare. You’d have to:
- Purchase/Generate: Get a certificate for each name.
- Deploy: Install each certificate on the relevant server(s).
- Renew: Track expiration dates for all of them and renew them before they expire.
- Manage Keys: Securely store and manage private keys for each certificate.
SAN certificates consolidate this. You request one certificate, listing all the names you need to cover. The Certificate Authority (CA) validates your control over all those names and issues a single certificate that covers them all. This significantly simplifies management and reduces operational overhead.
Internally, the Subject Alternative Name (SAN) extension is an X.509 v3 extension. It’s an array of general names, where each name can be of a different type. The most common types are DNS (for Domain Name System names, i.e., hostnames) and IP Address. You can also have other types like URI, email, etc., though DNS and IP Address are by far the most prevalent for web servers.
When a client (like your browser) establishes a TLS connection, it requests the server’s certificate. The client then examines the certificate’s Subject field (which typically contains the primary organization name) and, crucially, the Subject Alternative Name extension. The client checks if the hostname it’s trying to connect to matches any of the DNS entries or if the IP address matches any of the IP Address entries within the SAN extension. If there’s a match, and the certificate is otherwise valid (trusted CA, not expired, etc.), the connection is secured. If there’s no match, the client will refuse to connect, issuing a security warning.
The "Subject" field of a certificate historically held the "common name" (CN) of the entity. For a long time, people relied on the CN to match the hostname. However, the CN is only a single name. The SAN extension was introduced to allow for multiple names. Modern best practice, and often a requirement from CAs, is to use SANs for all names, even if there’s only one. This means you might see a certificate where the Subject has a CN, but the Subject Alternative Name extension lists the same name, along with any others.
When you’re requesting a SAN certificate, you specify all the hostnames and IP addresses you need covered. For example, when using certbot to obtain a Let’s Encrypt certificate, you’d typically provide all your domains using the -d flag:
sudo certbot --nginx -d www.example.com -d mail.example.com -d api.example.com -d example.com
Certbot will then ensure that the resulting certificate includes all these names in its SAN extension. If you’re manually generating a Certificate Signing Request (CSR), you’ll need to configure your OpenSSL settings to include the SAN extension with all your desired names. This is usually done in the [req] section of your openssl.cnf file or via command-line arguments.
For example, to create a CSR with SANs:
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr \
-subj "/C=US/ST=State/L=City/O=Organization/CN=www.example.com" \
-addext "subjectAltName = DNS:www.example.com,DNS:mail.example.com,IP:192.168.1.100"
The CN in the -subj is still often required by older systems or for backward compatibility, but the subjectAltName extension is what modern clients actually use for validation.
A common pitfall is forgetting to include internal hostnames or IP addresses in your SAN list. If you have a web application that is accessed both externally via app.example.com and internally via 192.168.1.50, you must include both DNS:app.example.com and IP:192.168.1.50 in your SAN list. Otherwise, users connecting via the IP address will receive a certificate error, even though the certificate is valid for the external hostname.
The sheer number of possible SAN entries is limited by the ASN.1 structure of the certificate, but in practice, the limit is extremely high (often hundreds or even thousands of entries), far beyond what most organizations would ever need. The real constraint is usually the CA’s policy or the CSR generation tool’s input limits.
When you’re managing certificates for a complex, multi-tenant, or highly distributed system, SAN certificates are not just convenient; they are essential for maintaining a robust and manageable TLS infrastructure. The next step after mastering SANs is understanding wildcard certificates and how they interact with SANs for even greater flexibility.