Multi-Domain SAN Certificates

A SAN certificate is a certificate with a list.

That's the core idea. Where a normal certificate says "I am example.com," a SAN certificate says "I am example.com, and also www.example.com, and also mail.example.com, and also api.totallydifferentsite.org." One certificate, multiple identities, single private key.

The "SAN" stands for Subject Alternative Name—an extension field in the certificate that lists every domain it covers. Browsers check this list. If the domain you're visiting appears in it, the certificate is valid for that connection. If not, you get a security warning.

How the List Works

When your browser connects to an HTTPS site, the server presents its certificate. The browser extracts the SAN extension and checks: is the domain I requested in this list?

The matching is exact. A certificate listing www.example.com does not cover example.com. A certificate listing example.com does not cover mail.example.com. Every domain you want covered must be explicitly listed.

This is different from wildcard certificates, which use pattern matching (*.example.com covers any subdomain). SAN certificates use explicit enumeration. You say exactly what's covered, nothing more.

What Makes SAN Certificates Useful

Unrelated domains, one certificate. Wildcard certificates only cover subdomains of a single base domain. SAN certificates can cover example.com, example.org, totally-different-brand.net, and acquisition-company.io all at once. No hierarchical relationship required.

Precise control. You list exactly what's covered. No pattern matching that might accidentally cover a subdomain you didn't intend.

Simpler validation. Each domain can be validated via HTTP challenge. Wildcard certificates require DNS validation, which is more complex to automate.

The www problem, solved. Almost every SAN certificate exists to cover both example.com and www.example.com. This is the most common use case by far.

The Constraints of Sharing

All domains in a SAN certificate share one private key. This creates consequences:

One key to protect them all. Compromise that key and every domain is compromised. You can't whisper one name and shout another—they all share one voice.

Revocation is all-or-nothing. You cannot revoke coverage for a single domain. Revoke the certificate, and every domain loses its protection until you obtain a new one.

Renewal requires unanimous validation. When renewing, you must prove control of every domain in the list. Lost access to one? The entire renewal fails.

Certificate Transparency reveals everything. Every domain in your certificate appears in public CT logs. Include your secret staging environment? It's not secret anymore.

You Cannot Edit a Certificate

This feels like it should be obvious, but it trips people up: certificates are immutable. Once issued, you cannot add a domain. You cannot remove a domain. You cannot change anything.

Want to add blog.example.com to your existing certificate? You get a new certificate that includes it. The old certificate continues to exist until it expires or you revoke it.

With Let's Encrypt, this is trivial—request a new certificate with the updated list, takes seconds, costs nothing. With commercial CAs, policies vary. Some charge fees for "modifications" (which are really new certificates). Some require starting the purchase process over.

How Many Domains Can You List?

Let's Encrypt allows up to 100 domains per certificate. This covers nearly every legitimate use case.

Commercial CAs vary. Some include a handful in the base price and charge per additional domain. Some offer higher limits for premium products.

The X.509 standard doesn't impose strict limits, but certificates with hundreds of domains become unwieldy. The certificate itself grows larger, slightly slowing TLS handshakes. Management becomes a nightmare. If you're approaching 100 domains, consider whether separate certificates make more sense.

SAN vs. Wildcard: When to Use Which

Use SAN when:

• You need to cover unrelated domains
• You want explicit control over exactly what's covered
• You prefer HTTP validation over DNS validation
• You're covering a known, stable set of domains

Use wildcard when:

• You create subdomains dynamically
• You want automatic coverage of future subdomains
• All covered domains share a base domain

Use both when: Many certificates combine approaches: example.com + www.example.com + *.example.com. This covers the apex domain, the www subdomain explicitly, and all other subdomains via wildcard.

Obtaining a SAN Certificate

With Let's Encrypt and Certbot:

certbot certonly --webroot -w /var/www/html \
  -d example.com \
  -d www.example.com \
  -d mail.example.com

Each -d flag adds a domain to the SAN list. Certbot validates each one, obtains a single certificate covering all of them, and handles automated renewal.

With other ACME clients or commercial CAs, the process varies but the concept is identical: specify all domains, prove control of each, receive one certificate.

Should You Use SAN Certificates?

The practical question: should you consolidate domains into SAN certificates, or use separate certificates?

Arguments for SAN certificates:

• One certificate to monitor and renew
• Simpler configuration
• Works on ancient systems that don't support SNI (rare today)

Arguments for separate certificates:

• Security isolation—compromise of one doesn't affect others
• Independent lifecycles—renew or revoke independently
• Can use different validation levels per domain

With Let's Encrypt and automated certificate management, the "simpler management" argument has weakened. Separate certificates provide better security isolation with minimal additional complexity.

For most deployments: use a SAN certificate for your primary domain and www, then evaluate whether consolidating further makes sense for your specific situation.