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.
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.