Dr.Who
← blog

Wildcard vs SAN certificate: which one you actually need

· tls · ssl · certificates · wildcard · san

tlssslcertificateswildcardsan

A wildcard certificate secures every host at one level under a domain — *.example.com covers app.example.com and api.example.com — all behind a single key. A SAN (Subject Alternative Name) certificate, also called multi-domain, instead lists each hostname explicitly, and those names can be unrelated domains. The short rule: use a wildcard when you have many subdomains at the same level, use a SAN when you have a fixed set of distinct names, and combine them when you need both an apex and its subdomains.

What a wildcard does — and does not — cover

*.example.com matches exactly one label in that position. So:

  • It covers www.example.com, api.example.com, mail.example.com.
  • It does not cover the apex example.com (no label there).
  • It does not cover nested hosts like a.b.example.com (two labels).

The single-key model is also the blast radius: if the private key behind *.example.com leaks, every subdomain under it is compromised at once. To cover both the apex and its subdomains you list both names:

subjectAltName = DNS:example.com, DNS:*.example.com

That combination — apex plus wildcard — is extremely common and lets one certificate serve example.com and any *.example.com host.

What a SAN certificate does

Modern TLS certificates carry their hostnames in the subjectAltName extension; the legacy Common Name is ignored by browsers. A SAN/multi-domain cert simply enumerates several explicit names, which may be entirely different domains:

subjectAltName = DNS:example.com, DNS:www.example.com, DNS:example.org, DNS:shop.example.net

This is the right tool when you serve a known, relatively static set of distinct hostnames behind one certificate and one termination point. The trade-off is maintenance: adding a new name means reissuing the certificate.

A practical note: SANs are public

Every name in a certificate — wildcard or SAN — is published in Certificate Transparency logs. A SAN cert therefore leaks your exact hostname list to anyone watching CT, which is a quiet form of subdomain enumeration. A wildcard reveals only the pattern *.example.com, not the specific subdomains in use, so it is the more discreet choice when you do not want to advertise individual hostnames.

Which to choose

  • Wildcard — many subdomains at one level, names that change often (spin up tenant-N.example.com freely), or when you want to keep your subdomain list out of CT logs. Accept the shared-key blast radius.
  • SAN — a small, stable set of distinct hostnames, especially across unrelated domains, where explicit per-name control matters more than convenience.
  • Both — apex + wildcard (example.com and *.example.com) on one cert is the standard pattern for a single brand.

Verify which names a deployed certificate actually presents before you decide.

Inspect a certificate's SANs →

Further reading