ERR_CERT_COMMON_NAME_INVALID: What It Means and How to Fix It

ERR_CERT_COMMON_NAME_INVALID means the website presented a real, unexpired certificate, but that certificate was issued for a different name than the one in your address bar. Chrome compares the domain you requested against the hostnames listed in the certificate's Subject Alternative Name (SAN) field. If none of them match, Chrome blocks the page with this error. The fix depends on who you are: as a visitor you can usually resolve or safely judge it in minutes, while as a site owner you need to reissue or reconfigure a certificate. This guide covers both, with data on how common each cause really is.

What the error actually means

Every public HTTPS certificate carries a list of hostnames it is valid for, stored in the SAN extension. Browsers historically also accepted the certificate's Common Name (CN) field, which is where this error got its name. That fallback is long gone:

• RFC 2818 deprecated CN matching for HTTPS back in the year 2000.
• Chrome 58 removed CN matching entirely in April 2017 and has required SAN entries ever since (source: Chrome for Developers, "Deprecations and Removals in Chrome 58"). At the time, only about 0.1% of all certificate validations still relied on the CN fallback (Chromium security-dev, 2017).
• RFC 9525 (November 2023), which replaced RFC 6125, made it formal across the industry: clients must check the SAN extension only and must not match domain names against the CN.

So despite its name, this error really means "SAN mismatch": nothing in the certificate's name list covers the host you asked for.

It is also remarkably common. In Google's study of over 300 million real-world Chrome certificate warnings (Acer et al., "Where the Wild Warnings Are", ACM CCS 2017), name mismatch was the single largest server-side cause of certificate warnings on desktop: 11.7% of all warning reports on Windows and 11.6% on Mac, ahead of untrusted authorities and expired certificates.

Server-side causes of Chrome certificate warnings as a share of all warning reports on Windows. Data: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.

The 7 common causes, and who can fix them

Within name mismatches, subdomain mistakes stand out. In the same Google dataset, 13.2% of server name-mismatch errors were requests for subdomains outside a wildcard's scope, and 3.7% were plain www mismatches (Acer et al., CCS 2017). A further 3.8% of name mismatch errors matched known captive portal patterns, which means the network, not the website, caused them.

If you are a visitor: 5 quick checks

1. Try the other form of the address. If example.com fails, try www.example.com, or the reverse. If one works, the site has a www mismatch and you can tell the owner exactly that.
2. Look at who the certificate was issued to. Click the padlock or "Not secure" chip, open certificate details, and read the SAN list. A certificate for a hosting company's placeholder domain or a completely unrelated site explains the block instantly.
3. On public Wi-Fi, trigger the login page first. Captive portals intercept your first HTTPS request and answer with their own certificate. Open any plain HTTP page (for example a router status page or neverssl.com), complete the portal login, then retry.
4. Test with HTTPS inspection off. Some antivirus suites and corporate proxies re-sign TLS traffic. Temporarily disable HTTPS scanning or try another network; if the error disappears, the interception software is the cause.
5. Do not click through on sites that matter. For banking, email, or anything with a login, treat a name mismatch as a hard stop. The generic version of this warning is covered in our guide to the "Your connection is not private" error.

If you own the site: diagnose, then fix

Start by reading exactly which names your certificate covers. From any terminal with OpenSSL installed:

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

Run it twice, once with your apex domain and once with www, and compare the SAN output against every hostname your users actually visit. Then fix the cause you find:

• Cover the apex and www together. Issue one certificate that lists both names. Let's Encrypt includes up to 100 hostnames per certificate at no cost (Let's Encrypt rate limit documentation), and every commercial CA sells multi-domain SAN certificates.
• Mind wildcard scope. A wildcard matches exactly one label, per RFC 9525:

• Fix SNI and the default virtual host. If your server hosts several sites, make sure each hostname is tied to its own certificate and that the default (fallback) virtual host does not answer with the wrong one for clients or bots that omit SNI.
• Check both ends of your CDN. With a CDN or reverse proxy in front, the edge certificate must cover your public hostname and the origin certificate must cover the origin hostname the CDN connects to. A mismatch on either leg triggers errors.
• Do not rely on redirects. TLS is negotiated before any HTTP redirect is sent. Even if example.com immediately redirects to www.example.com, the certificate served on example.com must still cover that name.

One more reason to automate: under CA/Browser Forum ballot SC-081v3 (adopted April 2025), the maximum public certificate lifetime dropped from 398 to 200 days on March 15, 2026, falls to 100 days in March 2027, and reaches 47 days in March 2029. Renewals are becoming far more frequent, and every renewal is a fresh chance for a SAN list to silently lose a name. Use ACME automation and monitor your coverage instead of trusting memory.

FAQ

Is it safe to click "Proceed anyway"?
Only when you positively know why the mismatch exists, for example your own test server reached by IP address. On any site where you would type a password or payment details, do not proceed.

Does this error mean the site was hacked?
Almost never. It usually means a configuration mistake: a renamed domain, a forgotten www entry, or a wildcard that does not stretch as far as the owner thought. Attacks exist, which is exactly why browsers refuse to guess.

Why is it called "common name" if browsers ignore the CN field?
The name is historical. Browsers matched the CN field until RFC 2818 (2000) deprecated it and Chrome 58 (April 2017) removed it. Today only the SAN list counts, per RFC 9525 (November 2023), but the error identifier was never renamed.

Do I need a separate certificate for every subdomain?
No. One certificate can list many SAN entries, and a wildcard covers all direct subdomains at one level. You only need extra planning for deeper levels like a.b.example.com, which a single-level wildcard does not cover.

Check your certificate coverage in 60 seconds

A name mismatch is invisible until someone hits the one hostname you forgot. FortifyNet's free scan reads your live certificate and reports which names it covers, alongside your TLS configuration, security headers, DNS, email authentication, and dark-web exposure. Run the free scan on your domain and check apex, www, and subdomains in one pass.

Related guides

• "Your connection is not private": what it means and how to fix it
• ERR_CERT_AUTHORITY_INVALID: what causes it and how to fix it
• ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it

Originally published at fortifynet.com/blog/err-cert-common-name-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.