How to Fix ERR_CERT_COMMON_NAME_INVALID in Chrome
What ERR_CERT_COMMON_NAME_INVALID means
Every time you visit a website over HTTPS, the server hands your browser an SSL/TLS certificate — a digital ID card that proves the site is really the site you asked for. That ID card lists the hostnames it is valid for in a field called the Subject Alternative Name (SAN) list. Chrome compares the address in your browser against that list, and if no entry matches, it shows the Your connection is not private warning with the code NET::ERR_CERT_COMMON_NAME_INVALID and refuses to connect.
The confusing part is that the certificate can be completely valid and issued by a trusted authority, yet still trigger this error. Trust is not the problem here — the name is. A certificate issued for example.com is useless when you visit www.example.com, because for certificate purposes those are two different hostnames. The same applies to subdomains: a certificate for example.com does not cover blog.example.com unless that subdomain is listed too. The error is Chrome telling you that the ID card belongs to somebody else, not that the ID card is fake.
There is also a historical twist behind the name. Certificates used to carry the domain in a field called the Common Name (CN), and browsers once accepted it. Chrome stopped doing that in version 58, released in 2017: it now requires a SAN list and ignores the Common Name entirely. So a legacy certificate that lists the domain only in its Common Name — with no SAN extension at all — fails validation even when the name looks exactly right. When you see this error, the SAN list is always where the answer lives.
Common causes
- Missing www or non-www hostname in the SAN list: the certificate covers example.com but not www.example.com (or the reverse), the single most common trigger.
- Uncovered subdomain: the site moved to a subdomain such as shop.example.com or app.example.com that was never added to the certificate.
- Legacy certificate with only a Common Name: an old certificate that lists the domain in the CN field but has no SAN extension, which Chrome no longer accepts.
- Wrong certificate at the CDN, proxy, or load balancer: the edge server serves its default or shared certificate instead of one issued for your domain.
- Public Wi-Fi sign-in portal interception: the portal answers your HTTPS request with its own certificate before you have signed in, producing a genuine name mismatch.
- Antivirus or VPN re-signing traffic: security software that inspects encrypted connections replaces the site's certificate with one of its own, whose names do not match the site.
How to fix ERR_CERT_COMMON_NAME_INVALID — step by step
Work through these fixes in order. Visitors should start with steps 1 through 3; site owners should jump to step 4 once the mismatch is confirmed.
- Confirm the mismatch in the certificate details On the warning page, click Advanced, then click the certificate link (or the Not secure text in the address bar) to open the certificate viewer. Look for the Subject Alternative Name (SAN) list — the hostnames the certificate is actually valid for. Compare that list with the address in your browser. If the address is www.example.com but the SAN list only shows example.com, or the address is shop.example.com but the certificate only covers example.com and www.example.com, you have found the mismatch. Note exactly which hostname is missing, because that is what the new certificate must include.
- Run the quick visitor-side checks First, reload the page and try the other form of the address — if www.example.com fails, try example.com, and vice versa. If one form works, the site's certificate simply does not cover the other, and the fix belongs to the site owner. Next, open an Incognito window with Ctrl + Shift + N (Cmd + Shift + N on a Mac) to rule out extensions and cached data. Also check that your system clock is set to automatic, since a wrong clock can make certificate checks behave strangely. If the error appears on every device and network you try, the certificate itself is wrong — skip to step 4.
- Rule out Wi-Fi portals, antivirus, and VPN interference On a public Wi-Fi network, the sign-in portal can answer your HTTPS request with its own certificate, which belongs to the portal rather than the site — a genuine name mismatch. Sign in to the network, or open a plain http:// page to trigger the portal, then reload. Also test with your antivirus HTTPS scanning paused and your VPN disconnected: software that inspects encrypted traffic re-signs connections with its own certificate, and if that certificate's names do not match the site, Chrome shows this error. If the warning disappears when you switch to your phone's mobile hotspot, the network was the cause.
- Reissue the certificate with every hostname in the SAN list This is the real fix for site owners. Chrome has required Subject Alternative Names since version 58 and ignores the older Common Name field entirely, so a certificate with only a Common Name and no SAN list will fail even if the name looks right. Reissue the certificate and list every hostname it must serve as a SAN: the bare domain and the www version, plus each subdomain that serves the site. For example, a site reachable at example.com and www.example.com needs both names in the SAN list. If you have many subdomains, a wildcard certificate covering *.example.com handles them all — but remember that a wildcard covers only one level, so api.v2.example.com still needs its own explicit entry.
- Fix the certificate at the CDN, proxy, or load balancer If the origin server has the right certificate but visitors still see the error, the wrong certificate is being served at the edge. Check your CDN, reverse proxy, or load balancer: each one terminates TLS with its own certificate, and it must be provisioned for your exact hostname. A CDN serving its default or shared certificate instead of one issued for your domain produces exactly this mismatch. Update the edge certificate to match the origin, then purge the edge cache and reload. Test with an SSL checker such as SSL Labs to confirm the public-facing certificate now lists your hostname.
- Correct the virtual host and the redirect Finally, check the server configuration. A virtual host serving the wrong certificate — for example, the default host catching requests for a domain it was never configured for — hands visitors a certificate issued for a different site. Point the domain's DNS and virtual host at the correct certificate, and make sure the www to non-www redirect (or the reverse) lands on the hostname the certificate actually covers. After any certificate change, wait a few minutes for caches to clear, then reload and confirm the padlock appears with no warning.
Did this fix it? Quick checklist
- The site loads with a padlock icon and no warning page
- The certificate's SAN list includes the exact hostname in your address bar
- Both the www and non-www forms of the address load without warnings
- Antivirus HTTPS scanning and the VPN are back on or reconfigured after testing
If the site loads on mobile data but not on your Wi-Fi, a portal or network device was intercepting the connection — sign in to the portal or switch networks. If one form of the address works and the other does not, the certificate is missing a hostname and the site owner needs to reissue it. And if the error appears only on a work or school computer, the organization's security software is re-signing traffic — ask the IT administrator before changing any settings.
Frequently asked questions
What does ERR_CERT_COMMON_NAME_INVALID mean?
It means the SSL/TLS certificate the server sent does not list the hostname you typed in the address bar. Chrome checks the certificate's Subject Alternative Name (SAN) list against the requested hostname, and if no entry matches, it shows Your connection is not private with the code NET::ERR_CERT_COMMON_NAME_INVALID. The certificate may be perfectly valid and trusted — it is simply issued for a different name than the one you asked for.
Why does my certificate fail even though the Common Name matches?
Because Chrome ignores the Common Name field. Since Chrome 58, the browser requires Subject Alternative Names and checks only the SAN list when matching hostnames, following RFC 2818. A certificate that lists the domain only in its Common Name, with no SAN extension at all, will fail validation even if the name looks correct. The fix is to reissue the certificate with the domain listed as a SAN.
Why does www.example.com fail when example.com works?
Because the www and non-www forms are different hostnames for certificate purposes. A certificate covering example.com does not automatically cover www.example.com. The certificate must list both names explicitly as SANs. Most certificate authorities and Let's Encrypt include both when you request them, but you should always open the certificate viewer and confirm both names are in the SAN list.
Can I fix ERR_CERT_COMMON_NAME_INVALID as a visitor?
Usually not — the names in a certificate are fixed when it is signed, and nothing on your device changes that comparison. What you can do is confirm the problem is really the site: try the site on your phone using mobile data instead of your Wi-Fi. If it fails there too, the server certificate is misconfigured and only the site owner can fix it by reissuing it. The one exception is a public Wi-Fi sign-in portal, which answers HTTPS requests with its own certificate until you sign in — complete the sign-in and reload.
Does a wildcard certificate fix this error for all subdomains?
A wildcard certificate covering *.example.com fixes the error for every single-level subdomain, such as blog.example.com or shop.example.com. It does not cover deeper levels: api.v2.example.com is not matched by *.example.com and needs its own explicit SAN entry. It also does not cover the bare domain example.com itself unless that name is listed separately, so include both the bare domain and the wildcard when you reissue.