Wildcard vs SAN Certificates: Choosing the Right One - Blog

You need certificates for more than one hostname, and there are two shapes to reach for. A wildcard certificate carries a single *.example.com entry and covers subdomains you have not even created yet. A multi-SAN certificate names each host you want to secure, one by one. Both are routine and supported everywhere. The interesting differences show up in three places: what a wildcard actually matches, what leaks when the key does, and what your hostnames look like to anyone reading public logs. On all three, named certificates are the safer default, and the wildcard earns its place only in a couple of specific situations.

What "Multi-SAN" and "Wildcard" Actually Mean

Both models live in the same place: the Subject Alternative Name extension. Under the hood a wildcard is a single SAN entry whose left-most label is a *, the same kind of certificate as any other, expressed differently. So the real comparison is one SAN entry with a wildcard against several SAN entries with explicit names.

Here is a named certificate covering four hosts, trimmed to the parts that matter:

$ openssl x509 -in san.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=example.com
        Validity
            Not Before: Jul 14 22:38:06 2026 GMT
            Not After : Jan 30 22:38:06 2027 GMT
        Subject: CN=example.com
        ...
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com, DNS:api.example.com, DNS:shop.example.com

And here is the wildcard equivalent, one entry doing the work of many:

$ openssl x509 -in wildcard.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name:
    DNS:*.example.com

The CN field still shows up in older tooling, but browsers and libraries have ignored it for name matching for years. The SAN list is the certificate's identity. If a host is not in there, in one form or another, the certificate does not vouch for it.

Issuing Each One

For a real certificate authority you send a CSR, and the SAN list has to be baked into that request. The repeatable way is a small config file you keep in version control:

# san.cnf
[req]
distinguished_name = dn
req_extensions     = v3_req
prompt             = no

[dn]
CN = example.com

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.com
DNS.4 = shop.example.com

openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.key -out example.csr -config san.cnf

For a quick self-signed cert to test something locally, -addext skips the file entirely:

openssl req -x509 -newkey rsa:2048 -nodes -days 200 \
    -keyout san.key -out san.pem \
    -subj "/CN=example.com" \
    -addext "subjectAltName = DNS:example.com, DNS:www.example.com, DNS:api.example.com, DNS:shop.example.com"

A wildcard is the same command with DNS:*.example.com in the SAN. The -days 200 mirrors what a public CA would issue you today. openssl will sign a self-signed certificate for as long as you ask, but the ceiling for a publicly trusted certificate dropped to 200 days on 2026-03-15 under CA/Browser Forum ballot SC-081v3, and it falls again to 100 days on 2027-03-15 and 47 days on 2029-03-15. Public CAs reject a longer request, and the shrinking window is why the renewal row below matters more every year.

The Rule Everyone Gets Wrong

This is the one that causes outages. A wildcard matches exactly one label. *.example.com covers www.example.com, and it does not cover a.b.example.com, and it does not cover the bare example.com. People deploy a wildcard, assume it blankets the whole tree, and then a nested host or the apex serves a certificate error the moment traffic hits it.

You do not have to take that on faith. Point openssl's own hostname check at a wildcard certificate and watch it enforce the rule:

$ for h in www.example.com a.b.example.com example.com; do
      echo "== $h"
      openssl verify -CAfile wildcard.pem -verify_hostname "$h" wildcard.pem
  done
== www.example.com
wildcard.pem: OK
== a.b.example.com
CN=example.com
error 62 at 0 depth lookup: hostname mismatch
error wildcard.pem: verification failed
== example.com
CN=example.com
error 62 at 0 depth lookup: hostname mismatch
error wildcard.pem: verification failed

That behavior comes straight from the specification. RFC 9525, which replaced RFC 6125 in 2023, permits a wildcard only as the complete content of the left-most label, and says it "can only match one label in a reference identifier." So *.example.com covers foo.example.com, and it leaves both bar.foo.example.com and the bare example.com uncovered. If you run deeper subdomains or need the apex covered, name them explicitly, either as extra SAN entries or as a separate certificate. A wildcard alone will leave them exposed.

Blast Radius If the Key Leaks

A wildcard is one private key that is valid for every subdomain, including ones nobody has created. To be useful it usually gets copied onto every server that answers for any of those names, and each copy is another place it can walk out the door. Whoever holds that key can present a trusted certificate for login.example.com, internal-admin.example.com, or any name they invent under the domain. One key, and the whole namespace is impersonable.

A named certificate contains the damage. The key is valid only for the hosts written into its SAN list, so a leak exposes those and stops there. That lets you draw the certificate boundaries along your trust boundaries: the key on a public marketing site never has to be the same key that fronts a customer data API. When the sensitivities differ, the keys should differ too, and only named certificates give you that separation cleanly.

What Certificate Transparency Publishes

Every certificate a public CA issues is logged to Certificate Transparency, and those logs are open to anyone. A CT log search such as crt.sh will show you the full SAN list of everything issued for your domain. That cuts differently for the two models.

A multi-SAN certificate publishes every name it carries. Issue one for example.com, vpn.example.com, and jenkins-staging.example.com, and all three names are now public and searchable the instant the certificate is logged, whether or not those hosts are meant to be discoverable. Attackers read CT logs precisely to enumerate a target's infrastructure.

A wildcard publishes only *.example.com. The specific subdomains behind it never appear in the certificate, so CT never learns them. That is a genuine reconnaissance advantage, and it is the strongest argument in the wildcard's favor: it keeps your internal hostnames out of a public index. Weigh it against the blast radius, because you are trading name privacy for key concentration.

Wildcard vs Multi-SAN, Side by Side

	Wildcard (`*.example.com`)	Multi-SAN (named hosts)
What it covers	Any single label under the domain, including hosts that do not exist yet	Only the exact names in the SAN list
Matching depth	One label only: `www` yes, `a.b` no, bare apex no	Exact per name; nothing implicit
Blast radius if the key leaks	Every current and future subdomain is impersonable	Limited to the named hosts on that certificate
Per-host issuance	None; one issuance covers the fleet	Reissue to add or remove a name
Hostnames in CT logs	Only `*.example.com` is public	Every name is published and searchable
Renewal / rotation	One certificate, but it sits on every server that serves the domain	More certificates, each scoped to its hosts
Cost	One certificate, usually cheaper across many hosts	Can climb as the name count grows

Which One to Pick

Reach for a named multi-SAN certificate by default. It matches only what you tell it to, a leaked key burns a bounded set of hosts, and you can split keys along trust lines. The cost is that adding a host means a reissue, which is real work but predictable work.

Choose a wildcard on purpose, for two cases. The first is a fleet of subdomains you cannot enumerate ahead of time, a platform minting customer.example.com on signup, where reissuing per tenant is a non-starter. The second is when keeping your hostnames out of CT logs genuinely matters and every host under the name shares one trust level. Outside those, the convenience is not worth handing an attacker the entire namespace on one stolen key. Plenty of shops run both: a wildcard for the disposable subdomain fleet, named certificates for the handful of high-value hosts that deserve their own isolated keys.

Whichever model you pick, both concentrate several services behind one key and one expiry date, which raises the cost of losing track of them. A wildcard hides how many services lean on it; a multi-SAN certificate makes one expiry hit every host it names. That is why a certificate is now a shared dependency worth inventorying, the whole point of an SSL certificate inventory audit. To read what a live host is actually serving and which names its certificate covers, the SSL certificate checker prints the SAN list in seconds. And Generator Labs certificate monitoring watches expiry and chain health across your wildcard and named certificates and maps each one to the endpoints that depend on it, so a single lapse does not quietly take several services down with it. Start monitoring.