SSL Certificate Name Mismatch (Common Name / SAN) Errors Explained

What a name mismatch error is

When you connect over HTTPS, the browser takes the hostname from the address bar and checks whether the certificate the server presents lists that exact name. If it doesn't, the browser refuses to trust the connection and shows a name-mismatch warning, Chrome calls it NET::ERR_CERT_COMMON_NAME_INVALID, Firefox says SSL_ERROR_BAD_CERT_DOMAIN. The certificate itself may be perfectly valid, issued by a trusted authority and years from expiry. It just wasn't issued for the name you asked for.

This is a distinct failure from an expired certificate or an untrusted issuer. Those are about time and trust chains; a name mismatch is purely about identity, does this certificate cover this hostname, yes or no. Getting the category right saves you from reissuing a certificate when the real problem is that the server handed back the wrong one.

Common Name is dead; the SAN is what counts

For years the hostname lived in the certificate's Common Name (CN) field. That is no longer how browsers decide. Since Chrome 58 in 2017, browsers ignore the CN entirely and validate the hostname only against the Subject Alternative Name (SAN) extension, a list of DNS: entries inside the certificate. A certificate whose CN says example.com but whose SAN list omits it will fail, even though a human reading the CN would think it should work.

This matters when you buy or generate certificates by hand, because an older tool or a hastily built CSR might populate the CN and forget the SAN. The rule to internalize: every hostname you serve, apex, www, every subdomain, must appear as an explicit DNS: entry in the SAN list (or be covered by a wildcard). The CN is decoration now.

You can read a live certificate's SAN list straight from the server. Run openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -text and look under 'X509v3 Subject Alternative Name'. Whatever hostnames are listed there are the only ones this certificate covers.

Why the names don't line up

Most mismatches trace back to a handful of causes. The classic one is apex versus www: a certificate issued for example.com that doesn't also list www.example.com, so the bare domain works and the www version breaks (or vice versa). Wildcards catch people too*.example.com covers www and shop but does not cover the naked apex example.com, and it only covers one level, so a.b.example.com fails against a *.example.com wildcard.

The other big family is 'wrong certificate served'. If a server has multiple sites and the requesting client doesn't send SNI, or the vhost is misconfigured, the server falls back to a default certificate for some other domain, and the browser correctly reports that the presented certificate doesn't match. The same thing happens when a CDN or load balancer terminates TLS with a certificate that hasn't been updated to include your hostname, or when someone browses directly to an IP address, which no public certificate lists as a SAN.

• Cert covers the apex but not www (or the reverse)
• Wildcard *.example.com used for the bare apex, or for a two-level subdomain
• Server serving a default/other-site certificate due to a missing SNI or bad vhost
• CDN or load balancer terminating TLS with a stale certificate
• Browsing to a raw IP address, which certificates don't list

Fixing it

First, inspect what's actually being served with the openssl command above, or from outside your network with our free SSL checker, which lists the SAN entries and flags the mismatch for you. Compare that list against the hostname visitors use. The gap tells you which fix you need.

If the certificate simply doesn't include the hostname, reissue it with every name in the SAN list, or switch to a wildcard that covers your subdomains, remembering to add the apex explicitly alongside it. If the certificate is correct but the wrong one is being served, the fix is on the server: make sure the vhost's server_name (nginx) or ServerName/ServerAlias (Apache) matches, that the correct certificate is bound to that vhost, and that SNI is working. When TLS terminates at a CDN or load balancer, update the certificate there rather than at the origin, since the origin's config is invisible to the browser.

A cheap and common improvement is to standardize on one canonical hostname and redirect the rest to it, but the redirect still needs a valid certificate for the hostname it's redirecting from, because the browser validates the certificate before it ever sees the redirect.

Catch mismatches before your visitors do

Name mismatches love to appear right after a change nobody connected to TLS, a new subdomain launched without adding it to the certificate, a wildcard that quietly doesn't cover a new host, a load balancer swapped without its certificate. Because the apex often keeps working, these can go unnoticed on exactly the pages you don't check daily. This is where uptime monitoring falls short: a simple up/down ping may see a 200 and report everything green while the certificate silently fails to match a subdomain, which is the distinction we cover in SSL monitoring versus uptime monitoring.

VigilDog's monitoring validates the actual certificate served for each hostname you track, checking that the SAN covers the name, that the chain is intact, and that expiry is comfortably far off, and alerts you the moment a mismatch appears. You find out from a notification, not from a customer forwarding you a scary browser warning.