Reference guide · dns-ssl · Published 2026-08-16 · 4 min read
Multiple domains on one SAN SSL certificate
SAN (multi-domain) SSL certificates explained: which names one cert covers, wildcard limits, and the renewal gotchas.
- ·What a SAN covers
- ·Single vs one-per-site
- ·Gotchas
What a SAN certificate covers
A SAN (Subject Alternative Name) certificate is an X.509 certificate that lists more than one name in its subjectAltName extension. Every name in that list is a valid name for the certificate: the same key pair covers example.com, www.example.com, shop.example.com, and often a completely unrelated domain like example.info. The alternative is a single-name certificate, which proves identity for exactly one name.
The practical reason SAN certs exist: the browser verifies the subjectAltName against the URL, and a cert with your site and its variants in one bundle covers a small family cheaply.
| Scenario | One SAN cert | One cert per name |
|---|---|---|
example.com + www.example.com | Full family on one cert | Two certs, two renewals |
Related subdomains blog, shop | One SAN, one renewal | Separate maintenance |
A wildcard *.example.com | See wildcards below | Wildcard plus a non-wild per name |
| Unrelated domain | Possible but messy | Stronger isolation |
How the names get in
You order the certificate with the exact names as subjectAltName entries. The names must be the absolute names you serve; a SAN does not auto-include the bare domain when you list www.example.com (you add both). This is why the www vs non-www decision is made before ordering a cert, and why a cert issued for one site name will not validate the bare domain.
Wildcard SANs exist: *.example.com in subjectAltName covers every one-level subdomain but not the apex (example.com itself) and not a second level (blog.sub.example.com). For a defined set, a SAN listing example.com, www.example.com, and shop.example.com is precise; a wildcard is usually about whole subdomain families you cannot enumerate in advance.
One SAN vs one cert per domain
The reason people split:
- Isolation. A breach in one tenant's TLS layer does not babysit a certificate that also names another tenant. On a multi-site agency platform the per-site cert is the safer default.
- Renewal blast radius. With one SAN for five domains, any change to the key, CA, or domain list requires re-issuing the single cert that covers all five; a single failed renewal takes down all five sites at once.
- Simpler provenance. When you check the certificate types family, a wildcard SAN scans as one certificate but only for names that resolve on the same server or a shared front-end that terminates TLS.
The case where a single SAN genuinely wins is a stable small set on one host with identical TLS configuration, because one renewal refreshes all names at once. Every other system line (tenant-agnostic hosting, wildcard subdomains that appear on demand, strict isolation) points at one cert per logical site.
Gotchas
- SAN is required in practice for any multi-name use. Modern browsers accept only subjectAltName for name matching; a certificate that lists names only in the common name (CN) is rejected for the bare domain.
- Limit the list. A SAN with dozens of arbitrary names makes the certificate file large and the renewal ceremony slow, and any of those names can become a liability when one gets reused.
- The wildcard double standard.
*.example.comin a SAN covers one level only; a SAN that mixes an apex, a wildcard, and a bare internal name is a smell that one per purpose is cleaner.
Renewal and propagation for a SAN is identical to any cert but multiplied by the domain list: if a listed domain's DNS changes, the renewal can fail for the whole certificate. The record types reference keeps the affected names in one view while certificate types positions SAN against single and wildcard for the decision.