Hostname Mismatch
The TLS certificate presented by the server does not include the domain name you are trying to reach. Browsers show "SSL_ERROR_BAD_CERT_DOMAIN" or similar.
What You Will See
"The certificate is not valid for the requested host." Browsers refuse to connect and show a security warning. Curl reports "SSL: certificate subject name does not match target host name." Programmatic clients throw hostname verification exceptions.
Common Causes
- Wrong certificate installed. The server is presenting a cert issued for a different domain entirely.
- Wildcard cert does not cover the bare domain. A certificate for
*.example.com covers www.example.com and api.example.com but does not cover example.com itself.
- DNS changed but the cert was not updated. You pointed a new domain at the server but never issued a certificate that includes it.
- Load balancer routing to the wrong backend. A misconfigured virtual host or listener serves a default certificate instead of the one for the requested hostname.
- SNI misconfiguration. The server is not using Server Name Indication correctly, so it falls back to a default cert that does not match the requested host.
How to Diagnose
Use the TLS Inspector to check the Subject Alternative Names (SANs) list on the certificate. If your domain is not in the SANs, the cert is wrong for this host. Also verify whether a wildcard pattern should match. Remember that wildcards only cover one level of subdomain.
How to Fix
- Issue a new certificate that includes the correct domain in the SANs. Most CAs and ACME clients let you specify multiple domains with
-d flags.
- If using a wildcard certificate, remember that
*.example.com does NOT cover example.com itself. You need both *.example.com and example.com as SANs.
- Check SNI configuration on your load balancer or reverse proxy to ensure the correct certificate is served for each hostname.
- Verify with the TLS Inspector that the updated certificate is being served and your domain appears in the SANs.