SSL Certificate Name Mismatch: Why It Happens and How to Fix It

Short answer: a name mismatch means the SSL certificate on your server was issued for different domain names than the one visitors are using. Look at which names the certificate lists, then reissue it so it includes every address you use, including the www and non-www versions.

Browsers show this as "Your connection is not private" with codes such as ERR_CERT_COMMON_NAME_INVALID (Chrome) or SSL_ERROR_BAD_CERT_DOMAIN (Firefox). It is different from an expired certificate because the certificate may be perfectly in date, just for the wrong names.

Step 1: see which names the certificate covers

In Chrome, click "Not secure" in the address bar, open the certificate details, and look at the "Subject Alternative Name" list. From a terminal you can read the same thing:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Modern browsers only trust the Subject Alternative Name (SAN) list. If the exact name you visit is not in it, you get the error.

Step 2: compare against the address people use

Write down every address that should work: example.com, www.example.com, and any subdomains such as shop.example.com. Each one needs to appear in the SAN list, or be matched by a wildcard.

Step 3: check you are hitting the right server

Sometimes the certificate is fine but the wrong one is being served.

• Shared hosting or a CDN: the server picks a certificate by the name the browser asks for. If your domain is not added to the account, it falls back to a default certificate for the host's own name.
• Old DNS record: if the domain still points to a previous host, that server answers with its certificate. Check with dig A example.com +short and compare with the IP your current host gave you.
• Several servers behind a load balancer: one of them may have the wrong certificate, so the error appears only some of the time.

Step 4: reissue the certificate with the right names

On most hosts this is a control panel setting. In a hosting panel, add the domain and all its subdomains to the SSL section and request a new certificate. With Certbot on your own server:

sudo certbot --nginx -d example.com -d www.example.com

Use --apache instead of --nginx on Apache. Reload the web server afterwards if the tool does not do it for you. If you use a CDN or proxy, make sure its SSL mode and its edge certificate also include the names.

Step 5: add redirects and test

Once both versions of your domain are covered, send one to the other so visitors and search engines see a single address. See www and non-www redirect for the setup. Test in a private window, then run your domain through an SSL checker such as Qualys SSL Labs to confirm the names and the chain.

Common mistakes

• Issuing the certificate for example.com only and forgetting www.
• Assuming a wildcard covers the bare domain and every deeper subdomain.
• Leaving the domain pointed at an old server that has a different certificate.
• Testing by IP address, which can never match a name-based certificate.
• Fixing the certificate but not the redirect, so visitors still land on the uncovered address.