NET::ERR_CERT_COMMON_NAME_INVALID Explained

What Chrome shows

The heading is the usual certificate warning, "Your connection is not private", followed by:

Attackers might be trying to steal your information from <SITE>
(for example, passwords, messages, or credit cards).

NET::ERR_CERT_COMMON_NAME_INVALID

The code appears under "Advanced". This error is overridable, so Chrome normally offers a "Proceed to <SITE> (unsafe)" link next to "Back to safety".

The rule most guides get wrong

The error name mentions the Common Name, and that is misleading, because Chrome does not use it.

Certificates used to carry the hostname in a field called the Common Name, or CN. That was replaced by the Subject Alternative Name field, or SAN, which can hold a whole list of names. Chrome has ignored the Common Name field entirely since Chrome 58.

The consequence is absolute. If a certificate has a Common Name and no SAN entries at all, it will fail in Chrome no matter what the Common Name says. It does not matter that the name looks correct when you inspect the certificate. Chrome never reads that field.

This catches out certificates generated by older tooling, appliances, and internal authorities that were never updated.

Why the hostname does not match

The common cases, in order:

→www versus the bare domain. A certificate issued for example.com does not cover www.example.com. They are different names and both have to be listed.
→A subdomain that was never included. shop.example.com or checkout.example.com needs its own entry, or a wildcard.
→A wildcard that does not stretch as far as you think. A certificate for *.example.com covers shop.example.com, but it does not cover example.com itself, and it does not cover a.b.example.com.
→No SAN entries at all. An old style certificate with only a Common Name. Chrome rejects it outright, as above.
→The wrong site is answering. On shared hosting or behind a proxy, a request can land on a different virtual host and be answered with that host's certificate. The certificate is real, it just belongs to someone else.
→You reached the site by IP address. Certificates are issued for names, not usually for IP addresses, so typing the IP produces a mismatch every time.

If it is your site: reissue covering every name

You cannot edit a certificate to add a name. You have to reissue it.

1.List every hostname you actually serve. The bare domain, the www version, and any subdomain a visitor can land on directly. Check your marketing links and old campaigns for names you forgot about.
2.Reissue the certificate with all of them in the SAN list. Every authority supports multiple names. Free automated authorities do it as standard, and it costs nothing extra.
3.Install it and reload the web server. Issuing is not installing.
4.Keep serving the certificate on the redirecting hostname. If www redirects to the bare domain, the browser still has to complete a secure connection to www before it can follow that redirect, so www must be covered.
5.Test both versions from outside. Load the site with and without www, and use the checker at the top of this page so you see what a real visitor sees.

When it is a genuine warning

Most of the time this is a configuration slip. Occasionally it is the certificate doing exactly what it exists to do.

If the certificate names a completely unrelated business, you may have reached a server that is not the site you intended, whether through a bad link, a lookalike domain, or a hijacked redirect. Read the domain in the address bar character by character before you assume it is harmless.

Our engine reports this case as the certificate does not match this website address, alongside the other reasons it checks for, such as expired or not issued by a trusted authority. That tells you which situation you are in without loading the site. You can read more in our guide to SSL certificates.

Frequently asked questions

Why do I get this on www.example.com but not example.com?

Because those are two different hostnames, and a certificate only covers the names listed inside it. The site owner has a certificate covering one and not the other. Both need to be included in the Subject Alternative Name list, which means reissuing the certificate.

My certificate has the right Common Name. Why is Chrome still rejecting it?

Chrome has ignored the Common Name field since Chrome 58. It reads only the Subject Alternative Name list. A certificate with a correct looking Common Name and no SAN entries will always fail in Chrome, regardless of how it looks when you inspect it. Reissue it with the hostnames in the SAN field.

Does a wildcard certificate cover everything?

No. A wildcard for *.example.com covers one level of subdomain, so shop.example.com works. It does not cover example.com itself, and it does not cover deeper names like a.b.example.com. Most wildcard certificates are issued alongside the bare domain for exactly this reason, but you have to ask for it.

Is it safe to continue past this warning?

Chrome does offer the option, but it is a bad idea on any site where you would enter information. The whole point of the check is confirming you are talking to the site you think you are, and this error means that confirmation failed. If you suspect it is just a www mix up, try the other version of the address instead of clicking through.

Can I get a certificate for an IP address?

A few authorities issue them, but it is unusual and most do not. If you are reaching a server by its IP address, the certificate almost certainly names a hostname instead, and you will get this error every time. Use the hostname.