A hostname mismatch means the certificate presented by the server does not cover the name the client requested. Find the requested name and the responding endpoint before buying or reissuing anything.
IN THIS ARTICLE
01 Trace the mismatch
- Record the exact URL or mail-server hostname, including any
wwwprefix. A domain name, its subdomains and an IP address are different certificate identities. - Inspect the certificate's subject alternative names. Compare them with the requested hostname rather than relying on the certificate's friendly label.
- Check the public DNS destination, including both IPv4 and IPv6 where present. Verify that every answering server has the intended website and certificate configuration.
- If a CDN or security proxy answers first, inspect its certificate coverage and custom-hostname configuration.
- Correct an accidental client hostname or server assignment. If the name is intentionally required but uncovered, arrange an appropriate certificate or reissue with the needed names.
- Retest the original address and every redirect destination. Keep a valid certificate on an HTTPS address even when its only job is to redirect visitors.
02 Example: inspect the names covered by the served certificate
From a trusted workstation, retrieve the website's public certificate and print its subject alternative names. Replace example.com with the hostname displaying the warning. The public certificate contains no private key, and this inspection does not change the site.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Read the result: Compare the exact browser hostname with the DNS names in subjectAltName. A certificate for www.example.com does not automatically cover example.com. A wildcard such as *.example.com covers an eligible single label beneath that domain, not every deeper name or the apex.
This extraction alone is not a complete trust-chain validation and hides handshake diagnostics for readability. Use a separate verified TLS check if it fails or if trust is also in doubt. Assign a certificate that covers the intended names at the actual TLS endpoint, then test again.
Common questions
Will an HTTPS redirect hide the mismatch?
The TLS connection is established before the server can return an HTTP redirect. The original HTTPS hostname still needs acceptable certificate coverage.
Why does it work by domain but fail by IP?
A domain certificate does not automatically cover an IP-address connection. Test using the intended hostname unless the service specifically supports a certificate for that IP.
Should I accept the warning permanently?
Fix the identity or configuration problem. An exception can conceal a wrong endpoint or interception and does not repair the certificate.