Guides · Understand your certificate

SAN and wildcard certificates explained: which names does a certificate cover?

Last reviewed by a person on October 4, 2026

When a browser opens https://shop.example.com, it checks that the certificate really lists that name. The list of names is the certificate's Subject Alternative Name (SAN) field. This guide explains what is in it, how wildcards match, and a renewal trap that catches teams who share one certificate across several servers.

What a SAN is

A certificate is issued for one or more names, and every name it covers is listed as a SAN. Modern browsers use the SAN list for hostname verification. The old "Common Name" field is ignored, so a name that is only in the Common Name does not work. The list can hold ordinary names (example.com, www.example.com), wildcards (*.example.com) and sometimes IP addresses.

See what a certificate covers:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext subjectAltName

Or use the SANs checker, which lists every name on the certificate and where each one points in DNS.

Three kinds of certificate

• Single name. One name only. Simple, but example.com and www.example.com are different names, so you usually need both.
• Multi-domain (SAN) certificate. One certificate listing several specific names, even on different domains. Easy to see exactly what it covers.
• Wildcard. Covers every name one level under a domain.

How wildcards match

A wildcard stands for exactly one label, and only at the left:

• *.example.com matches shop.example.com and api.example.com.
• It does not match example.com itself, so when the bare domain is needed too, it is listed next to the wildcard (that is common, not required).
• It does not match a.shop.example.com (two levels). That needs *.shop.example.com.
• It is not a prefix pattern: shop*.example.com is not valid.

With Let's Encrypt and other ACME certificate authorities, a wildcard requires DNS-01 validation (you prove control by publishing a DNS record, not by serving a file), so it suits automated renewal only if your DNS host has an API your certificate tool can use. Commercial authorities may offer other ways to validate a wildcard, such as email to the domain's administrator.

SAN or wildcard?

• A wildcard is convenient but spreads one private key. To use it on several servers you copy the same key to all of them, and every copy is one more place it can leak from. A leaked key works for every name the certificate covers, so sharing it widens the impact of any one leak.
• A wildcard doesn't list the individual names. The certificate's SAN list has *.example.com, not staging.example.com. That helps privacy, but you also lose the clear record of which names were meant to be there, and a forgotten subdomain keeps working under the wildcard.
• Separate certificates per service limit the damage and make ownership clear (the web team renews the website certificate, the mail admin renews the mail one).
• Whatever you choose, keep the list as short as the job needs. Names that nobody uses any more are still on the certificate, and still your responsibility.

The shared-certificate renewal trap

One certificate often lists several names, and those names are not always served from the same place. www may be on your web host, api on a load balancer, mail on a mail server, cdn at a CDN. You renew the certificate for the website and the website is fine. The other services keep presenting the old certificate until someone installs the new one there too, and then one of them expires and breaks.

The warning signs are names on your certificate that resolve to a different address than your main domain, or that do not resolve at all. From outside you can compare DNS, but not tell "another server" from "the same CDN with other addresses", so someone who knows the setup has to decide.

That is what the SANs tab in CertAvert is for: it lists every name on the certificate, shows where each one points in DNS, flags the ones that resolve elsewhere or nowhere, and lets you either acknowledge a name ("I know about this, it is expected") or add it to monitor as its own domain so it gets its own expiry alerts. A name that later changes, or a new one that appears, is flagged again. Monitor a domain with CertAvert to try it.

When a name is missing

If a visitor sees a name-mismatch error, the name they typed is not in the SAN list (or the wrong server answered). See certificate name mismatch: causes and fixes. To find names that exist for your domain that you did not know about, see Certificate Transparency.