Multi-Domain SSL: SAN Certificates, Wildcards, and What to Use

A multi-domain certificate lists every hostname it covers in the Subject Alternative Name field. Modern TLS ignores the Common Name entirely, so SAN is not an extra — it is the whole mechanism.

The terminology around this is worse than the technology. Multi-domain, SAN, UCC, and wildcard get used loosely and sometimes interchangeably, which makes buying decisions harder than they should be.

The underlying model is simple. A certificate carries a list of names it is valid for. How that list is written determines what it covers, and the choice between explicit names and a wildcard has real consequences for both operations and security.

Table of contents

• What SAN actually means
• SAN versus wildcard
• The security trade nobody mentions at purchase time
• SNI: why you no longer need an IP per certificate
• Getting multi-domain certificates free with ACME
• Renewals, and the failure that takes sites down
• How this fits the rest of the stack
• FAQ

What SAN actually means

Subject Alternative Name is an X.509 extension holding the list of identities a certificate is valid for. Every hostname the certificate covers appears there.

The historical Common Name field held a single name, and SAN was added to cover more. Since 2017 every major browser has ignored Common Name entirely and validates against SAN only. So a certificate without a SAN entry for the name you are visiting fails, regardless of what the CN says.

# Inspect what names a certificate actually covers
openssl x509 -in cert.pem -noout -text | grep -A1 "Subject Alternative Name"

# Against a live host
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

This is why “multi-domain certificate” and “SAN certificate” describe the same thing. Every certificate is a SAN certificate now; a multi-domain one simply has more than one entry in the list.

One consequence people miss: example.com and www.example.com are different names. A certificate covering only the bare domain will fail on the www host. Both need to be in the SAN list, and this is the single most common certificate mistake.

SAN versus wildcard

The two approaches solve overlapping problems differently.

• A SAN certificate lists each hostname explicitly: example.com, www.example.com, api.example.com, shop.other-domain.com. It can span entirely unrelated domains.
• A wildcard certificate covers one level of subdomain under a single domain: *.example.com matches api.example.com and www.example.com, but not example.com itself and not a.b.example.com.

The two limits of wildcards catch people out regularly. It matches exactly one label, so nested subdomains need their own wildcard. And it does not cover the apex domain — *.example.com does not match example.com, which is why wildcard certificates are nearly always issued with the bare domain added as an explicit SAN entry.

# A typical real-world certificate combines both approaches
DNS:example.com
DNS:*.example.com
DNS:other-brand.com
DNS:*.other-brand.com

Choose a wildcard when subdomains are created dynamically — per-tenant hostnames, preview environments — because adding a name to a SAN certificate means reissuing it. Choose explicit SAN entries when the list is stable and you want the certificate to state exactly what it covers.

The security trade nobody mentions at purchase time

A wildcard certificate is one private key valid for every subdomain. That is convenient, and it is also a larger blast radius.

If a wildcard key is compromised on a low-value host — a status page, a staging box, a marketing microsite — the attacker can impersonate every subdomain including the ones handling authentication and payments. With explicit SAN certificates, compromising the staging server’s key gives you the staging server.

This matters most when the wildcard key is distributed. Copying one key to a dozen servers so they can all terminate TLS means a dozen chances to leak it, and rotating it means touching all of them at once.

The practical middle ground: use a wildcard where dynamic subdomains genuinely require it, and issue separate certificates for the hosts that matter most. Do not put the wildcard key on a machine that does not need it.

SNI: why you no longer need an IP per certificate

The original reason multi-domain certificates existed was that TLS negotiation happened before the HTTP Host header was visible, so a server could not know which certificate to present. One certificate per IP address was the workaround.

Server Name Indication fixed this. The client sends the hostname it wants in the TLS handshake, so the server can select the right certificate. Every browser in current use supports it.

# Two separate certificates on one IP, selected by SNI
server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
}

server {
    listen 443 ssl;
    server_name other-brand.com;
    ssl_certificate     /etc/ssl/other-brand.pem;
    ssl_certificate_key /etc/ssl/other-brand.key;
}

So the decision is now about operational convenience rather than technical necessity. One certificate for twenty domains means one renewal to track; twenty certificates means twenty independent renewals but no single point of failure.

Test SNI behaviour explicitly, because the failure mode is subtle — without -servername, openssl omits SNI and you get the server’s default certificate rather than the one you meant to check.

openssl s_client -connect 203.0.113.10:443 -servername shop.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Getting multi-domain certificates free with ACME

Paid multi-domain certificates made sense when they were the only option. For domain-validated certificates — which is what almost everyone needs — ACME issues them free and automates renewal.

# Several explicit names on one certificate
certbot certonly --nginx \
  -d example.com -d www.example.com \
  -d api.example.com -d shop.other-brand.com

# Wildcard, which requires DNS validation
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Wildcards require DNS-01 validation, which means your ACME client needs API credentials for your DNS provider. HTTP validation cannot prove control of arbitrary subdomains, so there is no way around this.

Every name on the certificate must validate for the certificate to issue. Adding a domain whose DNS is not yet pointed at the server fails the whole request, not just that name — which is a confusing failure when you are adding a domain during a migration.

Extended validation certificates are the remaining paid case, and browsers stopped displaying the company name in the address bar years ago. The user-visible benefit that justified the price is gone.

Renewals, and the failure that takes sites down

Certificates expire. ACME certificates expire every ninety days, which makes automation mandatory rather than optional.

# Verify the renewal timer is active
systemctl list-timers certbot.timer

# Dry run the whole renewal path
sudo certbot renew --dry-run

# Check expiry on a live host
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

The classic failure: renewal succeeds, the new certificate is written to disk, and the web server keeps serving the old one because nothing reloaded it. The certificate on disk is valid and the site still shows an expiry error.

Fix that with a deploy hook so the reload is part of renewal rather than a separate thing somebody remembers.

sudo certbot renew --deploy-hook "systemctl reload nginx"

Monitor expiry externally as well. A check that connects from outside and reads the certificate dates catches the case where renewal silently stopped working weeks ago — which is the only way this goes wrong at scale.

How this fits the rest of the stack

Certificate management is one of those things that is invisible when it works and a public outage when it does not, and the failure is almost always automation that quietly stopped rather than a decision anybody made. RunxBuild provisions and renews certificates for custom domains automatically, including multiple domains on one project, so there is no renewal timer to monitor and no reload hook to forget. Domain configuration is covered in the docs, and the RunxBuild hosting calculator shows what a project with custom domains costs before you move DNS.

Useful related references:

• How to Renew an SSL Certificate: A 2026 Guide
• What Does SSL Mean? And Why Nobody Actually Uses SSL Anymore
• SSL_connect Error 5: What SSL_ERROR_SYSCALL Actually Means
• Custom domains and certificates on RunxBuild

FAQ

What is the difference between a SAN and a multi-domain certificate?

They are the same thing. Subject Alternative Name is the certificate field holding the list of covered hostnames; a multi-domain certificate is simply one with several entries in that list.

Does a wildcard certificate cover the root domain?

No. *.example.com matches one level of subdomain but not example.com itself. That is why wildcard certificates are normally issued with the bare domain added as an explicit SAN entry.

*Does .example.com cover a.b.example.com?

No. A wildcard matches exactly one label. Nested subdomains need either their own wildcard such as *.b.example.com, or explicit SAN entries.

Can I get a free multi-domain certificate?

Yes. ACME certificate authorities issue domain-validated multi-domain and wildcard certificates at no cost. Wildcards require DNS-01 validation, so your client needs API access to your DNS provider.

Why does my site show an expired certificate after a successful renewal?

The web server is still serving the old certificate from memory. Renewal writes the new file but does not reload the server. Add a deploy hook such as --deploy-hook "systemctl reload nginx" so the reload happens automatically.