What Is a SAN Certificate? Cover Multiple Domains With One SSL

What Is a SAN Certificate?

A SAN Certificate (Subject Alternative Names Certificate), also called a Multi-Domain SSL or UCC (Unified Communications Certificate), is a single SSL certificate that secures multiple completely different domain names within one certificate. Instead of purchasing separate SSL certificates for each domain, a SAN certificate lists all your domains as Subject Alternative Names.

For example, a company with multiple web properties could cover all of these with one SAN Certificate:

SAN Certificate vs Wildcard SSL: Key Differences

Benefits of Using a SAN Certificate

• Cost savings — One SAN cert covering 5 domains can be cheaper than 5 separate DV SSL certificates
• Simplified management — One renewal date instead of tracking 5 separate expiration dates
• Works across completely different domains — Something Wildcard SSL cannot do
• Supports internal hostnames — Some SAN certificates can include internal hostnames like mail.internal or IP addresses
• Reduced server complexity — Manage one certificate on a server instead of several

When to Use a SAN Certificate

A SAN certificate is the right choice when:

• Your company has multiple TLDs — e.g., example.com, example.co.th, example.net, example.org that all need HTTPS
• You operate multiple brands — a single company with separate domain names for each product line
• Microsoft Exchange or on-premise mail servers — typically require mail.company.com, autodiscover.company.com, and owa.company.com covered together (this is what "UCC" was originally designed for)
• SaaS companies with customer custom domains — each customer uses a different domain pointing to the same platform

How to Inspect SAN Entries in an Existing Certificate

openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A 10 "Subject Alternative Name"

The output lists all DNS entries in the certificate, such as: DNS:example.com, DNS:example.co.th, DNS:www.example.com

SAN Certificates and Let's Encrypt

Let's Encrypt supports free SAN Certificates covering up to 100 domains per certificate. Using Certbot:

certbot certonly --webroot \
  -w /var/www/example \
  -d example.com \
  -d example.co.th \
  -d shop.example.com \
  --email [email protected] \
  --agree-tos

However, Let's Encrypt only issues DV SAN certificates. For OV or EV multi-domain certificates — required by enterprises and financial organizations — you need a paid certificate from a CA like DigiCert or GeoTrust, both available through AsiaGB.

SAN Certificates and IP Addresses

SAN Certificates can include IP addresses as SAN entries (called IP SAN or IP SSL), enabling HTTPS for direct IP access — useful for internal APIs, monitoring dashboards, or systems that don't use domain names. Note that Let's Encrypt does not support IP SANs; only paid SSL certificates from commercial CAs support this feature.

Frequently Asked Questions

How many domains can one SAN Certificate cover?

This depends on the certificate product and CA. Commercial SAN certificates typically offer 3–250 SAN entries with pricing increasing per additional domain. Let's Encrypt supports up to 100 domains per certificate at no cost.

Can I add more domains to an existing SAN Certificate?

Yes, but you need to reissue the certificate with the additional SAN entries. During reissue, the CA issues a new certificate and the old one is revoked automatically once the new one is installed. Most commercial CAs allow unlimited reissues within the certificate's validity period at no extra charge.

Can a SAN Certificate combine wildcards and exact domains?

Yes. A SAN Certificate can mix exact domain names and wildcard entries — for example, example.com + *.example.com + another.com + *.another.com in a single certificate. This type is called a Multi-Domain Wildcard SSL and typically commands a premium price.

Installing a SAN Certificate on Your Web Server

Once your CA issues the SAN Certificate, installation follows the same general process as a standard SSL certificate — but with one key requirement: every domain listed in the SAN entries must have a correctly configured virtual host or server block.

Apache Configuration

In Apache, each domain in the SAN Certificate needs its own VirtualHost block. All blocks reference the same certificate files:

<VirtualHost *:443>
  ServerName example.com
  SSLEngine on
  SSLCertificateFile     /etc/ssl/certs/san-certificate.crt
  SSLCertificateKeyFile  /etc/ssl/private/san-certificate.key
  SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt
</VirtualHost>

<VirtualHost *:443>
  ServerName example.co.th
  SSLEngine on
  SSLCertificateFile     /etc/ssl/certs/san-certificate.crt
  SSLCertificateKeyFile  /etc/ssl/private/san-certificate.key
  SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt
</VirtualHost>

Nginx Configuration

Nginx makes multi-domain SSL simpler — list all SAN domains in a single server block using server_name:

server {
  listen 443 ssl;
  server_name example.com example.co.th;

  ssl_certificate     /etc/ssl/certs/san-certificate.crt;
  ssl_certificate_key /etc/ssl/private/san-certificate.key;
}

Limitations and Risks of SAN Certificates

SAN Certificates are powerful, but understanding their limitations helps you make an informed decision and avoid surprises after deployment.

• Reissue required to add domains — Unlike Wildcard SSL which instantly covers any new subdomain, adding a new domain to a SAN Certificate requires a full reissue, including re-validation of the new domain.
• A revoked certificate affects all domains simultaneously — Because all domains share one certificate, a compromised private key means all domains go down together when the certificate is revoked.
• Cost increases with each SAN entry — Unlike Wildcard SSL where the price is fixed regardless of subdomain count, SAN pricing scales with the number of entries you need.
• Validation required for every domain — The CA must verify ownership of each domain listed as a SAN entry. If any domain fails validation, the certificate cannot be issued.
• No multi-level wildcards — SAN Certificates support *.example.com as a SAN entry, but *.*.example.com is not supported by any commercial CA.

Real Cost Comparison: SAN Certificate vs Buying Separately

Many organizations are uncertain whether a SAN Certificate is actually cheaper than buying separate SSL certificates. The table below compares total cost of ownership for typical scenarios:

Beyond direct cost, the hidden expense is the management time spent tracking multiple expiry dates. A single expired certificate that slips through causes browser security warnings across the affected site — directly harming user trust and conversion rates.

Monitoring SAN Certificate Expiry

Because a SAN Certificate covers multiple domains simultaneously, its expiry affects all of them at once. Monitoring and early renewal are more critical than for a single-domain certificate. Follow these best practices:

• Set renewal alerts 60 days before expiry — this gives you time to reissue with updated SAN entries if needed
• Use automated SSL monitoring — tools like UptimeRobot, StatusCake, or a self-hosted Uptime Kuma instance can alert you when any domain's SSL is approaching expiry
• Inspect with OpenSSL to verify expiry date and confirm all expected domains are still present in the certificate

# Check certificate expiry date
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# List all SAN entries in the certificate
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A5 "Subject Alternative"

AsiaGB provides SSL certificates for every use case — from DV SAN certificates for general websites to OV and EV SAN certificates for enterprises and financial institutions. Our team can advise on the right number of SAN entries for your domain structure and assist with reissues when you add new domains.