ERR_CERT_COMMON_NAME_INVALID fix: Chrome connection not private

You're browsing to https://internal.company.com and Chrome slaps you with Your connection is not private. The exact error: ERR_CERT_COMMON_NAME_INVALID. This happens most often in internal networks, dev environments, or when you've got a proxy intercepting traffic. I've seen it a hundred times — someone sets up a self-signed cert for server01.local but the URL in the browser is server01 without the domain. Boom, mismatch.

What's actually happening

The SSL certificate was issued for a specific hostname (the Common Name or Subject Alternative Name). When you type a different URL into Chrome, the browser compares the cert's CN/SAN against the address bar. If they don't match — or if the cert's CN is missing entirely — Chrome kills the connection. This isn't a Chrome bug; it's a security feature that's saved your ass more times than you know.

Root causes (pick your poison)

1. Server-side misconfiguration — The web server is presenting a cert for a different domain. Most common on dev boxes or misconfigured IIS/Apache/NGINX.
2. Proxy or VPN interference — Corporate proxies often intercept SSL traffic and replace the cert. If their root CA isn't trusted by your machine, Chrome rejects it.
3. Outdated client or OS — Old versions of Chrome or Windows may not support newer cert formats like SAN-only certs (RFC 6125).
4. DNS mismatch — The domain you're hitting resolves to a different IP than the cert was issued for. Common with load balancers.

Fix it — step by step

Option A: You control the server (most reliable fix)

1. Check the cert's Common Name — On the server, run:

   openssl x509 -in /path/to/cert.crt -text -noout | grep 'Subject:'

   Look for CN = yourdomain.com. That CN must exactly match the URL users type.
2. Add Subject Alternative Names (SANs) — Modern Chrome ignores the CN if SANs exist. Generate a new CSR with SANs for every variant users might type:

   [ req ]
   req_extensions = v3_req
   
   [v3_req]
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = internal.company.com
   DNS.2 = internal
   DNS.3 = 192.168.1.50

   Re-issue the cert with openssl or your CA.
3. Deploy the new cert — Restart the web server. NGINX: sudo systemctl restart nginx. Apache: sudo apachectl restart. IIS: use the MMC console.

Option B: You're the client (temporary workaround — use with caution)

1. Type thisisunsafe — On the Chrome error page, click anywhere on the white space, then type thisisunsafe. Chrome will load the page. This only works for the current tab and session.
2. Add an exception — Click Advanced → Proceed to [site] (unsafe). Chrome will remember this for the session. Not permanent.
3. Install the server's root CA — If it's a self-signed or internal CA, export the root certificate and add it to your system's Trusted Root Certification Authorities. On Windows: double-click the .cer file → Install Certificate → Local Machine → Place in Trusted Root. Restart Chrome.

Option C: Proxy/VPN is the culprit

1. Bypass the proxy — In Chrome's proxy settings, add the internal domain to the exception list. On Windows: Settings → Network & Internet → Proxy → Use proxy server → Advanced → Exceptions. Add *.company.com.
2. Check the proxy cert — Ask your network team to install the corporate root CA on your machine. If they haven't, push back.

Still failing? Check these

• Time sync — If your system clock is off by more than 24 hours, all certs look invalid. Run w32tm /resync on Windows or sudo ntpdate pool.ntp.org on Linux.
• Chrome flags — Open chrome://flags and search for Enable common name fallback. If it's disabled (default), Chrome won't fall back to the CN if SANs exist. That's correct behavior — don't change it.
• Antivirus SSL scanning — Some AV suites (looking at you, McAfee) intercept HTTPS. Disable the HTTPS scanning feature temporarily to test.
• Wildcard certs — A cert for *.example.com will NOT match example.com (no subdomain). You need a separate cert for the bare domain.

If you've done all this and it's still broken, the server's cert is probably flat-out expired or revoked. Check the validity dates with openssl x509 -in cert.crt -noout -dates. That's where I'd start next.