Wildcard vs SAN certs: when each makes sense

Most teams hit the wildcard-vs-SAN question the first time they need to host more than one or two subdomains over TLS. The answer is rarely "one is better than the other". It is "they have different operational profiles, and the right choice depends on how your subdomain inventory grows and who controls each one".

Definitions

Wildcard certificate. Subject (or Subject Alternative Name) is *.example.com. Covers any single-label subdomain: www.example.com, api.example.com, blog.example.com. Does not cover the apex example.com — you need example.com as a separate SAN entry on the same cert. Does not cover two-level subdomains: v2.api.example.com is not matched.

SAN certificate. Subject Alternative Names is an explicit list: example.com, www.example.com, api.example.com, blog.example.com. Only those names are covered. New subdomains require a new cert (or re-issuance with the new name added).

The actual differences

The blast radius argument

A leaked wildcard private key gives an attacker a working cert for every subdomain that uses it — including subdomains that the original team didn't even know existed. If internal-api.example.com was set up by a team that forgot to deploy its own cert and is sharing the wildcard via a reverse proxy, that subdomain is now impersonable.

SAN certs limit the leak to the named hosts. Same compromise, smaller surface.

The mitigation for wildcards: rotate the key on every renewal, not just the cert. Many ACME clients reuse the private key across renewals by default — explicitly disable that for wildcards. In certbot: --reuse-key=false. In acme.sh: --always-force-new-domain-key.

The ACME constraint

Wildcards can only be issued via dns-01 ACME challenge. The CA cannot satisfy http-01 for a wildcard because there is no canonical hostname to GET. This means your ACME automation must have programmatic access to the DNS provider's API — Cloudflare token, Route53 IAM role, DigitalOcean PAT, etc. For shops that don't want to grant DNS-write capabilities to a webserver, that is a hard blocker.

SAN certs can use http-01, which only requires that the webserver be able to serve a file. Much lower trust footprint.

Practical decision matrix

• Few stable subdomains, one team controls them all. SAN cert. Issuance is simple, blast radius is bounded, ACME is straightforward.
• Many subdomains being created and destroyed (preview environments, multi-tenant subdomains). Wildcard. The operational cost of re-issuing per addition is too high.
• Compliance/regulatory environment that wants explicit allowlists. SAN. The auditor wants to see the list.
• Multi-tenant SaaS where each tenant gets <tenant>.app.example.com. Wildcard on the app.example.com level, plus SAN certs for the marketing site and apex.
• Legacy commercial CA, paying per cert. Wildcard becomes a budget question. If you have more than ~8 subdomains, wildcard is cheaper. With Let's Encrypt, this is moot.

The hybrid

Modern practice is often a wildcard + an apex SAN on the same cert: example.com and *.example.com. That covers the apex (which the wildcard alone doesn't) and every first-level subdomain. Combine that with separate SAN-style certs for any sensitive single-purpose hostnames (billing.example.com, admin.example.com) so a wildcard compromise does not expose them.

Inspecting

To see what a cert actually covers:

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

The SAN list is also in the SSL panel on dnscheck for any host you probe — see github.com for an example with both apex and subdomain coverage.

References: RFC 6125 (hostname verification rules), Let's Encrypt wildcard FAQ.