Certificate name mismatch: why the padlock fails on the right site

A name mismatch is one of the more confusing TLS failures because nothing is actually wrong with the certificate. It is genuine, in date and signed by a trusted authority. It just was not issued for the hostname the visitor typed, and browsers treat that as fatal.

How the match is decided

The browser compares the hostname in the address bar against the names inside the certificate: the Subject Alternative Name list, which is the authoritative one, and historically the Common Name. If the hostname is not in that list, the connection is refused.

Wildcards match exactly one label. A certificate for *.example.com covers www.example.com and shop.example.com, but it does not cover example.com itself, and it does not cover a.b.example.com. That single rule accounts for a large share of real mismatches.

The four usual causes

• The apex is missing. The certificate covers www.example.com but a visitor typed example.com, or the other way round. Both names need to be in the certificate.
• A new subdomain was added without reissuing. The DNS record exists, the service is running, and the certificate never learned about it.
• A CDN or load balancer is serving a default certificate. The origin is configured correctly but the edge is presenting something else entirely, often the provider's own hostname.
• The wrong virtual host is answering. On a server hosting several sites, a request that does not match any configured hostname falls through to the first site's certificate.

Fixing it

Reissue the certificate with every hostname that should be served, both the apex and www, plus each subdomain in use. If you use a wildcard, remember it does not include the apex, so the apex has to be listed explicitly alongside it. Then reload the web server and confirm from outside that the served certificate really contains the new names.

If the certificate is right and the mismatch persists, the problem is in front of your server. Check what the CDN or load balancer is presenting, because a correct certificate on the origin is invisible to visitors if the edge never uses it.

Why it tends to reappear

Mismatches are introduced by ordinary work: launching a subdomain, moving to a CDN, splitting a service out. The certificate is rarely part of that checklist, so the gap appears at deployment and is discovered by a customer. A check that reads the certificate the way a browser does, and reports which hostnames it covers, turns that into something you find rather than something you are told about.