← Back to Blog
troubleshooting

How to Fix the SSL Certificate Name Mismatch Error (2026)

Your browser shows NET::ERR_CERT_COMMON_NAME_INVALID or a variation of "the certificate is not valid for this domain." The certificate is real, it's not expired — but it was issued for a different domain name than the one your visitor is accessing. That mismatch is what triggers the error.

🔒

Free SSL Checker

Check exactly which domains your certificate covers to find a name mismatch.

Try It Free →

How Browsers Actually Check the Name

Modern browsers ignore the certificate's legacy Common Name (CN) field entirely for hostname matching and check only the Subject Alternative Name (SAN) extension — a change formalized industry-wide and required by the CA/Browser Forum Baseline Requirements. If the domain your visitor is accessing doesn't appear as a SAN entry on the certificate, the browser rejects it as a mismatch even if that same name happens to appear in the CN field.

What Causes a Name Mismatch — By Cause

CauseWhat's HappeningFix
www vs non-wwwCertificate only covers example.com but visitor hits www.example.com (or vice versa)Reissue with both as SANs, or redirect at the server level before TLS termination handles the wrong host
Subdomain not coveredCertificate covers example.com only; visitor hits shop.example.comAdd the subdomain as a SAN, or switch to a wildcard (*.example.com) certificate
Wrong certificate served (SNI misconfiguration)Server hosts multiple sites and serves the default/first certificate instead of the one matching the requested hostnameFix the web server's SNI/virtual-host mapping so each hostname maps to its own certificate
IP address accessVisitor accesses the server directly by IP; certificates are issued for hostnames, not IPs (unless the IP is itself listed as a SAN)Expected behavior — access via the domain name, or issue an IP SAN certificate if direct IP access is a genuine requirement
Load balancer/CDN edge mismatchOrigin certificate doesn't match the hostname the CDN or load balancer is forwardingEnsure the certificate installed at the edge covers the exact public-facing hostname

How to Diagnose It Yourself

# See exactly which names a certificate covers openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \ | openssl x509 -noout -text | grep -A 1 "Subject Alternative Name" # Compare against the hostname you're actually visiting echo "Visiting: yourdomain.com" # Check what a specific hostname resolves to and what cert it gets (useful for multi-site servers) openssl s_client -connect yourdomain.com:443 -servername www.yourdomain.com 2>/dev/null \ | openssl x509 -noout -subject
The -servername flag matters. Without it, some servers (especially those hosting multiple TLS sites via SNI) return their default certificate — which may not be the one for the hostname you actually care about — and you'll get a misleading result.

Wildcard vs. Explicit SAN: Which Fixes It Better?

If the mismatch is a missing subdomain, you have two real options: add each specific subdomain as its own SAN entry (more precise, requires reissuing whenever a new subdomain is added), or switch to a wildcard certificate covering *.example.com (covers any single-level subdomain automatically, but does not cover the bare apex domain or multi-level subdomains like a.b.example.com — those still need their own entry). See our wildcard vs. multi-domain comparison for the full decision framework.

Fixing It on Your Server

# Nginx — confirm which server block/certificate handles a given hostname nginx -T | grep -B 5 "ssl_certificate " | grep -E "server_name|ssl_certificate " # Apache — list configured VirtualHosts and their certificates apachectl -S # Reissue a Let's Encrypt certificate with the missing name added certbot certonly --cert-name yourdomain.com \ -d yourdomain.com -d www.yourdomain.com -d shop.yourdomain.com

Find out exactly which domains your certificate covers

Our SSL Checker lists every SAN entry on a certificate so you can spot a mismatch in seconds.