"NET::ERR_CERT_COMMON_NAME_INVALID" means the server sent a certificate that is otherwise fine — trusted, unexpired — but doesn't list the hostname you visited. Browsers match the address bar against the certificate's Subject Alternative Name (SAN) list, and nothing in it matched. The usual causes are a certificate that covers example.com but not www.example.com, a wildcard used where it doesn't apply, or the server sending the certificate for a different site. The fix is to issue a certificate that includes the hostname, or to make the server send the one that already does.
What It Looks Like
Every browser and client reports the same mismatch in its own words. In Chrome and Edge the page reads "Your connection is not private", with this code underneath:
# Chrome / Edge
NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is www.example.com; its security
certificate is from example.com.
# Firefox
SSL_ERROR_BAD_CERT_DOMAIN
# curl
curl: (60) SSL: no alternative certificate subject name matches target
host name 'www.example.com'
# Node.js
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match
certificate's altnames: Host: www.example.com. is not in the cert's
altnames: DNS:example.comChrome's detail line is the most useful part: it names the host you asked for and the name the certificate was actually issued to. That pair usually tells you the cause straight away.
Why It Happens
1. The certificate covers the apex but not www (or the reverse)
example.com and www.example.com are different names, and a certificate only covers the ones it lists. Issuing for one and serving both is the most common cause by far, often after a quick certbot -d example.com that left www out.
2. A wildcard used outside what it matches
*.example.com stands in for exactly one label. It covers shop.example.com, but not the bare example.com and not a deeper name like api.eu.example.com.
3. The server sends another site's certificate
On a server hosting several sites, each HTTPS virtual host needs its own certificate. If the hostname isn't listed in any server_name (Nginx) or ServerName/ServerAlias (Apache) on port 443, the server falls back to its default site and sends that site's certificate.
4. DNS points somewhere else
The hostname resolves to a server that isn't yours, or isn't set up for it yet: an old host after a migration, a CDN or platform (GitHub Pages, Netlify, a load balancer) where the custom domain was never added, or a parked page. That server answers with a certificate for its own name.
5. You're connecting by IP address or an internal name
Visiting https://203.0.113.10 or https://intranet fails against a certificate issued for example.com. Public CAs don't issue for internal names, so internal services need an internal CA or a real DNS name.
6. An old certificate with only a Common Name
Modern clients check the SAN list only. A self-signed or legacy internal certificate that puts the hostname in the Common Name but has no SAN fails, even though the name looks right.
How to Diagnose It
Ask the server for the certificate it sends for this exact hostname, and list its names. Always pass -servername: without it the server can't tell which site you want and may send its default certificate.
# Which names does the certificate for www.example.com cover?
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName
# subject=CN = example.com
# X509v3 Subject Alternative Name:
# DNS:example.com <- www.example.com is missing
# Is the hostname even pointing at your server?
dig +short www.example.com AIf the names are right but the certificate belongs to another site, the server is choosing the wrong virtual host (cause 3). If the subject is a name you don't recognise, DNS is pointing elsewhere (cause 4).
How to Fix It
Fix A — Reissue the certificate with every hostname
List every name the site answers on. With Let's Encrypt, add each as its own -d; the first becomes the Common Name and all of them become SANs:
# Cover the apex and www in one certificate
sudo certbot --nginx -d example.com -d www.example.com
# Wildcard plus the apex (DNS validation required for wildcards)
sudo certbot certonly --manual --preferred-challenges dns \
-d example.com -d '*.example.com'Fix B — Make the server send the right certificate
Give each hostname a port-443 virtual host that points at the certificate covering it. The hostname must appear in that block, or the server serves its default site instead:
# Nginx
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}
# Apache
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>Fix C — Point DNS at the right server, or add the domain on your platform
If the hostname resolves to an old host, update the A record (and AAAA, if you publish one) to your current server. On a CDN or hosting platform, add the custom domain in its dashboard so it issues a certificate for it; until that certificate is active, the platform sends its own.
Fix D — Use a real hostname for internal services
Give internal services a DNS name under a domain you own (intranet.example.com) and issue for that, or run an internal CA and install its root on your devices. Don't teach users to click through the warning.
Verify the Fix
Re-run the check for each hostname you serve. Every one should appear in the SAN list, and the browser should load the page without a warning:
for h in example.com www.example.com; do
echo "== $h"
openssl s_client -connect $h:443 -servername $h </dev/null 2>/dev/null \
| openssl x509 -noout -ext subjectAltName
doneFrequently Asked Questions
1. Why does example.com work but www.example.com shows the error (or the other way round)?
A certificate only covers the names listed in its Subject Alternative Name (SAN) field, and example.com and www.example.com are two separate names. If the certificate was issued for one of them, the other fails. Reissue it with both names, for example certbot -d example.com -d www.example.com.
2. Does a wildcard certificate cover the bare domain?
No. *.example.com matches exactly one label in place of the asterisk, so it covers www.example.com and shop.example.com but not example.com itself, and not a.b.example.com. Most CAs add the bare domain as a second SAN when you order a wildcard; check that yours did with the SSL Checker.
3. Can I fix it by redirecting to the hostname the certificate does cover?
No. The browser checks the certificate during the TLS handshake, before it has sent a single HTTP request, so it never sees your redirect. The certificate must cover the hostname the visitor typed. Once it does, a redirect to your preferred hostname works normally.
4. The certificate’s Common Name is correct. Why does Chrome still reject it?
Chrome (since version 58) and other modern clients ignore the Common Name and check only the Subject Alternative Name list. A certificate with the right CN but no matching SAN entry fails. Every CA-issued certificate today includes SANs; this mostly affects old self-signed and internal certificates.
5. Is it safe to click “Proceed anyway”?
Not on a site you don’t control. A name mismatch is exactly what an attacker’s certificate would look like, so the browser can’t tell a misconfiguration from interception. On your own server, use the warning only as a cue to fix the certificate.
6. Why do I only see the error on one network or one device?
Then a different server is answering. Captive portals, corporate TLS-inspection proxies and stale DNS (an old IP still cached) all present a certificate for some other name. Compare the IP the failing device resolves with DNS Lookup.