ERR_CERT_COMMON_NAME_INVALID is Chrome’s way of saying: “This certificate exists and looks legitimate, but it wasn’t issued for the domain you’re trying to visit.” The SSL certificate presented by the server and the domain name in Chrome’s address bar don’t match, and Chrome refuses to proceed rather than risk loading content from what might be the wrong server. You’ll find the complete rundown in our Google Chrome Errors.
The “Common Name” in the error refers to the CN field in the certificate — historically, the primary domain the certificate was issued for. Modern certificates use Subject Alternative Names (SANs) instead, which can cover multiple domains and wildcards in a single certificate. Either way: if the domain you’re visiting isn’t covered by what the certificate specifies, you get this error.
Is This a Local Problem or a Server Problem?
That’s the first question, and it has a quick answer. Open the same site in Firefox. If Firefox also shows a certificate mismatch error, the site’s certificate genuinely doesn’t cover the domain you’re visiting — the site owner has a misconfiguration to fix, and there’s nothing you can do locally except wait for them to correct it.
If only Chrome shows ERR_CERT_COMMON_NAME_INVALID while Firefox loads the site normally, something on your machine is causing Chrome to encounter a different certificate than Firefox does. Antivirus SSL scanning, a proxy, a stale cached certificate, or an outdated Chrome version are the local causes. Work through the fixes below.
Fix 1: Check the URL — www vs. Non-www
The most common locally-fixable cause of ERR_CERT_COMMON_NAME_INVALID is a URL mismatch between what you’re visiting and what the certificate covers. SSL certificates must explicitly list every domain variation they cover. A certificate for “example.com” doesn’t automatically cover “www.example.com,” and vice versa — the two are treated as different domains from a certificate perspective.
- If the URL shows www.example.com, try example.com without the www
- If the URL shows example.com, try www.example.com
- If you’re accessing a site by IP address (
https://192.168.1.1), certificates almost never cover IP addresses — use the hostname instead if one is available
Well-configured sites handle this automatically by redirecting to the canonical version. When they don’t, the mismatch is immediately apparent and immediately fixable by adjusting the URL.
Fix 2: Clear SSL State and Chrome’s Certificate Cache
Chrome caches SSL certificate information for performance. If a site recently updated its certificate to cover more domains or to fix a mismatch, Chrome may still be using the old cached certificate — continuing to show ERR_CERT_COMMON_NAME_INVALID even though the server is now presenting a correct certificate. Clearing the cache forces Chrome to fetch fresh certificate information.
- Open Internet Options (search in Start menu) → Content tab → Clear SSL State → OK
- In Chrome: Ctrl + Shift + Delete → All time → tick Cached images and files → Clear data
- Fully restart Chrome (Task Manager → end all Chrome processes → reopen)
- Try the site again
This is particularly worth trying on sites that you know have recently fixed their certificate configuration — if you saw this error yesterday and were told it would be fixed, clearing the cache ensures Chrome isn’t serving you a stale version of the problem.
Fix 3: Check Antivirus SSL Scanning and Proxy
ERR_CERT_COMMON_NAME_INVALID appearing across multiple different sites — rather than on one specific site — almost always means something is intercepting HTTPS traffic and presenting a substitute certificate that doesn’t cover all the domains the real certificates cover.
Antivirus products with HTTPS scanning (called Web Shield, SSL Scanning, or HTTPS Interception in various products) substitute the real certificate with their own. If the antivirus’s certificate isn’t well-configured for a specific domain, Chrome sees a certificate whose Common Name doesn’t match the domain you’re visiting — which is exactly what ERR_CERT_COMMON_NAME_INVALID describes.
- Open your antivirus application and find SSL/HTTPS scanning settings
- Temporarily disable it
- Test the site in Chrome
- If the error is gone: update the antivirus software (this is often a known bug fixed in the latest version), or add the affected site to the antivirus exclusion list
- Also check Windows Proxy: Settings → Network and internet → Proxy → confirm no proxy is configured
- Disconnect any VPN and test — VPN providers with malware protection features use similar HTTPS inspection that can cause this error
Fix 4: Proceed for Trusted Internal Tools
ERR_CERT_COMMON_NAME_INVALID on internal network devices is expected and normal. Your home router’s admin panel (192.168.1.1 or similar), NAS devices, network printers with web interfaces, local development servers, and internal company applications frequently use self-signed certificates that don’t cover the exact hostname or IP you’re using to access them. The certificate may be issued for a generic name like “router.local” while you’re accessing it at its IP address, or vice versa.
For these devices you trust completely and access on your own network:
- On the error page, click Advanced
- Click Proceed to [address] (unsafe)
- Chrome loads the tool and creates a session exception
The “(unsafe)” label sounds alarming but reflects that Chrome can’t verify the certificate’s identity — not that the connection is actively being attacked. On your own local network device, this is a reasonable exception to make. Don’t apply this logic to public-facing sites or sites you’re not completely certain about.
Fix 5: Update Chrome
Chrome’s certificate validation has evolved significantly. Older Chrome versions validate certificates against standards that have since been tightened — some certificates that passed validation in older Chrome versions now correctly fail it in current versions, while other certificates that caused false ERR_CERT_COMMON_NAME_INVALID in older versions are now handled correctly after updates that improved multi-domain SAN certificate handling.
Three-dot menu → Help → About Google Chrome. Chrome checks for and installs updates when this page opens. Restart if prompted. Also verify your system clock is correct (right-click taskbar clock → Adjust date and time → Sync now) — a wrong clock occasionally contributes to certificate validation failures that present as name invalid errors.
This certificate-name mismatch is browser-agnostic: the same site that throws this in Chrome will show the Secure Connection Failed warning in Firefox, where the resolution follows the same logic.
Understanding Wildcard Certificates and Why They Sometimes Cause This Error
Wildcard certificates (*.example.com) cover all subdomains one level deep — mail.example.com, blog.example.com, api.example.com — but they don’t cover the bare domain (example.com itself) or deeper subdomains (api.v2.example.com). This is a common source of ERR_CERT_COMMON_NAME_INVALID on legitimate sites that have a wildcard certificate but haven’t covered all the entry points.
When you see ERR_CERT_COMMON_NAME_INVALID and can view the certificate details (click the “Not secure” padlock → Certificate → Details), the Subject Alternative Names section shows exactly which domains the certificate covers. Comparing that list to the domain you’re trying to visit immediately shows whether the certificate legitimately covers your URL or not. If your URL is missing from the SAN list, that’s the site’s misconfiguration to fix — not something you can address locally.
| Situation | Cause | Fix |
|---|---|---|
| Other browsers also show error | Site’s certificate genuinely misconfigured | Contact site owner; check SAN list |
| www vs. non-www URL | Certificate doesn’t cover both variants | Fix 1 — try URL with/without www |
| Internal router or NAS | Self-signed cert on internal device | Fix 4 — click through after verifying |
| Multiple sites affected | Antivirus or proxy SSL interception | Fix 3 — disable SSL scanning |
| Previously worked, now fails | Cached stale certificate data | Fix 2 — clear SSL state and cache |
The broader SSL error context is covered in our guide on Your connection is not private, which handles all certificate error codes including ERR_CERT_COMMON_NAME_INVALID alongside the date and authority invalid codes. For SSL handshake failures that happen before certificate inspection even occurs, our ERR_SSL_PROTOCOL_ERROR guide covers the protocol negotiation failures that share some root causes. Enterprise certificate scenarios — including custom CAs, certificate pinning, and wildcard SAN configurations — have additional documentation on the Google Chrome support pages.
CDN configurations are a frequent source of ERR_CERT_COMMON_NAME_INVALID that’s worth understanding for site owners debugging their own installations. Content Delivery Networks like Cloudflare, Fastly, and AWS CloudFront issue certificates that cover the CDN’s own domain names and the customer’s domains — but only the domains explicitly configured in the CDN’s certificate provisioning. When a new subdomain is added to a site but the CDN certificate isn’t updated to include it, ERR_CERT_COMMON_NAME_INVALID appears for visitors to that subdomain while the main domain continues to work. This typically resolves within minutes of the CDN provisioning a new certificate through its automated systems (Cloudflare, for instance, provisions Let’s Encrypt certificates automatically), but there’s a brief window where visitors see the error. Refreshing after a few minutes, or using the site’s main domain rather than the newly added subdomain, is usually the practical workaround while the CDN catches up.
Load balancing and multi-server configurations add another layer of complexity. In large-scale deployments, HTTPS requests are distributed across multiple servers, each potentially carrying its own certificate. If one server in the pool has an outdated or misconfigured certificate while others are correct, ERR_CERT_COMMON_NAME_INVALID appears intermittently — sometimes the page loads fine, sometimes it shows the error — depending on which server handles the request. This is a diagnostically confusing situation because the error appears non-deterministically and can look like a client-side problem when it’s actually a server-side inconsistency. If you see ERR_CERT_COMMON_NAME_INVALID intermittently on the same URL, with the error appearing some times and not others without any change on your end, a load-balanced server pool with inconsistent certificates is a likely cause.
Certificate mismatch errors from mobile device hotspots are a specific scenario that trips people up. Some mobile carriers intercept HTTPS connections to compress data and reduce bandwidth costs — a practice called “transparent proxying” or “compression proxying.” When this proxy intercepts your HTTPS connection and presents a certificate for the proxy rather than the destination site, Chrome shows ERR_CERT_COMMON_NAME_INVALID because the proxy’s certificate doesn’t cover the site’s domain. This practice was more common five years ago and has become rarer as carriers have faced regulatory pushback, but it still exists on some carriers and some plan types. Testing whether ERR_CERT_COMMON_NAME_INVALID appears consistently only when connected to a specific mobile network (and disappears on Wi-Fi) confirms whether carrier-level proxying is the cause. If so, the only workarounds are using a VPN (which encrypts the traffic before the carrier can intercept it) or switching carriers.
Mixed content warnings and ERR_CERT_COMMON_NAME_INVALID sometimes appear together on sites that have partially migrated from HTTP to HTTPS. During migration, some resources (images, scripts, stylesheets) may still be served over HTTP or from subdomains that haven’t had their certificates updated. Chrome’s mixed content protection may cause additional certificate-related errors as it handles the partially-migrated content. If you’re debugging a site migration and seeing these errors, checking the browser’s developer console (F12 → Console) shows which specific resources are triggering certificate problems and from which origins, giving you a precise list of what needs to be fixed rather than a vague indication that something is wrong with the certificate.
Let’s Encrypt certificates, which are now extremely common because they’re free and automatically renewed, have a specific characteristic relevant to ERR_CERT_COMMON_NAME_INVALID: they’re issued with a 90-day validity period and must be renewed by an automated system (typically certbot or an ACME client). When the renewal automation fails — because of a server configuration change, a cron job that stopped running, a firewall rule blocking the ACME challenge, or a domain configuration change that breaks the renewal validation — the certificate expires and ERR_CERT_DATE_INVALID appears. But in the period just before expiry, if the renewal automation is generating new certificates for a slightly different set of domains than the current configuration serves, ERR_CERT_COMMON_NAME_INVALID can appear for the domains that dropped out of the renewal scope. Checking the Let’s Encrypt renewal logs on the server and confirming that the certificate being generated covers all the domains currently being served is the diagnostic step for this scenario.
Chrome’s certificate error page actually contains a link to view the certificate in question — click the padlock icon in the address bar (or on older Chrome versions, click “Not secure”), then “Certificate is not valid” or similar, and you can inspect the actual certificate that caused the problem. The Subject Alternative Names field in the certificate details shows exactly which domains the certificate covers. This is the most direct way to understand why ERR_CERT_COMMON_NAME_INVALID is appearing: compare the SANs to the URL you’re visiting and the mismatch is immediately visible. This works even when the “Proceed anyway” option is available — you don’t need to dismiss the error to inspect the certificate. Knowing exactly which SANs are present (and which are missing) provides the specific information needed to either fix a local URL issue (Fix 1) or report a precise misconfiguration to the site owner rather than a vague “your certificate is broken.” If this sounds familiar, How to Fix ERR_NAME_NOT_RESOLVED in Chrome is worth a look.
