A single TLS certificate can secure an entire wildcard domain and all of its subdomains, plus any number of explicitly listed additional domains, all at once.
Let’s see this in action. Imagine you have a primary domain, example.com, and you want to secure it, its www subdomain, and also api.example.com, staging.example.com, and even a completely different domain, another-site.org. You can do this with one certificate.
Here’s a simplified representation of what such a certificate’s Subject Alternative Name (SAN) extension would look like:
Subject: CN=example.com
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:api.example.com, DNS:staging.example.com, DNS:another-site.org
The CN (Common Name) is often the primary domain, but the real power comes from the Subject Alternative Name (SAN) extension. This is where you list all the DNS names the certificate is valid for.
The problem this solves is the administrative overhead of managing separate certificates for each domain or subdomain. Instead of generating, renewing, and deploying dozens of individual certificates, you can consolidate them into a single, manageable certificate. This is particularly useful for:
- Shared infrastructure: Servers hosting multiple distinct websites or APIs.
- Brand consolidation: A company owning several domain names that all point to similar or related services.
- Development/Staging environments: Quickly setting up secure access for various test subdomains.
Internally, when a client (like a web browser) connects to a server using TLS, it presents the server’s certificate. The client then checks if the hostname it’s trying to connect to is listed in the certificate’s SAN extension. If it finds a match, the connection is considered secure for that hostname. If the hostname isn’t in the SAN list, the client will present a security warning.
The key levers you control are the specific DNS names you include in the SAN extension during the certificate request. When requesting a certificate, you’ll typically provide a list of all desired hostnames.
For example, using certbot with an ACME provider like Let’s Encrypt, you might issue a certificate covering multiple domains like this:
sudo certbot certonly --manual --preferred-challenges dns \
-d example.com \
-d www.example.com \
-d api.example.com \
-d staging.example.com \
-d another-site.org
The certbot tool will then prompt you to create DNS TXT records for each domain to prove ownership. Once validated, it will issue a single certificate file (e.g., fullchain.pem) containing all the specified SANs. You then configure your web server (like Nginx or Apache) to use this single certificate file for all the corresponding virtual hosts or server blocks.
For Nginx, this would look something like:
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ... other SSL settings and location blocks
}
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ... other SSL settings and location blocks
}
server {
listen 443 ssl;
server_name staging.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ... other SSL settings and location blocks
}
server {
listen 443 ssl;
server_name another-site.org;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ... other SSL settings and location blocks
}
Notice how the same certificate and key files are referenced for multiple server_name directives. This is the core of the consolidation.
The most surprising thing about SAN certificates is that the CN field in the certificate’s subject is largely decorative for modern TLS validation; the client only checks the Subject Alternative Name extension for matching hostnames. If a hostname appears in the SAN, it’s considered valid, regardless of what the CN says. This is why a certificate issued for example.com might have CN=example.com but still be perfectly valid for www.example.com if www.example.com is listed in the SAN.
The maximum number of SAN entries allowed in a certificate is typically around 100, though this can vary slightly by Certificate Authority.