NET::ERR_CERT_COMMON_NAME_INVALID: what it means and how to fix it
The browser warns “Your connection is not private” with NET::ERR_CERT_COMMON_NAME_INVALID. The certificate is valid, but it was issued for a different name than the one in the address bar.
See which names the certificate covers
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltNameIn Chrome, click Not secure, then the certificate details, and look at Subject Alternative Name. Browsers ignore the old Common Name (CN) field and only check this list, which is why a certificate with the right CN but no matching SAN still fails.
Common causes and fixes
| You visited | Certificate covers | Fix |
|---|---|---|
www.example.com | example.com only | Reissue with both names: certbot -d example.com -d www.example.com |
example.com | *.example.com | A wildcard doesn't cover the bare domain; add example.com too |
api.dev.example.com | *.example.com | Wildcards cover one level only; add *.dev.example.com or the exact name |
https://203.0.113.10 | a domain name | Use the domain name; certificates for IPs are rare |
| Your site | another site on the same server, or the host's default | Fix the server block / virtual host, or the client isn't sending SNI |
| A new domain on a CDN or host | the platform's own name (*.herokuapp.com etc.) | Add the custom domain in the platform so it issues a certificate, and wait for it |
localhost or a LAN name | anything public | Use a local development certificate (for example mkcert) that lists that name |
Server-side checks
- nginx: each
serverblock needs the rightserver_nameand its ownssl_certificate. If no block matches, nginx uses the default server's certificate, which is the classic "wrong site's certificate" problem. - Apache: check
ServerName/ServerAliasin the:443VirtualHost, not just the:80one. - Let's Encrypt:
certbot certificateslists the names in each certificate. Use--expandto add a name to an existing one. - Behind Cloudflare: visitors see Cloudflare's edge certificate, which covers the zone and one level of subdomain on the free plan; deeper names like
a.b.example.comneed an advanced certificate. Between Cloudflare and your server, a name mismatch shows as error 526 in Full (strict) mode.
From code and command lines
The same problem appears as Hostname/IP does not match certificate's altnames (Node), certificate verify failed: Hostname mismatch (Python), SSL: no alternative certificate subject name matches target host name (curl) and x509: certificate is valid for …, not … (Go). Don't switch off verification to get past it: it means the client can't tell it's talking to the right server. Call the host name the certificate lists, or fix the certificate.
Related
Certificate has expired · unable to get local issuer certificate · SSL wrong version number · Mixed Content blocked · Who owns this link? · ERR_SSL_PROTOCOL_ERROR
Questions
What does NET::ERR_CERT_COMMON_NAME_INVALID mean?
The site's certificate is for a different name than the one you typed. The connection is encrypted, but the browser can't confirm it's really that site.
Does a wildcard certificate cover the root domain?
No. *.example.com covers www.example.com and api.example.com, but not example.com itself or two-level names like a.b.example.com.
Why does the error mention the common name?
It's a historical name. Browsers now ignore the Common Name and check only the Subject Alternative Name list.
Is it safe to click Proceed anyway?
Not on a site you don't control. It's how an interception attack would look. On your own server it's a configuration problem to fix, not to bypass.
Why does only www (or only the bare domain) fail?
The certificate lists just one of them. Reissue it with both names.
Published .