SAN Certificates: Multi-Domain SSL Explained

A SAN (Subject Alternative Name) certificate is an SSL certificate that covers multiple domain names within a single certificate. Instead of buying separate certificates for example.com, example.org, and myotherbrand.com, you can list all three as Subject Alternative Names on one certificate. This simplifies certificate management, reduces costs, and makes installation easier when multiple domains share the same server.

SAN certificates are also called multi-domain certificates, UCC (Unified Communications Certificates), or simply multi-SAN certificates. They are standard X.509 certificates with multiple entries in the Subject Alternative Name extension. For the broader picture of certificate types, see Types of SSL Certificates.

What Subject Alternative Names Are

The Subject Alternative Name is an X.509 certificate extension that lists additional identities the certificate is valid for. Originally, SSL certificates identified the domain through the Common Name (CN) field in the certificate's subject. The SAN extension was introduced to support multiple identities on a single certificate.

Modern browsers and the CA/Browser Forum Baseline Requirements now require that the domain name be in the SAN extension. The Common Name is effectively ignored by most browsers (though it is still required by the standard). This means every modern SSL certificate is technically a "SAN certificate" -- even a single-domain certificate lists its domain in the SAN field.

When people say "SAN certificate," they typically mean a certificate with multiple SAN entries covering different domain names.

How SAN Certificates Work

A SAN certificate's Subject Alternative Name extension contains a list of DNS names:

X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:example.org
    DNS:www.example.org
    DNS:myotherbrand.com
    DNS:www.myotherbrand.com

When a browser connects to any of these domains and the server presents this certificate, the browser checks the requested domain against the SAN list. If the domain appears in the list, the certificate is valid for that connection.

All domains on a SAN certificate share the same private key and the same certificate file. This means the same certificate is installed on every server that handles any of the listed domains. If the domains are on different servers, the same certificate (and private key) must be deployed to all of them.

When to Use a SAN Certificate

Multiple Domains on the Same Server

The most common use case is hosting multiple domains on a single server or load balancer. A web server running example.com and example.org needs a valid certificate for both. A SAN certificate covers both without needing separate certificates.

Related Brands

Organizations that own multiple brand domains often use SAN certificates:

primarybrand.com
secondarybrand.com
companyblog.com
support.primarybrand.com

All covered by one certificate, installed on the shared infrastructure.

Microsoft Exchange and Office 365

Microsoft Exchange servers typically need certificates covering multiple hostnames: the mail server's hostname, the Autodiscover hostname, the Outlook Web Access hostname, and possibly the legacy server name. UCC/SAN certificates were originally designed for this use case.

Staging and Production Domains

A SAN certificate can cover both production and staging domains if they share a server or load balancer:

example.com
staging.example.com
preview.example.com

Domain Migrations

During a domain migration from olddomain.com to newdomain.com, a SAN certificate covering both domains lets you serve HTTPS on both while the migration is in progress.

SAN vs Wildcard Certificates

SAN and wildcard certificates solve different problems, and they can be combined.

Wildcard certificates cover a domain and all its first-level subdomains: *.example.com matches www.example.com, blog.example.com, api.example.com, and any other subdomain. But a wildcard only covers subdomains of one domain. It does not cover example.org or anotherdomain.com.

SAN certificates cover a specific list of domain names. They can include entirely different domains (example.com and anotherdomain.com), but they only cover the exact names listed, not arbitrary subdomains.

| Feature | SAN Certificate | Wildcard Certificate | |---|---|---| | Multiple domains | Yes | No (one domain only) | | Unlimited subdomains | No (only listed names) | Yes (one level) | | Cross-domain coverage | Yes | No | | Adding domains later | Yes (reissuance) | Not needed (auto-covers new subdomains) | | Multi-level subdomains | If listed | No |

Multi-domain wildcard certificates combine both: a SAN certificate where some entries are wildcard domains (*.example.com, *.example.org). These cover arbitrary subdomains across multiple domains but are the most expensive option.

For wildcard details, see Wildcard SSL Certificates.

How Many SANs Can You Have?

The X.509 standard does not impose a hard limit on the number of SANs. However, CAs and their products set practical limits:

• Most commercial CAs support 3-250 SANs per certificate.
• Let's Encrypt supports up to 100 SANs per certificate.
• Some enterprise CAs support 500 or more.

The base certificate typically includes 3-5 SANs, with additional SANs available at a per-domain cost ($5-100 each, depending on the CA and validation level).

Pricing

SAN certificate pricing depends on the validation level and the number of domains:

| Validation | Base (3-5 SANs) | Additional SAN | |---|---|---| | DV | $15-80/yr | $5-15 each | | OV | $50-300/yr | $20-100 each | | EV | $100-500/yr | $50-150 each |

Let's Encrypt issues SAN certificates for free (up to 100 SANs). If your domains can all be validated through Let's Encrypt's automated process, this is the most cost-effective option.

For pricing context, see SSL Certificate Pricing Explained.

Getting a SAN Certificate

From Let's Encrypt (Free)

Use Certbot or another ACME client to request a certificate with multiple domains:

certbot certonly --standalone -d example.com -d www.example.com -d example.org -d www.example.org

Each domain must be validated (HTTP or DNS challenge). All domains must be reachable during the validation process.

From a Commercial CA

1. Generate a CSR with your primary domain as the Common Name.
2. During the order process, specify additional SAN domains.
3. Complete validation for each domain (DV, OV, or EV as applicable).
4. Receive the certificate with all SANs included.
5. Install on your server.

Adding or Removing SANs

To change the domains on a SAN certificate, you typically need to reissue the certificate. Most CAs allow free reissuance within the certificate's validity period. The reissued certificate has a new set of SANs but the same validity period.

Some CAs support adding SANs without full reissuance through their management platforms, but this is not universal.

Installation Considerations

Shared Private Key

All domains on a SAN certificate share the same private key. If the private key is compromised, all domains are affected. Consider whether sharing a key across different domains aligns with your security requirements.

Server Configuration

When installing a SAN certificate on a server that hosts multiple domains, configure each domain's virtual host to use the same certificate file. In Apache:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com example.org www.example.org
    SSLCertificateFile /path/to/san-certificate.crt
    SSLCertificateKeyFile /path/to/private.key
</VirtualHost>

In Nginx:

server {
    listen 443 ssl;
    server_name example.com www.example.com example.org www.example.org;
    ssl_certificate /path/to/san-certificate.crt;
    ssl_certificate_key /path/to/private.key;
}

CDN and Load Balancer Deployment

If your domains are behind a CDN or load balancer, upload the SAN certificate to the CDN/LB. Most CDN providers (Cloudflare, AWS CloudFront, Fastly) support SAN certificates.

Limitations

All domains are visible. Every domain on a SAN certificate is listed in the certificate and visible to anyone who inspects it. If you do not want people to know that secretproject.com is related to yourcompany.com, do not put them on the same certificate.

Validation for each domain. Every domain on the certificate must be validated. For OV and EV certificates, this can be time-consuming if the domains belong to different legal entities (which may not even be allowed by some CAs).

Renewal complexity. All domains must be revalidated at renewal time. If you lose control of one domain on the certificate, you cannot renew the certificate with that domain and must reissue without it.

Revocation affects all domains. If you need to revoke the certificate (due to key compromise, for example), all domains on the certificate are affected.

References

1. RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," May 2008. https://datatracker.ietf.org/doc/html/rfc5280
2. CA/Browser Forum, "Baseline Requirements," https://cabforum.org/baseline-requirements/
3. Let's Encrypt, "Rate Limits," https://letsencrypt.org/docs/rate-limits/