Bridge SSL
SAN certificates: how one certificate covers many names
Every HTTPS certificate in service today lists its names in a field called the subject alternative name, or SAN, and browsers read only that field. One certificate can therefore cover several unrelated hostnames, several domains, or a mixture of specific names and wildcards.
The term "SAN certificate" usually means one covering multiple names, but the field itself is universal: even a certificate for a single name uses it.
- Required in
- every publicly trusted server certificate: at least one dNSName or IP address entry, each validated by the authority (Baseline Requirements §7.1.2.7.12) [2]
- Common name
- not recommended; if present, it must repeat one entry of the SAN list (Baseline Requirements §7.1.4.3) [2]
- Browsers
- Chrome stopped matching the common name in Chrome 58 [3]; RFC 9525 says it must not identify a service [4]
- Names per certificate
- capped by the authority and its certificate profile, not by the standard; the figure is in the authority's own documentation [5]
The field that replaced the common name
Certificates once carried their primary hostname in a field called the common name, and that is where clients looked.
That field was never designed to hold a hostname. It is a general-purpose label, and using it for names was a convention that outlived its usefulness once certificates needed to cover more than one. The subject alternative name field was introduced for this, and clients moved to reading it. RFC 2818, which defined HTTP over TLS, already called the common name deprecated and told clients to use the DNS names in the SAN whenever they are present [6].
The practical position today is unambiguous: browsers use the alternative name list and ignore the common name entirely. A hostname present only in the common name is not covered, no matter how correct the certificate looks in a viewer that displays that field prominently.
This catches people inspecting an old certificate, or generating a signing request that fills the common name and omits the name list. The result is a certificate that appears to name your site and does not cover it, producing a name mismatch error, ERR_CERT_COMMON_NAME_INVALID in Chrome [7].
What a multi-name certificate can hold
Several hostnames on one domain, several separate domains, and wildcard entries alongside specific names can all appear in the same certificate, which makes the list more flexible than most people use. Nothing requires the names to be related, and a client accepts the certificate when any one listed name matches the hostname it asked for [6].
Two constraints apply in practice. Each SSL certification authority sets a maximum number of names per certificate, and all names in one certificate are validated together, so adding a name means demonstrating control of it before the certificate can be issued or reissued.
That second point has an operational consequence: one certificate covering names across several teams or systems means every reissue requires all of them to be validatable at that moment.
Name limits per authority
The standard sets no number. Each certification authority sets its own maximum for the SAN list, sometimes a different one for each certificate profile it offers, and it can change that figure. Read the current limit in your authority's documentation before planning a long list; Let's Encrypt, for example, states it per profile [5].
The same documentation shows a second difference: some profiles issue certificates with no common name at all [5]. A script or monitor that still reads that field then finds an empty value.
SAN versus wildcard
A SAN certificate and a wildcard certificate both cover multiple names. They differ in what happens when the set changes, which is the criterion that decides most cases.
| Criterion | Explicit name list | Wildcard |
|---|---|---|
| New name appears | reissue required | already covered |
| Names across several domains | supported | not possible |
| Names at different depths | supported | one level each |
| Key exposure | one key for the listed names | one key for every name at that level |
| Visibility of names | all listed names are public | individual names not disclosed |
| Revocation blast radius | the listed names | everything at that level |
Read the table as two questions rather than six.
Does the set of names change without warning?
If yes, a wildcard removes issuance from the path of creating a subdomain, which is its whole value. If no, an explicit list costs nothing extra and keeps control finer.
Do the names sit at different depths or on different domains?
If yes, a wildcard cannot do it and the list is the only option, possibly combined with wildcards as entries.
Every name in an explicit list is published in the certificate and is therefore public, and certificates are widely logged and searchable. A wildcard discloses only that the level exists. Where internal-sounding hostnames should not be advertised, that difference is real, though weak on its own. What a wildcard costs in return is on wildcard certificates.
Combining both
One certificate can list example.com, www.example.com, and *.example.com together in its subject alternative name. The bare domain and the www form are covered explicitly, every one-level subdomain is covered by the wildcard, and deeper names are added as explicit entries when they appear.
That combination handles the www and apex problem, the unpredictable subdomain problem, and the occasional deep name, in one certificate. It is the default worth asking for unless a reason exists to split.
The reissue problem
Adding a name means reissuing the whole certificate. That reissue is a new certificate covering the extended list, and it has to be installed everywhere the old one was, together with the intermediate chain certificates issued with it. On one server that is a minor task; across several servers, a load balancer, and a set of application instances, it is a coordinated change for the sake of one new hostname.
Two habits reduce the friction.
Group names by how often they change rather than by who owns them.
A certificate covering stable public names and a separate arrangement for volatile ones means the frequent changes touch only the volatile certificate.
Decide the boundary before it hurts.
A certificate accumulating names from several teams eventually requires all of those teams to be available whenever any of them needs a change, which is a coordination cost nobody chose deliberately.
Neither habit is about certificates specifically. They are about not letting one artefact become a shared dependency for parties who have no reason to be coupled.
What to put in the request
The signing request declares the names, and the rule follows from everything above: put every name in the alternative name list, including the one you also place in the common name.
Tools differ in whether they do this automatically. Where a request is generated by hand, the omission is silent and the consequence appears only after issuance. Details are on certificate signing requests.
Check the request's name list before submitting: a name left out is found only after issuance, and correcting it means going through issuance again.
Once the certificate arrives, two OpenSSL options answer the same question from the other side [8]. The first prints the SAN list; the second says whether one particular name is covered.
openssl x509 -in cert.pem -noout -ext subjectAltName
openssl x509 -in cert.pem -noout -checkhost www.example.comOn a live site the same list sits in the browser's certificate viewer; the steps are on checking certificates in Chrome.
FAQ
What is a SAN SSL certificate?
A certificate whose subject alternative name field lists more than one hostname, so a single certificate and key serve all of them. The term describes ordinary practice rather than a product tier: the field is where covered names live in every certificate issued today.
Is the common name still used?
Not for deciding what a certificate covers. Browsers read the alternative name list and disregard the common name entirely, which means a hostname present only in the common name is not covered at all, however correct the certificate looks when you inspect it. Some certificates no longer carry one. [5]
Can one certificate cover different domains?
Yes. Nothing requires the listed names to share a domain, so unrelated sites can be covered by one certificate, subject to whatever limit the authority places on the count. Whether that is wise is a separate question from whether it is possible.
Should I use a SAN list or a wildcard?
A list when the set of names is known and stable, or spans several domains and depths, since each name is then explicit and replaceable. A wildcard when subdomains appear without warning at one level, which is the situation a list cannot keep up with.
Can I mix wildcards and specific names?
Yes, and for most sites the mixture is the right answer: the bare domain and the www form listed explicitly, plus a wildcard covering the level below. That single certificate then handles both the names you know about and the ones nobody has created yet.
Do the names in my certificate become public?
Yes. Issued certificates are published to public logs that anyone can search, so every explicitly listed hostname becomes discoverable, including internal-sounding ones. A wildcard is the exception in this respect, since it reveals the level rather than the individual names.
Sources
RFC 5280, Internet X.509 PKI Certificate and CRL Profile, §4.2.1.6 Subject Alternative Name.
CA/Browser Forum Baseline Requirements, version 2.3.1, §7.1.2.7.12 and §7.1.4.3.
Deprecations and Removals in Chrome 58, Chrome for Developers: removal of commonName matching.
RFC 9525, Service Identity in TLS, §2; obsoletes RFC 6125.
Let's Encrypt: Profiles: names per certificate and common name, per profile.
RFC 2818, HTTP Over TLS, §3.1 Server Identity.
Chromium source, net/base/net_error_list.h: CERT_COMMON_NAME_INVALID, error -200.
OpenSSL 3.0 manual, openssl-x509: options -ext and -checkhost.