Wildcard vs SAN certificates: which one should you buy
Every certificate answers one question for the client: which hostnames am I valid for. Wildcard and SAN certificates are two different ways of answering it for more than one name. They are frequently presented as alternatives when they are closer to complements, and the choice mostly comes down to whether your names share a parent domain and how much you care about blast radius.
You can read the names on any certificate, wildcard or otherwise, by pasting it into the SSL Decoder, or by checking a live host with the SSL Checker.
What a wildcard actually covers
A wildcard certificate lists a name like *.example.com and matches exactly one label in that position:
| Hostname | *.example.com |
|---|---|
www.example.com | Covered |
api.example.com | Covered |
staging.example.com | Covered |
example.com | Not covered |
api.eu.example.com | Not covered |
www.example.net | Not covered |
Two of those rows cause nearly all wildcard confusion.
The apex domain is not covered by its own wildcard. *.example.com does not match example.com, because the wildcard requires something in the leftmost label. Every CA handles this by adding the bare domain as a second SAN entry, which is why a wildcard certificate in practice always lists two names. If yours does not, visitors to the apex get a name mismatch error.
Sub subdomains are not covered either. One wildcard covers one level. Covering api.eu.example.com requires a second wildcard for *.eu.example.com, and multi level wildcards like *.*.example.com are not permitted by the specification and will not be issued.
What a SAN certificate is
SAN stands for subject alternative name, and strictly speaking every modern certificate is a SAN certificate: clients ignore the legacy common name field entirely and match only against the SAN extension. When a vendor sells a "SAN certificate" or "multi domain certificate" they mean one carrying several explicit names, which can be unrelated:
DNS:example.com
DNS:www.example.com
DNS:example.net
DNS:api.partner.io
That is the capability a wildcard does not have. A wildcard is bound to one parent domain; a SAN list can span entirely different registrable domains, which matters if you run several brands, a legacy domain that still needs to work, or country specific variants.
The two combine freely. A single certificate can carry example.com, *.example.com, and *.eu.example.com at once, and that is the usual shape of a real production certificate.
Choosing between them
Choose a wildcard when subdomains are created often and unpredictably, particularly for multi tenant products where every customer gets customer.example.com. Issuing a certificate per tenant at signup is possible but adds a moving part to onboarding; a wildcard covers all of them the moment DNS resolves.
Choose an explicit SAN list when the set of names is known and stable, or spans multiple domains, or when you want the security property below.
The security property. A wildcard means one private key valid for every subdomain of your domain. If the server holding it is compromised, the attacker can impersonate every host under that parent, including internal ones the wildcard was never deployed to. An explicit SAN list limits exposure to the names actually on it. This is why wildcards are best kept off shared or lower trust machines, and why some organizations forbid them on anything internet facing.
There is a related operational cost: a wildcard usually lives on many servers, so rotating the key after an incident means touching all of them at once. Per host certificates rotate independently.
Cost is no longer the deciding factor. Free ACME issuance covers both shapes, wildcards included, though a wildcard requires DNS based domain validation rather than the simpler HTTP challenge, since there is no single host to serve a challenge file from. That means your DNS provider needs an API your ACME client supports. The validation methods are covered in domain control validation explained, and you can confirm the relevant records with the DNS Lookup tool.
Details that catch people out
Validation level is independent. Domain validated, organization validated, and extended validation describe how much the CA verified about you, not how many names the certificate covers. A DV wildcard and an OV wildcard encrypt identically; browsers stopped showing any visible difference for EV years ago.
Wildcards appear in CT logs as *.example.com, which paradoxically leaks less than explicit names. A SAN list publishes every hostname on it, including internal-admin.example.com, to a public log the moment it is issued. If you are relying on obscure internal hostnames staying unknown, an explicit SAN certificate ends that; check what is already public for your domain with the CT log lookup.
Adding a name means reissuing. A SAN list is fixed at issuance. Each new hostname requires a new certificate and a redeployment, which is the operational argument for wildcards when names change frequently.
Some clients still handle wildcards oddly. Older Java versions, some embedded devices, and certain pinning implementations treat wildcard matching inconsistently. If you are serving non browser clients, test rather than assume.
Confirming what you have
Whatever you deploy, verify the names as a client reads them rather than as the order form described them. Decode the deployed certificate with the SSL Decoder and check the SAN list covers every hostname in use, apex included. Then keep an eye on expiry across all of them with the bulk SSL checker, since one wildcard expiring takes down every subdomain simultaneously, which is the other side of the convenience.