TLS certificate hostname mismatch

What it means

A TLS certificate hostname mismatch occurs when the requested reference identity, usually the hostname in an HTTPS URL, does not match an appropriate identity in the certificate presented for that connection. The requested host is compared with DNS-ID entries in the Subject Alternative Name (SAN) extension under the applicable matching rules. IP literals require an appropriate IP address identity rather than just a DNS name that resolves to the same address. A redirect cannot repair a handshake already rejected for the wrong name.

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.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

In an authorized staging environment, record the exact requested URL authority and endpoint selected, then examine presented SANs and trust validation using verification enabled. Compare SNI, routing and certificate deployment configurations without copying private keys. Stop if the endpoint is unknown, the certificate is expired/untrusted or a suggested workaround disables verification. Prepare and deploy the correct certificate and verify the original URL; retain the prior known-good certificate and a controlled rollback route.

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

Use the exact requested reference identity and the actual SANs of the certificate served at that endpoint. A single-label wildcard is not an unrestricted suffix match; an IP literal needs the appropriate IP identifier. Fix certificate/SNI/endpoint selection with verification enabled—an HTTPS redirect arrives too late to repair a TLS name mismatch.