Error “net::ERR_CERT_COMMON_NAME_INVALID” for self-signed certificate (SOLVED)

net::ERR_CERT_COMMON_NAME_INVALID in Google Chrome

Let's look at how to fix the error “net::ERR_CERT_COMMON_NAME_INVALID”, which occurs for a self-signed certificate.

Full text of the error:

Your connection is not private
Attackers might be trying to steal your information from hackware.local (for example, passwords, messages, or credit cards). Learn more about this warning
net::ERR_CERT_COMMON_NAME_INVALID
Turn on enhanced protection to get Chrome's highest level of security
This server could not prove that it is hackware.local; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.

Proceed to hackware.local (unsafe)

This error can occur both when accessing a site on the Internet, and for a local site for which you created an SSL certificate, for example, to test HTTPS settings.

On the Internet, the most common cause of this error is a mismatch between the domain name for which the certificate was issued and the name you use to connect to the web server. To make it clearer, for example, you access a website by specifying the IP address in the browser line instead of the domain name. Or the domain name does not match the certificate – this can also happen for various reasons, for example, I have encountered such examples on virtual hostings, when a hoster's certificate is used for those sites that have not configured HTTPS, but are accessed via the HTTPS protocol.

Simply put, the error “net::ERR_CERT_COMMON_NAME_INVALID” for sites on the Internet is most likely not your headache (unless, of course, you are the owner of the problematic site).

How to fix “net::ERR_CERT_COMMON_NAME_INVALID” for a self-signed certificate

This note is dedicated to the error “net::ERR_CERT_COMMON_NAME_INVALID” that occurs on a local computer or server for which you generated a self-signed SSL certificate.

Note: in order for a self-signed certificate to be perceived by web browsers as signed by a trusted source, the certificate of the local Certification Authority (CA) must already be added to the trusted ones. However, if you encounter the error “net::ERR_CERT_COMMON_NAME_INVALID”, most likely, the certificate of the local Certification Authority (CA) has already been added to trusted ones, otherwise the error would be different.

So, you created a certificate specifying the domain name (host name) correctly, but the error “net::ERR_CERT_COMMON_NAME_INVALID” still occurs.

If you read the message carefully, it clearly says – incorrect Common Name (CN).

Common Name in the certificate is the same field in which the domain name is stored. That is, you might think that the domain name (host name) is specified with an error.

If you click on the message “net::ERR_CERT_COMMON_NAME_INVALID”, additional information will be shown, including the “Subject” field:

Subject: hackware.local

You can compare the Subject value with the domain name entered in the site's address bar.

Web browsers use the host name from the Subject Alternative Name (subjectAltName)

But no matter how much you double-check the Common Name (CN) and maybe even re-create the certificate without typos in the Common Name, none of this will help you. The fact is that the error message shows the wrong reason. Now web browsers compare the domain name in the address bar and the name of the domain for which the certificate is valid, taking it from the Subject Alternative Name field.

That is, even if you create a certificate with the correct Common Name (CN), it will still cause the error “net::ERR_CERT_COMMON_NAME_INVALID”.

To fix the “net::ERR_CERT_COMMON_NAME_INVALID” error, create a certificate with a Subject Alternative Name extension. It's pretty simple.

The Subject Alternative Name extension is NOT added when creating a certificate signing request, but when signing a certificate. That is, the private key and certificate signing request are generated in the usual way.

Before creating a self-signed certificate, you need to create a file with the Subject Alternative Name settings (subjectAltName). I chose extraoptions.ext as the file name, but you can choose any other. Example of file syntax (for the hackware.local domain):

subjectAltName = DNS:hackware.local

After DNS, you need to specify the host name. You can also specify the host name with wildcards. If there are several values, they are separated by commas:

subjectAltName = DNS:*.hackware.local, DNS:hackware.local

Then, at the stage of signing the certificate, you need to specify the -extfile option and then the name of the file where you saved the settings:

openssl x509 -req -in DOMAIN.NAME.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out DOMAIN.NAME.crt -days 500 -sha256 -extfile extraoptions.ext

Also see the details in the article: How to add Subject Alternative Name (subjectAltName) to a self-signed certificate

Now after creating a self-signed certificate, move it to the SSL certificates directory of the web server and restart the web server for the changes to take effect. In a web browser, it is recommended to use the Ctrl+F5 combination to reload the page to force a new version of the page to be loaded, without using the web browser cache.

That's it – the problem is solved! The connection is now marked as secure.