A multi-domain SSL certificate, also called a SAN (Subject Alternative Names) certificate, is a certificate that secures multiple distinct domains and subdomains under a single certificate file. Instead of installing and renewing a separate certificate for each domain, you manage one that covers them all.
Below we explain how it works, how it differs from a wildcard certificate, and when it's the smartest choice for your project.
What Are SANs and How Do They Work?
The X.509 standard — the base format for all SSL/TLS certificates — includes a field called Subject Alternative Name (SAN). It was originally designed to list multiple identifiers under a single certificate: domains, subdomains, IP addresses, and even email addresses.
When a browser verifies a certificate, it checks both the Common Name (CN) field and all registered SANs. If the current domain matches any of them, the connection is valid.
A typical SAN certificate might protect:
mycompany.comwww.mycompany.commycompany.co.ukstore.mycompany.commycompany.net
All with a single pair of files (certificate + private key) installed on the server.
Key Differences: SAN vs. Wildcard vs. Individual Certificate
| Feature | Individual | Wildcard | SAN (Multi-Domain) |
|---|---|---|---|
| Domains covered | 1 | 1 domain + all one-level subdomains | Multiple distinct domains (up to ~100 SANs) |
| Distinct subdomains | No | Yes (same base domain only) | Yes (any domain) |
| Different TLDs | No | No | Yes |
| Management | One cert per domain | One certificate | One certificate |
| Relative cost | Low per unit, high at scale | Medium | Medium-high; scales well |
The critical difference from a wildcard: *.mycompany.com covers store.mycompany.com and blog.mycompany.com, but it does not cover mycompany.co.uk or mycompany.net. For different root domains, you need SAN.
When to Use a SAN Certificate
A multi-domain certificate is the right choice when:
- You have a presence across multiple domain extensions (.com, .co.uk, .net, .org) and want to secure them all.
- You manage sites for multiple clients from a single server and need one certificate per server (as in managed shared hosting).
- You have an intranet or staging environment on a different domain than production but want to cover them together.
- You run an e-commerce store with a main domain and a checkout on a separate subdomain or alternate domain:
mystore.comandcheckout.mystore.co.ukunder one certificate. - You want to simplify renewals: renewing one certificate instead of five or ten reduces the risk of letting one expire.
On the other hand, if you only need to protect subdomains of the same base domain (blog., api., app.), a wildcard certificate is simpler and more cost-effective.
Validation Levels and Available SAN Types
SAN certificates are available at all three standard validation levels:
- DV (Domain Validation): automated domain ownership check. Fastest to obtain (minutes). Ideal for blogs, portfolios, and internal projects.
- OV (Organization Validation): the CA verifies the organization exists. Company details appear in the certificate. Recommended for corporate sites.
- EV (Extended Validation): the strictest level. Thorough verification process. Recommended for banking, high-value e-commerce, and government portals.
Let's Encrypt issues DV certificates with multiple SAN support for free, making them very popular for projects spanning several owned domains. Commercial CAs like DigiCert, Sectigo, or GlobalSign offer OV and EV SAN certificates with warranties and additional support.
To dive deeper into certificate type differences, visit our SSL security section for detailed comparison guides.
How to Add or Modify SANs in a Certificate
SANs are defined when generating the CSR (Certificate Signing Request). They cannot be modified afterward without revoking the current certificate and issuing a new one.
In practice, to add a new domain to an existing SAN certificate you must:
- Generate a new CSR that includes all SANs (the previous ones plus the new one).
- Request a reissue from your CA.
- Complete domain validation for each newly added domain.
- Install the new certificate on the server.
Most CAs allow free reissues during the certificate's validity period, so adding domains typically has no extra cost.
The team at elenlace.com can handle the full process of issuing, configuring, and installing SAN certificates on any server or hosting control panel, including the correct certificate chain to prevent browser errors.
Key Takeaways
- A SAN SSL certificate protects multiple distinct domains — including different TLDs — under a single certificate file.
- It beats a wildcard when you need to cover different root domains, not just subdomains.
- It simplifies renewals and reduces the risk of missing an expiring certificate when you manage several domains.
- Available in DV, OV, and EV levels; Let's Encrypt offers free DV SANs.
- SANs are fixed at CSR time; to add new domains you must reissue the certificate.
Need to protect multiple domains with a single certificate? Reach out to elenlace.com and we'll advise you on the right SAN certificate type for your use case, installation included.
FAQ
How many domains can a SAN certificate cover?
Technically the standard allows 100 or more SANs, but most commercial CAs offer plans for 5, 10, 25, or 100 domains. Let's Encrypt allows up to 100 SANs per certificate for free.
Can a SAN certificate cover subdomains?
Yes, you can include specific subdomains as SANs (for example, store.mydomain.com). However, if you need to cover all subdomains of a base domain without listing them one by one, a wildcard certificate (*.mydomain.com) is more practical.
Can I combine SANs and wildcards in the same certificate?
Yes. Many CAs allow issuing certificates that include both wildcard entries (*.mycompany.com) and distinct additional domains (mycompany.co.uk). This offers maximum flexibility for complex infrastructures.
Does a SAN certificate affect server performance?
Not significantly. The number of SANs in a certificate has a minimal impact on certificate size and TLS handshake time. Performance is far more influenced by the chosen cipher suite and the server's TLS configuration.
Further reading
Other providers and guides worth comparing:
