← Blog

Wildcard vs SAN certificates — which one do you actually want?

April 22, 2026

By Nick Phillips, Founder

If you're picking a cert for a domain that has more than one hostname under it, you have three plausible options: a wildcard cert (*.example.com), a SAN cert that lists every hostname explicitly, or one cert per hostname. Which is right depends on how your infrastructure is shaped, not on which sounds fanciest.

Here's the honest decision guide.

The three options

1. Wildcard cert. One cert, one wildcard SAN like *.example.com. Matches api.example.com, www.example.com, mail.example.com, every direct subdomain. Does not match example.com itself (you usually need to add it as a separate SAN) and does not match deeper subdomains like staging.api.example.com (a wildcard is one level deep only).

2. Multi-domain (SAN) cert. One cert, multiple explicit SANs: example.com, www.example.com, api.example.com, mail.example.com. You can include hostnames from completely different domains, too — example.com and another-brand.com on the same cert.

3. Per-host certs. One cert per hostname, period. With ACME and automated renewal this is much more tractable than it used to be.

For most teams, the right answer is per-host or SAN. Wildcards are popular for the wrong reasons.

The case for per-host certs

The defaults-are-best answer. If you're using Let's Encrypt or a similar ACME CA, issuing per-host certs is fully automated. Each cert is independent: a renewal failure on one doesn't affect the others, the blast radius of a key compromise is exactly one hostname, and there's no operational coordination needed when adding or removing hosts.

The historical reason people avoided per-host certs was either cost (multi-domain certs from commercial CAs charged per SAN) or operational pain (you had to manually renew dozens of certs). Both reasons are obsolete today: ACME made issuance free, and automation makes the per-host count irrelevant.

Use per-host certs when: you control deployment, you're using ACME, and your hostnames are reasonably static (not a multi-tenant SaaS spinning up hostnames on demand).

The case for SAN certs

A SAN cert is the right answer when you want a small number of related hostnames to share a single cert because they share a single TLS termination point and you'd rather configure one cert than many.

Common patterns:

• A load balancer fronting example.com and www.example.com and the app server expects exactly one cert.
• A static site CDN where the apex and www are both served, plus a cdn.example.com for assets.
• A small B2B SaaS that lists 5–10 known customer-facing hostnames and wants them on one cert for config simplicity.

SAN certs have one operationally annoying property: adding a hostname requires re-issuing the cert. If you have a cert for a.example.com and b.example.com and you want to add c.example.com, you re-issue with all three SANs and replace the old cert. With ACME this is fine; with manual CAs it's friction.

Use SAN certs when: you have a stable list of hostnames, you want one cert per termination point, and you'd rather re-issue occasionally than manage many certs.

The case for wildcards (and why it's weaker than people think)

Wildcards are popular because they sound like they solve the "many subdomains" problem elegantly. They do, with some real costs that don't show up until later.

The good case for a wildcard:

• You're a multi-tenant SaaS where customer hostnames are created dynamically (acme.yourapp.com, globex.yourapp.com, ...) and you can't pre-list them in a SAN.
• You can't use ACME's per-host issuance for those subdomains because your DNS or hosting setup makes it impractical at scale.
• You're issuing certs for hostnames you don't fully control (internal subdomains spun up by other teams) and pre-listing them isn't realistic.

The first case is the legitimate one. If your product spawns customer subdomains, wildcards are genuinely the only sane option.

The costs of a wildcard, which proponents understate:

One key for everything. A wildcard cert is one keypair. If that private key is compromised, every subdomain is compromised. With per-host certs, a key leak on one server affects only that hostname.

DNS-01 challenges required. Public wildcards can only be issued via DNS-01 challenges (the CA requires you to prove control of the parent domain by setting a DNS record). HTTP-01 doesn't work for wildcards. That means your renewal automation has to have credentials for your DNS provider — a non-trivial security surface. Per-host certs can use the lighter-touch HTTP-01.

Less observability. When a key leaks for a wildcard, you may not notice which hostname leaked it, because the same cert is everywhere. Per-host certs give you natural compartmentalization.

Browser/CT log treatment. Some browsers and certificate transparency monitors treat wildcards with marginally more scrutiny. This isn't a real operational issue but it's worth knowing.

Use wildcards only when: dynamic subdomain provisioning genuinely makes per-host issuance infeasible. Not because they sound convenient.

The wildcard-plus-apex problem

A subtle thing that catches people: *.example.com does not cover example.com. The wildcard matches one label, and example.com has zero labels in the position where the wildcard goes. If you want both, you need two SANs on the same cert:

DNS:*.example.com, DNS:example.com

Every CA supports this — it's the "wildcard + apex" pattern and it's the right shape for a wildcard deployment. But if you forget the apex, your bare-domain visitors will get the cert error and you'll only notice when a customer types example.com instead of www.example.com.

The cost angle (mostly historical)

Commercial CAs used to price these very differently — wildcards at 5–10× the cost of single-host certs, multi-domain certs at a per-SAN markup. With ACME and Let's Encrypt issuing all three for free, the pricing argument is mostly moot.

The exception is if you're stuck on a commercial CA for compliance or EV reasons (which we'd argue you probably aren't, since EV has been visually de-emphasized in browsers since 2019). In that case, the wildcard's per-cert price tag is still cheaper than buying twenty single-host certs, even with the security trade-offs.

A quick flowchart

• Multi-tenant SaaS with dynamic customer hostnames? Wildcard (this is the case wildcards are made for).
• Stable list of 2–10 hostnames at a single termination point? SAN cert.
• Many hostnames, automated infrastructure, ACME available? Per-host certs.
• Stuck on a commercial CA and the bill matters? Wildcard + apex, accept the key-compromise trade-off knowingly.
• You're not sure? Per-host certs. The default is the right default.

What this has to do with monitoring

Whichever shape you pick, the cert is going to expire and you're going to need to know about it before it does. Monitoring shape differs slightly per cert type:

• Per-host certs mean a longer list of things to monitor, but each is independent and any one failure is contained.
• SAN certs mean one monitor per cert (per termination point) — the cert expiring takes down every listed hostname at once, so the blast radius of one missed renewal is bigger.
• Wildcards mean one monitor for the wildcard, but the failure mode is "every subdomain dies at once," which makes the monitoring more critical, not less.

The actual notAfter field is on the cert itself in every case, and a daily external check reads it the same way. Our free SSL checker handles all three — paste any hostname, and it'll report on the cert that's actually being served to that name. For ongoing monitoring across however many hostnames you have, signup is here and the per-monitor limit on the free tier is generous enough to cover most real infrastructures.

The shape of your certs is a deployment decision. The need to watch their expiration dates is the same regardless.