Wildcard vs SAN certificates: what each one actually covers

Two different ways to cover more than one hostname

A single certificate can be issued for more than one hostname, and there are two distinct ways to do it: a wildcard entry, which matches an entire class of names at once, and explicit SAN (Subject Alternative Name) entries, which each name one specific host. Both ultimately show up in the same SAN extension RFC 5280 defines — a wildcard is simply a SAN entry that starts with *. — but they cover fundamentally different things, and conflating the two is the most common reason someone discovers a certificate doesn’t cover a hostname they assumed it did.

What a wildcard actually matches

A wildcard entry like *.example.com matches any name that substitutes something for that single leading label — mail.example.com, app.example.com, anything.example.com — but nothing else. RFC 6125 §6.4.3 restricts wildcard matching to the left-most label position in a presented identifier, which has two consequences that surprise people who assume “wildcard” means “everything under this domain”:

• It does not cover the bare apex. *.example.com does not match example.com itself — the bare domain has no label in the wildcard’s position. A certificate meant to cover both needs the apex added as its own separate SAN entry, which is why publicly trusted certificates for a domain and its www or wildcard subdomains commonly list the apex explicitly alongside the wildcard rather than relying on the wildcard alone.
• It does not cover a second level of subdomains. *.example.com matches sub.example.com but not a.b.example.com, which has two labels ahead of the base domain instead of one. CAs following the CA/Browser Forum’s Baseline Requirements do not issue multi-label wildcards like *.*.example.com to work around this — a deeper subdomain needs either its own listed name or its own wildcard certificate scoped one level down.

What a SAN (multi-domain) certificate actually covers

A SAN certificate — sometimes called a UCC (Unified Communications Certificate) or multi-domain certificate — lists an explicit, enumerated set of hostnames instead of matching a pattern. Each name is independently validated by the issuing CA before being added, and unlike a wildcard, those names don’t need to share a base domain at all: one certificate can legitimately cover example.com, www.example.com, and a completely unrelated example.net together, something no wildcard, however it’s written, can ever do on its own.

The tradeoff is operational: adding a new hostname to a SAN certificate means reissuing the certificate with the updated list, while a wildcard automatically covers any new name that fits its one matching label without touching the certificate at all.

The real tradeoff: coverage convenience vs blast radius

Choosing between them isn’t about which is more “secure” in a cryptographic sense — the key and signature algorithms are identical either way. It’s about two practical differences:

1. Coverage shape. A wildcard effortlessly covers an unknown, growing set of names at one subdomain level under one base domain. A SAN certificate covers an exact, fixed list that can span multiple unrelated domains, but every addition requires reissuing.
2. Key compromise blast radius. A compromised wildcard private key is valid for every hostname matching that label, including ones that don’t exist yet — a single leak can affect an entire, open-ended set of subdomains. A compromised SAN certificate’s key only affects the specific, already-known names it was issued for, which is one reason some organizations deliberately avoid wildcards for anything handling sensitive traffic even when the convenience would be welcome.

How to check what your own certificate actually covers

Run AdminKit’s SSL/TLS check tool against your hostname to see the exact SAN list a live certificate presents — including whether an entry is a wildcard, a specific name, or both — rather than assuming from the certificate’s nickname or how it was sold to you. See how to read a TLS/SSL certificate check result for what the other fields in that result mean, and checking TLS certificate chain completeness if the certificate’s coverage looks right but connections are still failing. If you’re also controlling which CAs are even allowed to issue for your domain in the first place, see what CAA records are and how they limit issuance.

This is a different wildcard mechanism from a wildcard DNS record, which answers a DNS query for any unregistered subdomain — the two happen to use the same *. notation but operate at completely different layers, and having one says nothing about whether the other is also in place.

Two other configuration details worth checking while you’re reviewing DNS and mail fundamentals: whether your zone’s apex is set up correctly in ALIAS, ANAME and CNAME flattening at the apex explained, and whether your DMARC record’s alignment setting matches how your mail is actually sent, in DMARC alignment: relaxed vs strict explained.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.