Navigating to a website in Google Chrome only for the browser to block access with the warning: “Your connection is not private” and error code: NET::ERR_CERT_COMMON_NAME_INVALID prevents secure web browsing. In modern web standards, HTTPS establishes an encrypted TLS session by validating that the server’s SSL certificate matches the exact Fully Qualified Domain Name (FQDN) in the browser address bar. When a certificate’s Common Name (CN) or Subject Alternative Names (SAN) do not align with the requested URL, an outdated DNS record points to a shared hosting IP, or a third-party antivirus proxies SSL connections incorrectly, Chrome terminates the TLS handshake. This tutorial outlines how to diagnose SSL certificate mismatches, flush local SSL state caches, and resolve this connection error.
What Triggers NET::ERR_CERT_COMMON_NAME_INVALID?
Chrome halts connection progress whenever public-key cryptography fails domain identity verification:
- Domain Name Mismatch: The certificate was issued to
example.combut the user accessedwww.example.comwithout matching SAN declarations. - Stale Local DNS and Host Cache: Outdated IP mappings routing traffic to an old server hosting a different website’s SSL certificate.
- Third-Party Antivirus HTTPS Scanning: Security software intercepting web traffic with a locally generated proxy certificate that Chrome rejects.
- Corrupted Windows SSL State: Damaged X.509 certificate revocation lists (CRL) stored in the local Schannel cache.
- Public Wi-Fi Captive Portals: Network gateways attempting to hijack HTTPS requests to display login or agreement pages.
Method 1: Check the Certificate Subject Alternative Names (SAN)
Verifying which domains the certificate legitimately covers reveals whether the error is client-side or server-side.
- On the warning page in Google Chrome, click the red Not secure badge in the address bar.
- Click Certificate is not valid (or Certificate invalid).
- In the Certificate Viewer window, click the Details tab.
- Scroll down and select Extension: Subject Alternative Name.
- Inspect the DNS names listed. If you visited
subdomain.example.combut the SAN list only coversexample.com, the website administrator must re-issue the certificate with wildcard coverage.
Method 2: Clear the Windows SSL State
Purging cached TLS session tickets and local certificates resolves stale authentication records.
- Press Win + R, type
inetcpl.cpl, and press Enter to launch Internet Properties. - Navigate to the Content tab.
- Click the Clear SSL state button.
- Wait for the confirmation message stating: “The SSL certificate cache was successfully cleared.”
- Click OK, restart Google Chrome, and reload the webpage.
Method 3: Flush Local DNS Cache and Chrome Host Resolver
Stale DNS entries frequently point users to old hosting IP addresses bearing obsolete SSL certificates.
- In Chrome, type
chrome://net-internals/#dnsinto the address bar and press Enter. - Click the Clear host cache button.
- Next, press Win + X and select Terminal (Admin) or Command Prompt (Admin).
- Enter the following command and press Enter:
ipconfig /flushdns - Restart your browser and re-test connection.
Method 4: Disable Third-Party Antivirus HTTPS Scanning
Many third-party security suites (such as Avast, AVG, or Bitdefender) inspect encrypted HTTPS traffic by creating local proxy certificates.
- Open your third-party antivirus software dashboard.
- Navigate to Web Protection or Real-time Protection settings.
- Locate options such as Enable HTTPS scanning or Scan secure connections and toggle them off temporarily.
- Refresh Google Chrome to determine whether the certificate error clears.
Method 5: Check System Clock and Time Zone
SSL certificates contain strict Not Before and Not After validity timestamps:
- Right-click the clock in the bottom-right corner of the taskbar and select Adjust date and time.
- Toggle on Set time automatically and Set time zone automatically.
- Click Sync now under Additional settings.