A multi-domain SSL certificate (also called SAN or UCC certificate) secures multiple different domain names with a single certificate. Instead of managing separate certificates for example.com, example.org, and myapp.io, one SAN certificate covers all of them.
This is different from a wildcard certificate, which covers subdomains of one domain. A SAN certificate can cover entirely different domains.
How SAN certificates work
SAN stands for Subject Alternative Name — a field in the X.509 certificate standard that lists additional domain names the certificate is valid for. When your browser connects to a server, it checks if the requested domain matches any SAN entry.
Here’s what a multi-domain certificate looks like internally:
Certificate for:
CN: example.com
SAN: example.com
SAN: www.example.com
SAN: example.org
SAN: api.myapp.ioAll four domains are secured by a single certificate with a single private key. The browser accepts the connection if the requested hostname matches any SAN entry.
Limits: Let’s Encrypt supports up to 100 SAN entries per certificate. Commercial CAs vary — some allow 250+, some charge per entry.
Common use cases
Multiple brand domains
You run brandname.com, brandname.co.uk, and brandname.de. One SAN certificate covers all three without managing separate certificates per region.
Domain + www variants
The most common SAN use: example.com + www.example.com. Most certificates include both automatically. GetHTTPS prompts you to add the www variant when you enter a bare domain.
Microservices on different domains
Your API lives at api.company.com, your docs at docs.company.com, and your marketing site at company.com. A SAN certificate secures all three. If they’re all subdomains, a wildcard might be simpler.
Migration between domains
Moving from olddomain.com to newdomain.com? A SAN certificate covering both lets you serve HTTPS on both domains during the transition without maintaining two separate certificates.
SAN vs Wildcard
| SAN (multi-domain) | Wildcard | |
|---|---|---|
| Covers | Specific listed domains | All subdomains of one domain |
| Cross-domain | ✅ example.com + other.com | ❌ One base domain only |
| New domains | Requires new certificate | New subdomains covered automatically |
| Challenge type | HTTP-01 or DNS-01 | DNS-01 only |
| Certificate size | Grows with each SAN entry | Fixed |
| Use case | Multiple distinct domains | Many subdomains of one domain |
| Let’s Encrypt limit | 100 names per cert | 1 wildcard per cert (combine with SAN) |
You can combine both: A single certificate can include example.com, *.example.com, and other.com as SAN entries. This is common for covering the bare domain, all subdomains, and additional domains in one cert.
Getting a multi-domain certificate with GetHTTPS
- Go to gethttps.com/app/setup
- Enter all domains you want to cover:
example.com,www.example.com,example.org - Complete a challenge for each domain — HTTP-01 (place a file) or DNS-01 (add a TXT record)
- GetHTTPS pre-checks each challenge before submitting to Let’s Encrypt
- Download one certificate covering all domains
Each domain needs its own validation because Let’s Encrypt must verify you control each one independently. GetHTTPS handles them sequentially — you verify one, then the next.
Example: 3 domains, mixed challenges
| Domain | Challenge type | What you do |
|---|---|---|
example.com | HTTP-01 | Place a file on the server |
www.example.com | HTTP-01 | Same server, same process |
example.org | DNS-01 | Add a TXT record (different DNS provider) |
After all three pass, you get one certificate file set (fullchain.pem, privkey.pem) that covers all three.
Installing a multi-domain certificate
Installation is identical to a single-domain certificate. The server doesn’t care how many SANs are in the cert — it uses the same files.
Nginx:
server {
listen 443 ssl http2;
server_name example.com www.example.com example.org;
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
}Apache:
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com example.org
SSLEngine on
SSLCertificateFile /etc/ssl/cert.pem
SSLCertificateKeyFile /etc/ssl/privkey.pem
SSLCertificateChainFile /etc/ssl/chain.pem
</VirtualHost>If the domains point to different servers, install the same certificate files on each server. The certificate is valid for all listed domains regardless of which server presents it.
Frequently asked questions
Is a SAN certificate more expensive?
Not with Let’s Encrypt. You can include up to 100 domains in a single free certificate via GetHTTPS. Some commercial CAs charge $10-50 per additional SAN entry.
Do all domains need to be on the same server?
No. The certificate works on any server. Install the same fullchain.pem and privkey.pem on each server that needs to serve any of the listed domains.
Can I add a domain to an existing SAN certificate?
Not directly — you can’t modify an issued certificate. You need to request a new certificate that includes all domains (existing + new). With GetHTTPS, this takes a few minutes.
When should I use separate certificates instead?
Use separate certificates when:
- Different teams manage different domains (separate keys = separate access control)
- Different renewal schedules are needed
- Isolation matters — compromising one key shouldn’t affect other domains
- You exceed 100 names — split across multiple certificates
How does SAN affect certificate size?
Each SAN entry adds ~30-50 bytes to the certificate. At 100 entries, the certificate is a few KB larger. This has negligible impact on TLS handshake speed.
What’s the difference between SAN and UCC?
UCC (Unified Communications Certificate) is Microsoft’s name for multi-domain SAN certificates, originally designed for Exchange and Office Communications Server. Technically they’re the same thing — a certificate with multiple SAN entries.