NET::ERR_CERT_COMMON_NAME_INVALID

Chrome error when the hostname you typed doesn't match any name on the server's certificate. The user's only fix is the site owner re-issuing the cert.

NET::ERR_CERT_COMMON_NAME_INVALID is the Chrome and Edge error message when the hostname in the URL doesn't match any of the names on the certificate the server sent. Firefox calls the same thing SSL_ERROR_BAD_CERT_DOMAIN. Safari shows "Safari can't verify the identity of the website."

What's actually mismatching

The cert has either a Subject (Common Name, CN) field or a Subject Alternative Names (SAN) list. The browser checks: does the URL's hostname match the CN or any SAN entry? If not, this error fires.

Modern browsers (Chrome 58+, ~2017) ignore the CN field entirely. They only look at SANs. So a cert with CN=foo.com but no SAN entries will fail this check even if you visit foo.com. The cert has to have a SAN.

What it's not

This is not about expired certs (ERR_CERT_DATE_INVALID), untrusted CAs (ERR_CERT_AUTHORITY_INVALID), or revoked certs (ERR_CERT_REVOKED). Those are separate errors. COMMON_NAME_INVALID is purely "the cert exists, is otherwise valid, but doesn't list the hostname you're visiting."

The common causes

User typed www.foo.com but cert only covers foo.com. Wildcard certs and SAN lists are how you fix this. A *.foo.com wildcard cert covers www.foo.com but not the apex foo.com.
User is hitting the IP address. Certs don't usually cover IPs. https://192.168.1.50 will always fail this check unless the cert specifically has the IP as a SAN.
Wrong virtual host served by the server. Multiple HTTPS sites on one IP, server is misconfigured to serve the wrong cert for the requested hostname. Almost always an SNI configuration bug.
Cert reissued for a different hostname. Site owner generated a new cert thinking the old SAN entries would carry over, but they didn't.

For a custom-domain SaaS

When customers report this on their branded URL, check that you provisioned a cert covering the exact hostname they're visiting. Visiting dashboard.customer.com against a cert covering only customer.com triggers this error. The fix is reissuing with the right SAN, not flipping a config setting.