When you need to secure more than one hostname with TLS, two products keep coming up: the wildcard certificate and the multi-domain certificate (often labelled SAN or UCC). They sound interchangeable, but they answer two different questions. A wildcard asks "how do I cover every subdomain of one domain?" A multi-domain certificate asks "how do I cover a list of separate names — possibly across unrelated domains — on a single certificate?" Pick the wrong one and you either over-pay, leave hosts unprotected, or end up reissuing every time you add a service. This guide compares them head to head so you can choose with confidence.
The short answer
Choose a wildcard when you have many subdomains under a single domain (and expect to add more): one *.example.com covers them all. Choose a multi-domain (SAN) certificate when you need to protect several distinct domains — like example.com and example.net — on one certificate. Need both at once? A multi-domain wildcard can list wildcard and named entries together.
At a glance
Before the detail, here is the quick mental model. The two certificates differ mainly in what shape of coverage they give you, not in how strongly they encrypt — a connection secured by either is exactly as safe.
Wildcard
One base domain plus unlimited first-level subdomains, written as a single *.example.com entry. Add a new subdomain tomorrow and it's already covered — no reissue.
Multi-domain (SAN)
A list of explicitly named hostnames — which may live on completely different domains — bundled on one certificate. Every name is spelled out; adding one means reissuing with the new SAN.
What a wildcard certificate covers
A wildcard certificate uses an asterisk in place of the subdomain label: *.example.com. That single entry matches any first-level subdomain of example.com — so the same certificate secures www.example.com, mail.example.com, shop.example.com, and any subdomain you spin up later, without buying or reissuing anything.
There are two details worth pinning down. First, the asterisk only replaces one label: *.example.com covers blog.example.com but not app.staging.example.com, which is two levels deep. Second, a wildcard does not automatically secure the bare root example.com — most CAs add the root as an extra name so both work, but it isn't implied by the asterisk alone.
Wildcards are ideal when you run a growing fleet of subdomains under one brand and don't want to manage a certificate per service. For the full mechanics, see our dedicated wildcard SSL certificate guide.
What a multi-domain (SAN) certificate covers
A multi-domain certificate — also marketed as a SAN or UCC certificate — relies on the Subject Alternative Name field defined in the X.509 standard. Instead of one pattern, it carries a list of specific hostnames, and those names can belong to entirely unrelated domains. A single certificate might cover example.com, www.example.com, example.net, and shop.anotherbrand.com — four different services on one certificate.
The number of SANs you can include is set by your certificate authority, not the protocol. Many CAs allow up to roughly 100–250 names per certificate, and some go higher for an additional fee; the exact ceiling and how many names are bundled in the base price vary by provider. The "UCC" name (Unified Communications Certificate) comes from this format's popularity with Microsoft Exchange and Office Communications deployments, which need several named hosts on one certificate.
Because every name is explicit, a multi-domain certificate gives you precise control over exactly what is covered — and because the names are individually identifiable, this format can be issued at every validation level. Our multi-domain SSL certificate guide goes deeper on SAN limits and configuration.
Side-by-side comparison
The table below lines up the differences that actually drive a buying decision. Neither is "more secure" — the distinctions are about coverage shape, flexibility, validation, and cost.
| Property | Wildcard | Multi-domain (SAN) |
|---|---|---|
| What it secures | One domain + all first-level subdomains | A list of named hosts across one or many domains |
| Different root domains? | No — single base domain only | Yes — that's the whole point |
| Add a new host later | Automatic for first-level subdomains; no reissue | Requires reissuing with the new SAN added |
| Number of names | Unlimited first-level subdomains | Fixed list, capped by your CA |
| Validation levels | DV and OV (no EV) | DV, OV, or EV |
| Typical pricing model | Flat price, unlimited subdomains | Base price + per-SAN add-ons |
| Best for | Many subdomains under one brand | Several separate domains/properties |
Coverage: what each can't do
Most misconfigurations come from assuming a certificate covers a name it doesn't. Here are the edges that trip people up.
Wildcard gaps
- No second-level subdomains —
*.example.comwon't covera.b.example.com. - No other root domains — one base domain per wildcard.
- Root not implied —
example.commust be added as its own name (most CAs do this for you).
Multi-domain gaps
- No open-ended subdomains — each host is listed explicitly, so a new subdomain isn't covered until you reissue.
- SAN count is capped by the issuing CA, not infinite.
- But it can include wildcard SANs to close the first gap — see below.
Validation levels and the EV rule
Both certificate types come in different validation levels — Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) — but with one important asymmetry.
There is no EV wildcard
No publicly trusted CA issues an Extended Validation wildcard certificate. The CA/Browser Forum's EV guidelines require every name in an EV certificate to be individually vetted, which is impossible for an open-ended *.example.com entry that matches names nobody has reviewed. Wildcards are therefore available only at DV and OV. A multi-domain certificate can be EV — because each SAN is a specific, verifiable name — but an EV multi-domain certificate cannot contain any wildcard SAN.
If your decision hinges on displaying verified organization identity, that rules out a pure wildcard. Our guide to OV vs EV explains when the extra vetting is worth it.
Cost and management
The economics flip depending on shape. A wildcard usually carries a single flat price that covers unlimited first-level subdomains — so the more subdomains you run under one domain, the better its value. A multi-domain certificate is typically priced as a base certificate plus a per-name charge for each additional SAN, so the cost scales with how many distinct hosts you add. For a handful of separate domains that's efficient; for dozens of subdomains under a single domain a wildcard almost always wins on price. Confirm the current numbers with your provider, since per-SAN rates and included-name counts differ — see the SSL pricing guide for what drives cost.
Both concentrate risk
A wildcard or multi-domain certificate often protects many services at once, so when it expires they can all fail together. Since March 2026, public TLS certificates are capped at 199 days under CA/Browser Forum Ballot SC-081v3, meaning more frequent renewals — which is why automating renewal matters most for exactly these certificate types.
Can you combine them?
Yes — and for larger estates it's often the right answer. A multi-domain wildcard (sometimes called a wildcard SAN certificate) puts wildcard entries and named entries on the same certificate. One certificate could list *.example.com, *.example.net, and shop.thirdbrand.com together — covering all subdomains of two domains plus one specific host on a third.
It's the most flexible format, but it inherits the trade-offs of both: it's the most expensive option, and because it covers the most ground, a single missed renewal has the widest blast radius. It also can't be EV, since it contains wildcard entries. Reach for it when you genuinely manage several domains and many subdomains; for a single site, a plain wildcard or a small multi-domain certificate is simpler and cheaper.
How to choose
Run your situation through these questions in order and the answer usually falls out:
All your hosts share one domain?
If every name is a subdomain of a single domain and the list will grow, a wildcard is the natural choice — one entry, unlimited first-level subdomains, no reissue when you add the next one.
You need to cover several different domains?
A multi-domain (SAN) certificate is built for this — list each domain and host explicitly on one certificate.
You need verified organization identity (EV)?
That rules out wildcards. Use a multi-domain EV certificate with each name listed — no wildcard SANs allowed.
Both many domains and many subdomains?
A multi-domain wildcard combines both — the most flexible (and most expensive) option.
Still unsure how validation, coverage, and budget intersect for your case? Walk through our which SSL certificate do I need guide, or compare options directly on the wildcard SSL and multi-domain SSL pages.
Frequently Asked Questions
Answers to common questions about certificates and our services.
What is the difference between a wildcard and a multi-domain SSL certificate?
A wildcard certificate secures one base domain and an unlimited number of its first-level subdomains using a single entry written as *.example.com — for example mail.example.com, shop.example.com, and app.example.com. A multi-domain certificate (also called a SAN or UCC certificate) secures a list of distinct, explicitly named hostnames that can belong to completely different domains, such as example.com, example.net, and shop.anotherbrand.com on the same certificate. The simplest way to remember it: a wildcard covers many subdomains under one domain, while a multi-domain covers many separate domains. They solve different problems, and the right choice depends on whether your sites share a single parent domain or span several unrelated ones.
Can I use one certificate for both multiple domains and multiple subdomains?
Yes. A multi-domain certificate can include wildcard entries in its Subject Alternative Name list — this is often called a multi-domain wildcard or wildcard SAN certificate. For example, a single certificate could list *.example.com, *.example.net, and shop.thirdbrand.com together, covering all subdomains of two domains plus one specific host on a third. It is the most flexible option, but also the most expensive and the one that fails the most widely if a renewal is missed, so it suits organizations that genuinely manage many domains and subdomains rather than a single site.
Does a wildcard certificate cover the root domain and nested subdomains?
A wildcard like *.example.com covers every first-level subdomain (www.example.com, blog.example.com) but does not automatically cover the bare root domain example.com unless that exact name is also added — most issuers include the root as an additional SAN so both work. Crucially, a single wildcard does not cover deeper, multi-level subdomains: *.example.com will not secure app.staging.example.com, because that is two levels down. To secure a second level you need a separate wildcard for that level, such as *.staging.example.com, or you list those hosts explicitly.
Is a multi-domain certificate more expensive than a wildcard?
It depends on scale rather than a fixed rule. A wildcard has a flat price that covers unlimited subdomains of one domain, so if you run many subdomains under a single domain it is usually the cheaper route. A multi-domain certificate is typically priced as a base certificate plus a per-SAN cost for each additional hostname, so its total rises with the number of distinct names you add. For a handful of separate domains a multi-domain certificate is economical; for dozens of subdomains under one domain a wildcard almost always costs less. Always confirm current pricing with your provider, since per-SAN models and included-SAN counts vary by CA.
Can I get an EV wildcard certificate?
No. Extended Validation (EV) wildcard certificates are not issued by any publicly trusted certificate authority because the CA/Browser Forum's EV guidelines require each name in an EV certificate to be individually vetted, which is incompatible with a wildcard's open-ended *.example.com entry. Wildcards are therefore available only at the Domain Validation (DV) and Organization Validation (OV) levels. Multi-domain certificates, by contrast, can be issued as DV, OV, or EV, because every SAN in them is a specific, verifiable name — though an EV multi-domain certificate cannot contain any wildcard SAN.
How does the 199-day validity limit affect wildcard and multi-domain certificates?
Both certificate types are subject to the same cap: since March 2026, all publicly trusted TLS certificates are limited to 199 days of validity under CA/Browser Forum Ballot SC-081v3, dropping further in later years. The practical impact is concentration of risk. A wildcard or a multi-domain certificate typically protects many services at once, so a single missed renewal can take all of them offline simultaneously. With shorter lifetimes meaning more frequent renewals, automating issuance and renewal is strongly advisable for either certificate type.
Should I choose a wildcard or multi-domain certificate for a few subdomains?
If those subdomains all sit under one domain and you expect to add more over time, a wildcard is usually the better fit because it covers any future first-level subdomain with no reissue. If you have a small, stable set of names — especially if they span different domains — a multi-domain certificate listing just those hosts is cleaner and lets you keep tighter control over exactly what is covered. For a single domain with only two or three fixed subdomains that will not change, a standard multi-domain (or even a single-name certificate per host) can also work; the wildcard's advantage grows with how many subdomains you have and how often the list changes.
The bottom line
Wildcard and multi-domain certificates aren't competitors so much as answers to two different shapes of problem: a wildcard scales down one domain into its subdomains, while a multi-domain certificate scales across separate names. Match the certificate to your topology — one domain with many subdomains, or many domains side by side — and combine the two only when you truly need both. If you're still mapping it out, start with which SSL certificate you need.