Guides

Certificate name mismatch (ERR_CERT_COMMON_NAME_INVALID): causes and fixes

Updated October 1, 2026

The browser says NET::ERR_CERT_COMMON_NAME_INVALID (Chrome), SSL_ERROR_BAD_CERT_DOMAIN (Firefox) or "the certificate is not valid for this name". The certificate itself may be perfectly valid and in date, but it does not list the name you typed.

How the name check works

A certificate lists the names it covers in its Subject Alternative Names (SANs). The browser compares the hostname in the address bar with that list. If the hostname isn't in it, you get this error. The old "Common Name" field is ignored by modern browsers, so adding the name there does nothing.

See what a certificate covers:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Or use the free SSL checker, which lists the names and ticks the ones that cover the domain you checked.

Common causes

• www and the bare domain are different names. A certificate for www.example.com does not cover example.com, and the other way round. Include both.
• A wildcard covers one level only. *.example.com matches shop.example.com, but not example.com itself and not a.shop.example.com.
• The wrong server answers. If a server hosts several sites and doesn't pick the right certificate (SNI), or a new name points at a server that has only the default certificate, visitors see someone else's certificate. This is common right after pointing a new subdomain at a host.
• Using an IP address or another hostname. Certificates are issued for names. Opening https://203.0.113.5 or an internal alias will mismatch unless that exact name is on the certificate.
• A new subdomain was never added. Someone created api.example.com but the certificate was issued before, without it.
• CDN or proxy misconfiguration. The edge presents a certificate for a different hostname than the one visitors use.

How to fix it

1. List the exact hostnames visitors use (including www and any API or admin names).
2. Reissue the certificate with all of them as SANs. With certbot: certbot --nginx -d example.com -d www.example.com (add more -d for each name).
3. Install it on every server or service that answers for those names, then reload.
4. Verify with the commands above or the checker, for each name.

A related trap: names that point somewhere else

One certificate often lists several names, and not all of them are served from the same place. When you renew it for one site, the other places keep the old certificate until someone installs the new one there, and then they expire. CertAvert shows, for each name on a certificate, where it points in DNS, so you can spot names served from elsewhere. Sign up free to try it.