Subject Alternative Names & the Mismatch Trap

The single most common HTTPS error isn't an expired certificate. It's a perfectly valid, perfectly trusted certificate that simply doesn't list the hostname the visitor typed. The list it should have been on is the Subject Alternative Name — and the “Common Name” field that everyone instinctively checks has been ignored by browsers for years.

CN is dead; long live SAN

Early TLS certificates identified their site with a single field, the Common Name — one hostname, like www.example.com. That fell apart as soon as sites needed to be reachable under more than one name, so the Subject Alternative Name extension was added: a list of hostnames the certificate is valid for.

For years certs carried both, and the CN duplicated the first SAN entry for compatibility. Then browsers drew a line. Chrome 58, in 2017, stopped looking at the Common Name altogether — if a hostname isn't in the SAN list, the cert is invalid for it, full stop, no matter what the CN says. Every major browser followed. The CN is now a vestigial, display-only field; the SAN is the only thing that decides validity.

How matching works

When you connect to a host over HTTPS, the browser takes the hostname from the URL and checks whether it matches any entry in the certificate's SAN list. The match is exact, with one wrinkle for wildcards:

Wildcards cover exactly one label

A wildcard SAN like *.example.com matches one level of subdomain — and only one:

This is why the common, correct pattern is to put both the wildcard and the apex in the SAN: *.example.com and example.com. A wildcard alone leaves your bare domain uncovered, and a wildcard never reaches two levels deep — api.staging.example.com needs either its own entry or a *.staging.example.com wildcard.

SNI: how the server even knows which cert to send

One server IP often hosts many HTTPS sites, so before any certificate changes hands the browser announces the hostname it wants in the TLS handshake — that's Server Name Indication (SNI). The server uses the SNI value to pick which certificate to present. If SNI and your virtual-host config disagree, you can get the wrong site's certificate back — which then fails the SAN check for the name you asked for. Mismatches sometimes trace back to a misconfigured default vhost rather than the cert itself.

Single, multi-domain, and wildcard certs

• Single-name — one or two SAN entries (typically apex + www). Fine for a simple site.
• Multi-domain (SAN / UCC) — an explicit list of unrelated hostnames, even across different domains, on one cert. Common behind load balancers and on platforms hosting many properties.
• Wildcard — one *.example.com entry covering any single-label subdomain, usually paired with the apex.

What FatDig shows you

The SSL section on the Advanced Dig lists the certificate's Subject Alt Names alongside who it was issued to and its validity window. The check that actually matters: is the specific hostname you care about — both the apex and the www, if you use both — present in that SAN list? A cert can be freshly issued, from a top-tier CA, valid for another 89 days, and still throw an error for half your visitors because one of those two names was left off. The SAN list is where you confirm it wasn't.