Chrome 'Your connection is not private' NET::ERR_CERT_COMMON_NAME_INVALID fix

1. Wrong domain name or subdomain mismatch

What's actually happening here is that the SSL certificate on the server was issued for www.example.com, but you typed example.com (without the www). Or vice versa. Chrome sees the certificate's common name field — that's the domain it was issued to — and compares it to the URL in your address bar. If they don't match exactly, Chrome throws NET::ERR_CERT_COMMON_NAME_INVALID.

This is the most common cause, and it's especially frequent on smaller sites that use a single-domain certificate instead of a wildcard one (*.example.com).

How to fix it

1. Check the URL you're visiting. If you're on example.com, try www.example.com. If you're on www.example.com, try without the www. Just add or remove the subdomain.
2. If that works, the site's admin should either redirect all traffic to the correct domain or buy a wildcard SSL certificate. But that's their problem, not yours.
3. On your end, you can bookmark the correct version of the site so you don't hit this again.

I see this all the time with local businesses running cheap shared hosting. Their cert covers www.bobsplumbing.com but they printed bobsplumbing.com on their flyers. Users type it without www and get this error. The fix is always on the server side, but the workaround is just adding the www.

2. Outdated or incorrect system clock

The reason this causes a certificate error is that SSL certificates have a validity period — they're not valid before a certain date and expire after another. Your computer's clock tells Chrome what the current date is. If your clock is wrong — say it's set to 2022 or 2028 — Chrome thinks the certificate is either not yet valid or expired.

This happens more than you'd think. Dual-boot systems are notorious for this: Windows uses local time, Linux uses UTC, and every time you switch OSes, the clock gets corrupted. Also, dead CMOS batteries on desktops will reset the clock every time you power off.

How to fix it

1. On Windows 10/11: Right-click the clock in the taskbar → Adjust date/time. Toggle Set time automatically on. If it's already on, toggle it off, wait 5 seconds, then toggle it back on. This forces a sync with time.windows.com.
2. On macOS: System Settings → General → Date & Time. Toggle Set time and date automatically on.
3. On Linux (systemd): Run sudo timedatectl set-ntp true and then sudo timedatectl status to verify.
4. After syncing, close Chrome completely and reopen it. Chrome caches certificate validation results, so a simple tab refresh won't cut it.

If the clock keeps drifting, replace the CMOS battery on your motherboard (CR2032 coin cell, costs about $2). You shouldn't have to, but here we are.

3. ISP or corporate proxy intercepting SSL traffic

This is the sneaky one. Some ISPs, hotel Wi-Fi portals, or corporate networks intercept HTTPS traffic by replacing the original site's certificate with their own. They do this for content filtering, bandwidth shaping, or just plain snooping. But they don't always configure it correctly. The replacement certificate's common name won't match the site you're visiting, and Chrome catches it.

You'll often see this on public Wi-Fi — Starbucks, airports, hotel lobbies — where the captive portal redirects you before you've authenticated. But it can also happen on your home network if your ISP uses transparent proxies (looking at you, some rural satellite providers).

How to fix it

1. On public Wi-Fi: Try to open a new tab and visit http://example.com (note: HTTP, not HTTPS). This often triggers the captive portal login page. Authenticate there, then go back to the original site.
2. On a corporate network: You need the company's root CA certificate installed in your system's trust store. Talk to your IT department. They should have pushed this via Group Policy or MDM. If they haven't, that's their screw-up, not yours.
3. On your home network with a suspect ISP: Try using a VPN. A VPN encrypts your traffic before it leaves your device, so the ISP can't inject their proxy. If the error disappears with the VPN on, your ISP is the culprit. Consider switching providers.
4. As a last resort (don't do this habitually): You can bypass the error by clicking Advanced on the error page and then Proceed to [site] (unsafe). But this only works for that one visit, and Chrome will warn you again next time. That's by design — Chrome is doing its job.

The real fix is to get the network admin to deploy a properly signed certificate. If you're on a public network and can't authenticate, just move to a different network. That's the nuclear option, but it works.

Quick-reference summary

These three causes account for about 95% of NET::ERR_CERT_COMMON_NAME_INVALID occurrences on sites that should be legitimate. Start with the URL check, then the clock, and only dig into the network stuff if those don't work. You'll be unblocked in under a minute.