SSL Hostname Mismatch Error Explained

An SSL hostname mismatch error occurs when the domain in the browser's address bar does not match any of the domains covered by the certificate's Subject Alternative Names (SANs). Browsers verify that the certificate is valid for the specific hostname being accessed — if it isn't, the connection is rejected.

Error Codes

• Chrome: NET::ERR_CERT_COMMON_NAME_INVALID
• Firefox: SSL_ERROR_BAD_CERT_DOMAIN
• curl: SSL: certificate subject name '...' does not match target host name

Common Causes

• www vs. non-www: Certificate covers www.example.com but not example.com, or vice versa. All modern certificates should include both.
• Wrong certificate deployed: Nginx/Apache is serving a certificate for a different site (misconfigured virtual host)
• Subdomain not in SAN: app.example.com is not listed in a certificate issued for example.com
• IP address access: Accessing a server directly by IP and the certificate has no SAN entry for that IP
• Pre-production domain: A staging.example.com is using the production certificate that doesn't list the staging domain

How to Diagnose

Fetch the live certificate and paste it into the decoder:

openssl s_client -connect yourdomain.com:443 </dev/null 2>/dev/null | openssl x509

In the decoder, check the Subject Alternative Names section. Verify that the hostname you're trying to access is listed there. Remember that wildcards (*.example.com) only cover one subdomain level deep — they don't cover sub.sub.example.com.

How to Fix It

If the domain is not in the SAN, you need to reissue the certificate with the domain added. For Let's Encrypt: add the domain to your certbot certonly or --domains list and re-issue. For commercial CAs: reissue the certificate with the additional SAN. You cannot add a domain to an existing certificate — a new certificate must be issued.