Encountering Google Chrome’s stark red warning screen—“Your connection is not private. Attackers might be trying to steal your information from [domain] (for example, passwords, messages, or credit cards)”—can be alarming. Accompanied by diagnostic error strings like NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_DATE_INVALID, or NET::ERR_CERT_AUTHORITY_INVALID, this warning indicates an SSL/TLS cryptographic handshake failure.
While this barrier protects users from active man-in-the-middle attacks on unsecured public networks, in the vast majority of daily instances, the error is caused by a harmless local misconfiguration, such as a skewed system clock, corrupted local SSL caches, or overzealous antivirus firewalls. Follow these steps to resolve it quickly.
Step 1: Check and Calibrate Your System Date & Time
Digital SSL certificates are cryptographically signed with strict validity start and expiration timestamps. If your computer’s clock deviates by even an hour from real-world time, Chrome will automatically flag the certificate as expired or invalid:
- Right-click the clock in the bottom right corner of your Windows taskbar and choose Adjust date and time.
- Verify that “Set time automatically” is toggled ON.
- Verify that “Set time zone automatically” is toggled ON.
- Scroll down and click the button Sync now to synchronize your clock with Microsoft time servers (
time.windows.com). - Return to Chrome and refresh the problematic web page.
Step 2: Clear the Windows SSL State Cache
Windows stores cryptographic certificate handshakes in a local cache. When a website updates or renews its SSL certificate, a stale local cache can continue presenting the expired key:
- Press Windows Key + R to open the Run dialog box.
- Type
inetcpl.cpland press Enter to open the classic Internet Properties panel. - Switch to the Content tab at the top.
- Click the button labeled Clear SSL state.
- A notification will confirm: “The SSL cache was successfully cleared.” Click OK and restart Chrome.
Step 3: Temporarily Pause Antivirus HTTPS/SSL Scanning
Third-party security suites (such as Avast, Bitdefender, Kaspersky, or ESET) inspect encrypted HTTPS traffic by inserting their own intermediate security certificate between your browser and the web. If this internal certificate breaks, every single secure website will throw ERR_CERT_AUTHORITY_INVALID:
- Open your antivirus control center.
- Navigate to Web Protection or Network Shield settings.
- Temporarily disable “HTTPS Scanning”, “Scan Encrypted Connections”, or “SSL Filtering”.
- Reload the website in Chrome to verify if the certificate warning disappears.
Step 4: Test in Incognito Mode and Check Extensions
Certain proxy, privacy, or rogue VPN extensions modify browser security headers, triggering false-positive SSL flags:
- Press Ctrl + Shift + N to launch an Incognito window.
- Try loading the website. If it opens without error, an installed extension is causing the conflict.
- Navigate to
chrome://extensions, disable all extensions, and re-enable them one by one to find the faulty tool.
Frequently Asked Questions (FAQ)
Is it safe to click ‘Proceed to website (unsafe)’?
Only bypass the warning if you are accessing a trusted internal network device (such as your home router’s admin portal at 192.168.1.1 or a local development server). Never bypass this warning when entering payment details or passwords on unknown public websites.
What does NET::ERR_CERT_COMMON_NAME_INVALID mean?
This code means the domain name listed in the website’s certificate does not match the actual URL in your address bar (for example, the certificate was issued for subdomain.example.com but you visited example.com). It usually indicates a web server misconfiguration on the website owner’s end.
Summary
Resolving ‘Your connection is not private’ errors in Chrome is simple. Calibrate your Windows system clock, clear the Windows SSL state, and verify antivirus HTTPS inspection settings to restore safe, uninterrupted web browsing.
Written by Alex Carter
Alex Carter is a senior systems specialist and technical writer with over 8 years of hands-on experience in Windows diagnostics, network protocols, and software troubleshooting.
