Wildcard vs Multi-Domain SAN Certificates: Which Do You Need?

A wildcard certificate covers one domain and one level of its subdomains, automatically, without naming them. A multi-domain or SAN certificate covers an explicit list of hostnames that can span entirely unrelated domains, and adding a name means reissuing. The choice between them comes down to how your hostnames are shaped and how often new ones appear.

This article covers what each type actually covers, the three questions that decide between them, the security trade-off that pushes some organisations away from wildcards regardless of convenience, and the option most comparisons skip, which is that automation has made the whole question smaller than it used to be.

What each type covers

A wildcard certificate uses an asterisk in place of a single label. Issued for *.example.com, it covers api.example.com, shop.example.com, and any other first-level subdomain, including ones that do not exist yet. That last property is the real appeal: a new subdomain is covered the moment it is created, with no reissue and no new certificate.

Two limits define its edges. It matches exactly one label, so _.example.com does not cover test.api.example.com, which needs its own wildcard for _.api.example.com. And it does not cover the bare domain example.com unless that name is added separately, which most certificate authorities do automatically but which is worth verifying rather than assuming. Our post on whether subdomains need their own certificates covers both limits in more detail.

A multi-domain certificate, also called a SAN certificate or a Unified Communications Certificate, takes the opposite approach. Every hostname is listed explicitly in the Subject Alternative Name field, and those names need have nothing to do with each other. A single certificate can carry example.com, shop.example.net, and mail.example.org. Typical products support up to around one hundred names, though anything past roughly twenty-five becomes awkward to administer. The cost of that flexibility is that adding a name requires reissuing the certificate, so a growing list means recurring work.

A third product exists in the middle, the multi-domain wildcard, which carries several wildcards on one certificate, covering _.example.com and _.example.net together. It solves the case where you have subdomain sprawl across multiple domains, and it is priced accordingly.

The three questions that decide it

Work these in order and the answer usually falls out.

First, do all the names share one parent domain? If yes, a wildcard is available to you. If your names span separate registered domains, a wildcard cannot help, because the asterisk only substitutes for a label within one domain. That eliminates half the decision immediately, and it is the question people skip most often.

Second, how deep do the names go? A flat structure under one parent is wildcard territory. A nested structure, where names sit two or three levels down, needs either a wildcard per level or an explicit list. Teams that adopt nested naming after buying a wildcard tend to find this out during a deploy.

Third, how often do new names appear? This is the question that decides the value of a wildcard over a SAN certificate, because it is the only dimension where a wildcard is genuinely and permanently better. A platform that provisions a subdomain per customer creates names continuously, and a wildcard covers each one at the instant of creation. A stable set of six hostnames that changes twice a year gets almost no benefit from that property, and a SAN certificate serves it just as well.

The security trade-off worth taking seriously

Convenience is not the only axis, and the security argument against wildcards is more substantial than it first appears.

A wildcard certificate means one private key, deployed everywhere a covered subdomain is served. If those subdomains run on different servers, managed by different teams, at different trust levels, then a compromise on any one of them is a compromise of the key protecting all of them. The blast radius of a single incident is the entire domain rather than one hostname. This is why some organisations prohibit wildcards outright, and the position is defensible rather than reflexive.

Whichever you deploy, the names a host actually presents are worth reading rather than assuming, which is what an SSL checker reports back from the handshake. Multi-domain certificates are frequently described as more secure for a related reason, which is that the names are locked in at issuance. A wildcard will happily protect a subdomain that an attacker stands up, because the certificate does not know or care which names exist. A SAN certificate covers only names someone deliberately requested, which is a meaningfully smaller surface.

Neither argument is decisive on its own. A wildcard deployed to one tightly controlled server is a very different risk from the same wildcard spread across a dozen hosts of varying provenance. The question to ask is not whether wildcards are safe in the abstract but how many machines that key will end up on, and who controls them.

What automation changed about this question

Most comparisons of these two products were written when certificates were bought individually and installed by hand, and the arithmetic has moved since.

When each certificate cost money and took an afternoon, a wildcard covering forty subdomains was an obvious win. With automated issuance, per-name certificates are free and provisioning is a configuration line, so the administrative saving that made wildcards compelling has largely evaporated. What remains is the genuinely dynamic case, where names are created faster than any provisioning step can follow.

Shortening certificate lifetimes push the same direction. As validity falls toward the 100 day and then 47 day marks, and validation reuse windows shrink alongside them, any certificate strategy that depends on manual steps stops working. That matters here specifically because wildcards require DNS-based validation, since no single host can serve an HTTP challenge for an unlimited set of names. If your DNS provider offers no API, a wildcard makes every renewal a manual task at precisely the moment renewals are becoming more frequent.

So the modern version of the question is narrower than the traditional one. Choose a wildcard when names are genuinely dynamic and DNS automation exists. Choose a SAN certificate when the list is known, stable, or spans multiple domains. Choose individual automated certificates when you have working automation and no strong reason to consolidate, which is more often than the comparison articles suggest.

Common mistakes in choosing between wildcard and SAN certificates

Choosing a wildcard for names across different domains. A wildcard substitutes a label within one domain. Separate registered domains need a SAN certificate or a multi-domain wildcard, and no amount of configuration changes that.

Ignoring the depth of your naming scheme. A wildcard covers one level. Nested names two or three deep need a wildcard per level, which is usually discovered at deploy time rather than at purchase time.

Treating a wildcard as the automatic choice for convenience. It concentrates one private key across every host that serves a covered name. In split-trust environments that is a real and often unacceptable widening of blast radius.

Buying a wildcard without DNS automation. Wildcards require DNS validation. Without an API to create records, every renewal becomes manual work, and renewals are getting more frequent, not less.

Comparing on price rather than on change rate. Automated issuance has made per-name certificates cheap. The remaining advantage of a wildcard is covering names that do not exist yet, so if your names rarely change, you are paying for a property you will not use.

FAQ

What is the difference between a wildcard and a SAN certificate?

A wildcard covers one domain and any first-level subdomain automatically, without listing them. A SAN or multi-domain certificate covers an explicit list of hostnames, which can span unrelated domains, and adding a name requires reissuing.

Does a wildcard certificate cover multiple domains?

No. A standard wildcard applies to one parent domain only. Covering subdomain sprawl across several domains requires a multi-domain wildcard, which carries more than one wildcard entry on a single certificate.

How many domains can a SAN certificate cover?

Typical products support up to around one hundred names, though administration becomes difficult well before that, often past about twenty-five. Every name is fixed at issuance, so changes require a reissue.

Are wildcard certificates less secure?

They concentrate risk rather than being weaker cryptographically. One private key is deployed everywhere a covered subdomain is served, so a compromise on any of those hosts affects the whole domain. A SAN certificate limits exposure to the names explicitly requested.

Closing thought

This decision is usually framed as a product comparison and is better framed as a question about your own naming. How many parent domains you have, how deep the names go, how fast new ones appear, and how many machines will hold the private key are four facts about your infrastructure, and once you have them the certificate type is close to determined. The comparison articles start at the wrong end, which is why the answer so often feels arbitrary.

Whatever you choose, the certificate you picked is not the thing that causes outages. Losing track of what is deployed where is. Odown gives you unlimited SSL monitors on every plan including the twelve dollar tier, checks each host on a daily cycle, and alerts at 30, 10, and 7 days before expiry with custom thresholds available. Because it reads what each hostname actually presents, a wildcard that never reached one of the servers it was supposed to cover shows up as a problem rather than hiding behind a certificate you know you renewed.