Introduction

An SSL certificate name mismatch means the browser reached a server that presented a certificate for a different hostname than the one the visitor requested. The certificate may still be valid and unexpired, but it does not cover the exact domain in the address bar, so the browser blocks or warns before the page can be trusted.

Symptoms

  • Browsers show warnings such as NET::ERR_CERT_COMMON_NAME_INVALID or “Your connection is not private”
  • HTTPS works on one hostname like www.example.com but fails on another like example.com
  • The error appears after moving hosting, changing CDN settings, or reissuing a certificate
  • SSL checkers show that the certificate subject or SAN list does not include the requested hostname
  • The issue affects only specific subdomains, alternate domains, or preview environments

Common Causes

  • The wrong certificate was installed on the web server, load balancer, or reverse proxy
  • The certificate does not include the required hostname in the SAN list
  • A CDN or proxy is terminating TLS with an old or incorrect certificate
  • Redirects send visitors to a hostname that was never added to the certificate
  • The origin server and edge layer use different certificates and one of them is misconfigured

Step-by-Step Fix

  1. Identify the exact hostname that fails, including whether the error is on the apex domain, www, or a subdomain.
  2. Inspect the live certificate in the browser or an SSL checker and confirm the subject and SAN entries include that hostname.
  3. If the hostname is missing, reissue the certificate with every required domain name and subdomain that should serve traffic.
  4. Verify the new certificate is installed on the correct layer, whether that is the web server, load balancer, hosting panel, or CDN edge.
  5. Check redirect rules so visitors are not being sent from a covered hostname to one that the certificate does not protect.
  6. If you use Cloudflare or another proxy, verify edge certificates, origin certificates, and SSL mode settings all match the intended architecture.
  7. Clear old certificates from the server configuration, restart or reload the relevant service, and confirm the new certificate chain is actually being served.
  8. Test the failing hostname again in a browser, with an external SSL checker, and from a private window to rule out cached certificate data.
  9. After recovery, document which hostnames must always be included whenever the certificate is renewed or the site is migrated.