Wildcard Certificate vs SAN: Choosing the Right Coverage for Your Domains

The wildcard certificate vs SAN question comes up every time an estate outgrows a single hostname: do you issue one *.example.com certificate and cover everything, or enumerate hostnames as Subject Alternative Names on one or more certificates? Both are mainstream, both are free via ACME, and both have sharp edges that only show up later — usually around key compromise, multi-level subdomains, or the day you try to automate wildcard renewal and discover it needs DNS API access. Here's the actual trade-off.

Definitions, briefly

• A wildcard certificate has a name like *.example.com and matches any single label in that position: app.example.com, api.example.com, anything.example.com.
• A SAN certificate (technically: every modern certificate is a SAN certificate; here we mean a multi-domain one) explicitly lists each hostname it covers: example.com, www.example.com, api.example.com, and so on. Let's Encrypt allows up to 100 SANs per certificate.
• The two combine: a common pattern is a certificate with SANs example.com and *.example.com, because the wildcard alone does not cover the bare apex domain.

The trade-offs that actually matter

Three of these deserve expansion.

Blast radius: the strongest argument against wildcards

A certificate is only as safe as its private key, and wildcard keys have a habit of multiplying. Because one cert covers everything, it gets copied to the CDN, the load balancer, three app servers, a staging box, and a developer laptop "temporarily". Every copy is a place the key can leak from — and a leaked *.example.com key lets an attacker convincingly impersonate any subdomain: your SSO portal, your API, your webmail. With per-service SAN certificates, compromising the marketing site's key gets the attacker the marketing site.

If you do run wildcards, treat the key like the crown jewels: minimise the systems holding it, and prefer issuing separate wildcard certs (distinct keys) per environment rather than rsyncing one PEM around.

Coverage: wildcards match one level only

*.example.com covers api.example.com but not v2.api.example.com and not example.com itself. The single-level rule surprises people constantly:

• Multi-level naming schemes (region.service.example.com) need either a wildcard per level (*.service.example.com) or enumerated SANs.
• The apex must be added as an explicit SAN alongside the wildcard.
• A wildcard at one level provides no coverage for deeper levels — there is no *.*.example.com.

If your hostname scheme is flat and genuinely dynamic — per-customer subdomains on a SaaS, preview deployments, multi-tenant vhosts — that's the textbook wildcard use case, and enumerating SANs is impractical. If your hostnames are a known, slowly-changing list, enumeration is not actually painful under ACME automation.

Automation: wildcards require DNS-01

Under ACME (Let's Encrypt and others), wildcard certificates can only be validated with the DNS-01 challenge: proving control by publishing a TXT record under _acme-challenge.example.com. That means your renewal automation needs API credentials for your DNS provider — which brings real operational baggage:

• A live DNS API token sitting on whatever box renews the cert (scope it as tightly as your provider allows).
• A dependency on the DNS provider's API uptime and on the token not being rotated, expired or revoked — one of the most common silent renewal-failure causes we see.
• No DNS API at your provider? Wildcard automation effectively forces a provider change or a delegation trick (CNAME _acme-challenge to a zone you can automate).

SAN certs for ordinary hostnames can use HTTP-01, which needs nothing but port 80 reachability. You can verify what any existing cert actually covers in one line:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName
# X509v3 Subject Alternative Name:
#     DNS:example.com, DNS:*.example.com

Cost considerations

With Let's Encrypt and other ACME CAs, both options are free, so cost only enters the picture with commercial CAs — where wildcards typically carry a significant premium and multi-domain certs are often priced per SAN. The honest framing for most teams in 2026: pay for a certificate only when you need something ACME can't give you (organisation validation, certain compliance checkboxes, very long support guarantees from a vendor). Otherwise the "cost" comparison is really an operational cost comparison: DNS-01 plumbing and key custody for wildcards, versus reissue-on-change and more renewal events for SAN certs.

When each fits

Choose a wildcard when: subdomains are dynamic or numerous (per-tenant SaaS subdomains, preview environments), they all terminate TLS at one controlled point (a load balancer or CDN, so the key lives in one place), and you have solid DNS API automation.

Choose SAN/per-service certificates when: the hostname list is finite and known, services terminate TLS independently, you want compromise contained per service, or you can't (or don't want to) wire DNS API credentials into renewal.

Mix them when sensible: a wildcard at the edge for tenant subdomains, individual certs for crown-jewel services like SSO. There's no purity prize.

Whichever you choose, the operational risk concentrates in the same place: renewals that silently fail and certificates serving past their welcome. DomainOps monitors every certificate's expiry across your domain portfolio — wildcards, SANs and the apex — and alerts you by email, Slack or Pushover before anything lapses; see how domains are organised into portfolios.