TLS certificate hostname mismatch

What it means

Certificate hostname validation compares the requested service identity with acceptable names in the certificate actually presented by the endpoint. The relevant identifier is the requested reference identity, not simply the IP address to which DNS resolved. A redirect received later cannot repair an identity check that must pass before trusting HTTP. Service identity

Try it

Simulation — compare reference identity with SAN. Select www.example.com with a matching exact SAN or *.example.com and inspect one-label wildcard behavior. Try a.b.example.com: it does not match the single-label wildcard in this fixture. Choose 192.0.2.10 and a DNS-only SAN, then inspect IP-ID mismatch. Select an expired chain or a redirect-only plan to understand why other validation steps and the order of HTTPS/redirect matter. Reset clears the diagnostic path.

How the mechanism works

Clients start with a reference service identity and compare it against relevant identifiers presented by the selected endpoint. Servers that host multiple sites can present different certificates depending on endpoint configuration and SNI. A certificate valid for example.com does not automatically cover www.example.com, and DNS resolution to an IP does not turn a DNS-ID into an IP-ID. Wildcards, where applicable, are restricted; they must not be interpreted as matching arbitrary depths or arbitrary identity types. Matching a name does not prove the trust chain or validity period passed.

For an HTTPS redirect to happen, the client ordinarily must first establish a secure connection to the origin responding with the redirect. If its certificate name is wrong, redirect configuration cannot rescue the failed TLS identity step. The safe fix is to serve a certificate with the correct authorized SAN from the intended endpoint and then verify deployment and chain.

The right server can present the wrong certificate

A client requests https://www.example.com/, and the intended virtual-host configuration contains www.example.com in its SAN. If the server instead selects its fallback virtual host, the fixture presents a certificate for fallback.example.net. The requested hostname and the presented certificate disagree even though the intended configuration looks correct.

A redirect to the right host cannot fix the original TLS handshake: identity checking happens before the browser can act on an HTTP Location header. Check the selected endpoint and SNI configuration, the presented SAN, and certificate path/time independently. STOP rather than suggesting that users ignore a browser certificate warning. Preserve the prior tested deployment so a correction can be reverted.

The certificate is valid, but for another host

A client opens https://portal.example.test but the endpoint presents a certificate covering only www.example.test. The chain could be valid while hostname verification still rejects the connection. A certificate for *.example.test can match a single leftmost label such as portal.example.test under the relevant rules, but not an arbitrary deeper name such as a.portal.example.test and not necessarily the bare example.test. When the URL uses an IP literal, appropriate IP-address certificate identifiers are required. The simulated checker is a bounded matching example, not the browser’s full trust evaluation. Wildcard and IP-ID rules

In practice

Inspect the exact URL requested, the endpoint selected through DNS and TLS SNI, and all relevant subjectAltName entries in the presented certificate. If the hosting configuration serves a default certificate for the wrong virtual host, fix that endpoint mapping with authorization and verify again. Never disable hostname verification as the normal remedy.

Limits and common mistakes

The scene restricts identity checks to a small set of ASCII DNS names, IP literals and a simple wildcard. It does not implement IDNA, internationalized names, all RFC 9525 application identifier types or complete certificate-path validation. It cannot diagnose every browser warning or scan real certificates.

Key takeaways

Certificate identity is checked for the service the user requested, before any trusted application redirect. Find which endpoint actually served the wrong identifiers, and keep identity verification enabled throughout the repair.