Wildcard SSL certificate: what it covers, and wildcard vs SAN

Published November 2, 2026 · about a 7-minute read

"Just get a wildcard, it covers everything." I've heard that a hundred times, and it's wrong in two specific ways that bite people later. A wildcard certificate is genuinely useful — one cert for all your subdomains, no reissuing every time you add a service — but it covers less than most people think, and it concentrates more risk than most people realize. Here's what it actually does, how it compares to a SAN certificate, and how to choose.

What a wildcard actually covers

A wildcard certificate is issued for *.example.com. The * matches any single label in that position, so it secures:

• www.example.com ✅
• app.example.com ✅
• api.example.com, mail.example.com, anything.example.com ✅

One certificate, unlimited direct subdomains. That's the appeal, and for a site that spins up subdomains often, it's a real time-saver. But now the two gaps.

Gap 1: it does not cover the apex

This is the one that catches people. *.example.com does not match example.com itself — the bare apex domain. The wildcard matches a label in front of example.com; the apex has no label there. So if someone visits https://example.com and your cert is a bare wildcard, they get a certificate error. The fix is to list the apex explicitly on the same certificate, which most issuers do for you — you end up with a cert covering both example.com and *.example.com. Just don't assume the wildcard alone has you covered.

Gap 2: it only goes one level deep

*.example.com matches app.example.com but not staging.app.example.com. The wildcard is one level only. Deeper names need their own wildcard (*.app.example.com) or explicit listing. I've watched a perfectly valid wildcard throw errors on a multi-level subdomain and send everyone hunting for a problem that was really just this rule.

Wildcard vs SAN (multi-domain)

The other way to cover multiple names is a SAN certificate — Subject Alternative Name, also sold as "multi-domain." Instead of a wildcard pattern, it lists each name explicitly, and those names can be completely different domains:

And they're not either/or: a SAN certificate's name list can include wildcard entries. A common real-world cert looks like example.com, *.example.com, *.app.example.com all on one SAN list. Pick based on how your names grow: lots of unpredictable subdomains under one domain → wildcard; a fixed set of distinct domains → SAN; both → combine them.

The risk nobody puts on the sales page

A wildcard means one private key secures every subdomain you have. That's convenient right up until that key leaks. If a wildcard key sits on a low-trust box — a marketing microsite, a dev server, a third-party host — and that box is compromised, the attacker can now impersonate every subdomain on your domain, including the ones that matter. The blast radius is your whole namespace.

So I treat wildcards as a convenience with a cost. For ordinary subdomains, fine. For a high-value host — your auth server, your payment flow, your admin panel — I'd lean toward a dedicated certificate with its own key, so a compromise somewhere else can't be turned into a valid cert for it. The broader the certificate, the more careful you have to be about where its key lives.

A practical note on issuing them

If you use Let's Encrypt (or most ACME automation), wildcards have one extra requirement: you can only validate them with the DNS-01 challenge — proving control by publishing a TXT record — not the simpler HTTP-01 file check. That means your issuance automation needs API access to your DNS provider. It's not hard, but it's a different setup than a normal single-host cert, and it's the step people get stuck on when their first wildcard renewal fails.

Whatever you choose, the thing that actually causes outages isn't the cert type — it's a cert that quietly expired or a chain that's missing an intermediate. A wildcard renewing on DNS-01 automation is exactly the kind of cert that fails silently at 2am, because nobody's watching the subdomain it covers. And with certificate lifespans shrinking, renewals happen more often, so there are more chances for one to slip.