Hostname Mismatch and SAN Sprawl
At a private wedding, the bouncer has a list. Names of approved guests. They check each arrival against the list. If your name's on it, you're in. If it isn't, you're not, even if you're standing next to the bride and explaining at length that you were definitely invited and they must have lost the email.
The list isn't perfect. Sometimes a guest got invited and never made it onto the list (administrative error). Sometimes a name got copied wrong (Smith vs. Smyth). Sometimes a plus-one was assumed but never officially registered. Sometimes the list was updated for the original venue and not migrated to the back-up venue when the wedding moved indoors because of rain.
A TLS certificate's Subject Alternative Name (SAN) list is exactly this bouncer's list. It's the official record of which hostnames this cert is allowed to vouch for. When a client connects to api.example.com, the cert had better have api.example.com somewhere on the list. If it doesn't, no entry. No connection. The error doesn't say "you weren't on the list" - it says "this certificate doesn't match the domain you're trying to reach" - but the structural problem is the same.
Here's how SAN mismatches actually happen, the phenomenon of SAN sprawl, where wildcards bite, and how to catch the gaps.
How SANs and wildcards actually work
A TLS certificate's identity is governed by:
The Common Name (CN). The "primary" hostname. Historically this was the main field. Modern browsers ignore it in favour of the SAN list.
The Subject Alternative Name (SAN) list. An explicit list of every hostname this cert is valid for. Can include literal names (api.example.com) and wildcards (*.example.com).
A connection to [hostname] succeeds if [hostname] matches either a literal name in the SAN list or a wildcard that covers it.
The wildcard rules matter and are subtler than they look:
.example.comcoversapi.example.com,www.example.com, but notexample.comitself, and notapi.eu.example.com(two dots deep)..api.example.comcoversv1.api.example.com,v2.api.example.com, but notapi.example.comitself, and notv1.staging.api.example.com.
A wildcard covers exactly one level of subdomain. Anything deeper, or anything at the wildcard's own level, requires an explicit SAN entry.
The hostname mismatch failure modes
Five common patterns.
Pattern 1: New subdomain, old cert. Marketing launches campaign.example.com. The wildcard cert is *.www.example.com. The new subdomain isn't covered. The browser shows an error. Marketing complains. Engineering issues a new cert. Repeat next sprint.
Pattern 2: Wildcard depth mismatch. A team launches api.v2.example.com. They assume the existing *.example.com covers it. It doesn't - that's two levels deep, the wildcard covers only one. Browser error.
Pattern 3: Truncated SAN list during renewal. A cert had a long SAN list - say, 47 hostnames. At renewal, the new cert is issued with only 30 of them. Someone copied an old configuration. Seventeen subdomains stop validating. Some users notice immediately; some only when they hit those subdomains.
Pattern 4: SNI mismatch. Multiple sites on one IP via Server Name Indication (SNI). The server is supposed to serve the right cert for the requested hostname. Some configurations get it wrong - the wrong cert is served for one of the hostnames. The SAN doesn't match. Browser error.
Pattern 5: Apex domain forgotten. The team set up *.example.com and never explicitly added example.com. A user types just example.com and gets a hostname mismatch error.
The thread connecting these: each one is a failure of "we said this cert covered everything" running into "actually, it doesn't cover this specific thing." The fix is usually re-issuing the cert with the right SAN list. The harder part is noticing.
SAN sprawl - why your cert has 200 names
Some teams take the opposite approach to wildcards: put every hostname explicitly in the SAN list. This is fine until it isn't.
A cert that starts with 5 SANs grows over time. Marketing launches a new microsite. Engineering adds the hostname to the SAN list. Six months later, sales spins up another. SAN list goes up. Subdomain churn continues. After three years, the cert has 200+ SANs.
This works mechanically. It introduces three subtler problems.
Maintenance overhead. Every new subdomain requires either a new cert or an updated SAN list on an existing cert. Both are operational events.
Renewal risk. When a cert with 200 SANs is renewed, the renewal must include the right SANs. Renewals that drop SANs are exactly Pattern 3 above.
Information disclosure. The full SAN list is public - anyone who connects to the server can see all 200 hostnames. This is sometimes a feature (CT logs show them anyway) and sometimes a problem (you've inadvertently published a list of internal-sounding subdomains).
SAN sprawl is a symptom, not a disease. The disease is that nobody owns the cert architecture decision. New subdomains get bolted on to existing certs because that's the path of least resistance.
The wildcard problem
Wildcards solve some of the sprawl problem by covering many subdomains at once. They also introduce their own issues.
Blast radius. If a wildcard cert's private key is compromised, every subdomain it covers is exposed. A *.example.com cert with hundreds of subdomains is a much higher-impact compromise than a single-subdomain cert.
The two-deep rule. Wildcards cover only one level. Teams forget. Multi-deep subdomains break.
Audit complications. Compliance frameworks sometimes want to see explicit ownership per cert. A wildcard covering subdomains owned by different teams confuses the ownership picture.
Vendor restrictions. Some CAs charge more for wildcards. Some compliance environments (FedRAMP, certain financial regulations) restrict their use.
When to use wildcards: when you have many short-lived subdomains and the blast radius is acceptable. When to use explicit SANs: when subdomains are stable, owned by specific teams, and the cert lifecycle can keep up.
When to use both: rarely intentional, often accidental, usually messy.
How to monitor for this
The diagnostic question to answer continuously: "for every hostname my organisation serves, does the cert it's being served actually cover that hostname?"
This is harder than it sounds because: - The set of hostnames changes over time (new subdomains). - Each hostname needs to be checked against the actual cert served, not against the intended cert. - Wildcards need to be checked correctly (one-deep, not two-deep).
The practical setup:
Discover all your hostnames. From DNS, from CT logs, from cloud configurations, from CDN settings. Reconcile.
Connect to each one and inspect the cert. External scanning. Note the SAN list. Check whether the hostname is covered.
Alert on mismatches. Hostname found in DNS but cert doesn't cover it. Cert covers hostnames that don't exist in DNS. Wildcard depth assumed but not actual.
Track SAN list changes over time. Specifically, alert on shrinking SAN lists at renewal - that's the truncation pattern.
One small ask
Hostname mismatches are the failure mode most teams discover via customer complaints rather than monitoring. The user sees a browser warning; the engineer says "but the cert isn't expired." Both are true. The cert is fine. The match isn't. TLS Radar checks SAN coverage against every hostname it knows about, surfaces wildcard depth issues, and tracks SAN list changes between renewals. Free tier covers three domains, which is enough to see whether any of your current certs aren't covering hostnames you're actually serving.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.