Wildcard vs SAN certificates

Most sites answer to more than one name. There is the apex domain (example.com), its www twin, perhaps shop, mail, api and a scatter of others. Browsers check the exact name in the address bar against the names on the certificate — so every name a visitor can use must be covered, or they meet NET::ERR_CERT_COMMON_NAME_INVALID instead of your site. You have two tools for covering several names with one certificate: wildcards and SAN lists. They are often confused, and the differences bite.

First, what every modern certificate has: SANs

The Subject Alternative Name (SAN) extension is simply the list of names a certificate covers. It is not a premium feature — every publicly trusted certificate issued today carries a SAN list, and it is the only place browsers look; the older Common Name field is ignored. Even a single-name certificate has a SAN list with one entry. So the real question is not “SAN or not?” but what goes in the list: several specific names, a wildcard entry, or a mixture.

Wildcard certificates: *.example.com

A wildcard entry uses * as the leftmost label, and matches exactly one label at that position. *.example.com covers:

• www.example.com, shop.example.com, anything.example.com — including subdomains that do not exist yet.

It does not cover:

• example.com itself — the apex has no label where the * is. This is the classic wildcard surprise, which is why wildcard certificates are almost always issued with two SAN entries: *.example.com and example.com.
• a.b.example.com — the wildcard matches one label, not two. Deeper levels need their own certificate or a deeper wildcard (*.b.example.com).
• Partial labels — sh*.example.com style patterns are not allowed in practice.

Wildcards shine when subdomains are numerous or dynamic — customer subdomains, per-environment hostnames, anything provisioned on the fly. One certificate, one renewal, no re-issuing every time a subdomain appears. Two costs come with that convenience. First, issuance requires DNS validation: under ACME, wildcards are only issued via the DNS-01 challenge, so your ACME client needs API access to your DNS zone. Second, the private key becomes master key to every subdomain — deploy the same wildcard certificate to many servers and a compromise of any one of them lets an attacker impersonate all of *.example.com. Scope it thoughtfully.

SAN (multi-domain) certificates

A “SAN certificate” — vendors also say multi-domain or UCC — is one whose SAN list simply enumerates several specific names, and they do not need to be related at all:

example.com
www.example.com
example.co.uk
app.example.io

That cross-domain ability is the headline: a wildcard can only ever cover one domain’s subdomains, while a SAN list can span entirely different domains — ideal for consolidating a handful of country domains or product sites onto one certificate and one renewal. Limits are generous (Let’s Encrypt allows 100 names per certificate; commercial CAs similar).

The trade-offs mirror the wildcard’s. Every name is fixed at issuance: adding or removing a name means re-issuing the certificate (cheap and automatic under ACME, slower and sometimes chargeable with manual paid certificates). The list is also public — anyone inspecting the certificate, or the Certificate Transparency logs, sees every name on it, which can leak internal hostnames or reveal which brands share infrastructure. And as with wildcards, unrelated sites sharing a certificate share its private key and its fate.

Mixing both

SAN entries can themselves be wildcards, so one certificate can read example.com, *.example.com, example.org, *.example.org. Large multi-brand setups and CDN-managed certificates use exactly this shape. If you check such a site with our SSL checker, Tech mode shows the full SAN list — a quick way to see how a provider has structured coverage.

How to choose

• One site, two names (example.com + www): a plain certificate with both SANs. This is what ACME clients and hosting panels do by default.
• Many or unpredictable subdomains of one domain: wildcard (plus the apex as a second SAN). Accept the DNS-01 requirement and guard the key.
• A fixed set of names, possibly across domains: SAN certificate. One renewal, explicit coverage, nothing matches by accident.
• Sprawling estates: mix strategies per system rather than pursuing one certificate to rule them all — smaller blast radius when a key or renewal fails, a lesson that pairs well with automating renewal.

Price is barely a factor any more: Let’s Encrypt issues single-name, SAN and wildcard certificates free. Paid CAs still charge meaningful premiums for wildcards — worth paying only if you specifically need their validation levels or support terms.

Check what a certificate actually covers

Coverage problems are invisible until someone uses the uncovered name. Run each name your users actually visit — apex, www, app subdomains — through the SSL checker: the verdict tells you whether that exact name is covered, and Tech mode lists every SAN so you can see what else the certificate carries. If a name fails, common SSL errors explained covers what your visitors are currently seeing.