How to Fix ‘NET::ERR_CERT_COMMON_NAME_INVALID’ in Google Chrome

When Google Chrome encounters the warning screen “Your connection is not private” accompanied by the specific error code NET::ERR_CERT_COMMON_NAME_INVALID, it means the SSL/TLS digital certificate presented by the website does not match the exact domain name typed into the address bar. Web browsers mandate that a certificate’s Common Name (CN) or Subject Alternative Name (SAN) list matches the requested host to prevent man-in-the-middle impersonation attacks. While this error often occurs on misconfigured websites (such as accessing a site via its raw IP address or forgetting that a wildcard certificate excludes subdomains), it is also regularly caused by stale local DNS records, captive Wi-Fi portal redirects, or proxy software. Resolving this issue involves clearing DNS resolver caches, auditing domain URLs, and verifying certificate parameters.

Why Common Name Mismatches Occur

During the Transport Layer Security (TLS) handshake, the web server delivers its X.509 cryptographic certificate to Google Chrome. Chrome extracts the domain identity listed in the certificate’s Subject Alternative Name extension. If you navigate to https://example.com, but the certificate was issued exclusively for https://www.example.com, or if the server presents a default fallback certificate belonging to its hosting provider (e.g., *.webhost.com), Chrome immediately aborts the connection and displays NET::ERR_CERT_COMMON_NAME_INVALID.

Common causes of this certificate mismatch include:

  • Missing Non-WWW or Subdomain SAN Entries: The website administrator obtaining a certificate that covers www.domain.com but omitting the bare root domain.com. For certificate date errors, see our guide on fixing NET::ERR_CERT_DATE_INVALID in Google Chrome.
  • Accessing a Web Server via Raw IP Address: Entering a server’s public IP (e.g. https://192.0.2.1) when the installed SSL certificate only covers fully qualified domain names (FQDN). For cipher negotiation stalls, see our guide on fixing ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome.
  • Stale Local DNS / Hosts File Mappings: Outdated IP addresses pointing your browser to a decommissioned server hosting completely different SSL credentials. For proxy errors, check our guide on fixing ERR_PROXY_CONNECTION_FAILED in Google Chrome.
  • Public Wi-Fi Captive Portals: Hotel or airport Wi-Fi networks intercepting HTTPS traffic to display sign-in landing pages.
Scenario Requested URL Certificate SAN / CN Handshake Result
Missing Apex Domain https://domain.com www.domain.com Mismatched Name (Triggers Error)
Single-Level Wildcard Exceeded https://sub.blog.domain.com *.domain.com Mismatched Name (Wildcards only cover 1 level)
Direct IP Navigation https://203.0.113.50 example.com Mismatched Name (IP not listed in SAN)
Shared Hosting Fallback https://mysite.com *.cpanel-hosting.net Mismatched Name (SNI negotiation failure)

Method 1: Verify the URL Syntax (WWW vs Non-WWW)

The most common cause of Common Name errors is navigating to a website variation that the server administrator did not include in their multi-domain SSL certificate.

  1. Examine the address bar in Google Chrome.
  2. If you typed https://example.com, add www. to the beginning: https://www.example.com, and press Enter.
  3. Conversely, if you navigated to www.example.com, remove the www. prefix and attempt loading the bare domain.
  4. If the site loads cleanly on one variation, the website administrator simply failed to register both aliases on their certificate.

Method 2: Inspect the Certificate’s Subject Alternative Names

Inspecting the active certificate allows you to see the exact domains the server is legally certified to represent.

  1. On the Chrome warning screen, click Advanced.
  2. Click the red warning link reading Certificate invalid (or click the tune icon beside the URL in the address bar and select Certificate is not valid).
  3. In the Certificate Viewer dialogue, navigate to the Details tab.
  4. Scroll through the fields and click Extension: Subject Alternative Name.
  5. Read the listed DNS Names. If your requested URL is absent from this list, the web server is delivering the wrong certificate, or your DNS is directing traffic to the wrong host.

Method 3: Flush DNS Cache and Clear Chrome Host Cache

If a website recently updated its IP address or migrated hosting providers, your computer may still query an old IP address presenting obsolete certificates.

  1. Press Win + S, type cmd, right-click Command Prompt, and select Run as administrator.
  2. Execute the DNS flush command:
    ipconfig /flushdns
  3. Next, open Google Chrome and navigate to the internal socket page:
    chrome://net-internals/#dns
  4. Click the button labelled Clear host cache.
  5. Navigate to chrome://net-internals/#sockets and click Flush socket pools.
  6. Close and reopen Chrome, then test the website again.

Method 4: Check and Clean the Windows Hosts File

Manual IP overrides configured in the Windows hosts file force Chrome to connect to specific IP addresses, bypassing public DNS records.

  1. Press Win + S, type notepad, right-click Notepad, and select Run as administrator.
  2. Click File > Open and navigate to:
    C:\Windows\System32\drivers\etc\
  3. Change the file type dropdown from Text Documents (*.txt) to All Files (*.*).
  4. Select and open the hosts file.
  5. Review the bottom of the file. If entries map your problematic domain to an IP address, delete those lines.
  6. Click File > Save, then restart your browser.

Method 5: Check Captive Wi-Fi Portals on Public Networks

Public Wi-Fi networks in hotels, cafes, and airports intercept your initial web requests to display terms-of-service splash screens. Because the portal cannot forge the SSL certificate of your destination site, Chrome throws this error.

  1. Open a new browser tab in Chrome.
  2. Navigate to a non-HTTPS plain HTTP website, such as:
    http://neverssl.com
  3. The network router will intercept the unencrypted HTTP request cleanly and display the Wi-Fi authentication portal.
  4. Agree to the terms, sign in, and complete network authorization. Once the internet connection is active, reload your secure HTTPS websites normally.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.