Creating self signed certificate for domain and subdomains - NET::ERR_CERT_COMMON_NAME_INVALID
Solution 1
As Rahul stated, it is a common Chrome and an OSX bug. I was having similar issues in the past. In fact I finally got tired of making the 2 [yes I know it is not many] additional clicks when testing a local site for work.
As for a possible workaround to this issue [using Windows], I would using one of the many self signing certificate utilities available.
Recommended Steps:
- Create a Self Signed Cert
- Import Certificate into Windows Certificate Manager
- Import Certificate in Chrome Certificate Manager
NOTE: Step 3 will resolve the issue experienced once Google addresses the bug...considering the time in has been stale there is no ETA in the foreseeable future.**
As much as I prefer to use Chrome for development, I have found myself in Firefox Developer Edition lately. which does not have this issue.
Hope this helps :)
Solution 2
Chrome 58 has dropped support for certificates without Subject Alternative Names.
Moving forward, this might be another reason for you encountering this error.
Solution 3
A workaround is to add the domain names you use as "subjectAltName" (X509v3 Subject Alternative Name). This can be done by changing your OpenSSL configuration (/etc/ssl/openssl.cnf
on Linux) and modify the v3_req
section to look like this:
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net
With this in place, not forget to use the -extensions v3_req
switch when generating your new certificate. (see also How can I generate a self-signed certificate with SubjectAltName using OpenSSL?)
Solution 4
Create openssl.conf
file:
[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = Cary
L = Cary
O = BigCompany
CN = *.myserver.net
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net
Run this comand:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
Output files app.crt
and app.key
work for me.
Solution 5
Your wildcard *.example.com
does not cover the root domain example.com
but will cover any variant on a sub-domain such as www.example.com
or test.example.com
The preferred method is to establish Subject Alternative Names like in Fabian's Answer but keep in mind that Chrome currently requires the Common Name to be listed additionally as one of the Subject Alternative Names (as it is correctly demonstrated in his answer). I recently discovered this problem because I had the Common Name example.com
with SANs www.example.com
and test.example.com
, but got the NET::ERR_CERT_COMMON_NAME_INVALID
warning from Chrome. I had to generate a new Certificate Signing Request with example.com
as both the Common Name and one of the SANs. Then Chrome fully trusted the certificate. And don't forget to import the root certificate into Chrome as a trusted authority for identifying websites.
Related videos on Youtube
Zed
Updated on July 08, 2022Comments
-
Zed almost 2 years
I followed this tutorial for creating Signed SSL certificates on Windows for development purposes, and it worked great for one of my domains(I'm using hosts file to simulate dns). Then I figured that I have a lot of subdomains, and that would be a pain in the ass to create a certificate for each of them. So I tried creating a certificate using wildcard in
Common
field as suggested in some of the answers at serverfault. Like this:Common Name: *.myserver.net/CN=myserver.net
However, after importing this certificate into Trusted Root Certification Authority, I'm getting
NET::ERR_CERT_COMMON_NAME_INVALID
error in Chrome, for main domain and all of its subodmains, for example:https://sub1.myserver.net
andhttps://myserver.net
.This server could not prove that it is myserver.net; its security certificate is from *.myserver.net/CN=myserver.net.
This may be caused by a misconfiguration or an attacker intercepting your connection.
Is there something wrong in Common Name field that is causing this error?
-
Alex Vasilev about 6 yearsSpent much time trying to fix this too. See my answer here stackoverflow.com/questions/42816218/…
-
-
Philip about 9 yearsThe bug you linked to is A) only valid for OS X, and B) concerns domains with a trailing ".", neither of which are valid for @Zed.
-
Thomas.Donnelly about 9 yearsHmm which link would that be?
-
Philip about 9 yearsThe link to the chromium bug (98627)
-
Thomas.Donnelly about 9 yearsRegardless the fix I proposed works on Windows too as I have used it many times.
-
serraosays over 7 yearsIf anyone reading this uses Pantheon for hosting, they seem to reconstitute the common name associated with your cert when you upload it into their platform, creating this problem. You have to test against the custom static IP they give you to see if the cert's common name remained intact during the setup.
-
bossi about 7 yearsThe usage of
subjectAltName = @alt_names
totally solved my issue. I had previously bound the DNS identity to my domain by providing it thoughCN=*.example.com
. SettingDNS.1 = example.com
andDNS.2 = *.example.com
did the trick. Weird thing (for me) was that it all worked until ~2017-03-17 and stopped a day after (had run a large batch of Windows udates). Nothing broke for me on Linux though, this was only Chrome, Firefox on Windows. -
Pawel Kraszewski about 7 years@bossi: Unfortunately I have this problem on Chrome/Ubuntu. And cert is nothing fancy, single host, single DN (internal GitLab repository).
-
Pawel Kraszewski about 7 yearsIt worked a week or so ago, nothing changed on server. 2 other servers started to rant due to upper-lower case mismatch (cert is uppercase, Chrome drops address to lowercase)
-
Tobias J about 7 years@bossi I bet your Windows version is on the beta track, right? Chrome has deprecated certs without a
subjectAltName
as of Chrome 58 which is currently in beta. This bit me hard because not only had I not seen anything about it, but the error name is very misleading (it's not the common name that's invalid!) I was the opposite of you; it happened only on Linux for me so I spent hours trying to fix my local cert store there. -
Tobias J about 7 years@PawelKraszewski sounds like you also have the same issue; are you on Chrome 58 beta? See my note above; matching on
commonName
is now removed. -
Pawel Kraszewski about 7 years@TobyJ
58.0.3029.19 beta (64-bit)
it is. I've regenerated cert tree with correctsubjectAltName
-s and everything works now. And I agree, the error message is very misleading, as it is notCommonName
that is invalid. If the message read "Certificate is missing a propersubjectAltName
", everybody would be much more happy. -
Tobias J about 7 years@PawelKraszewski well here's the power of open source I suppose, I found the Chromium issue where they discussed this, and complained about the error message being unclear, so they've agreed to make it better (I guess it was actually a bit difficult to change that message from the point where they detected the error): bugs.chromium.org/p/chromium/issues/detail?id=308330
-
bossi about 7 years@PawelKraszewski I'd always go for lower case or lower camelCase for anything config related unless the context prescribes caps explicitly. using `alt_names doesn't work for you? Does the console say anything more specific?
-
bossi about 7 years@TobyJ Yeah you're spot on, I'm on Chrome/beta (58.0.3029.19 currently), Firefox/stable though (52.0.1) on my Win. FF seems to have dropped support for the domain name in the CN field as well. I guess the error message makes sense from a historic point of view if the general change has indeed been from domain identifier in
CN
field tosubjectAltName
only but this way it's confusing now. I'm sure it'll get addressed if it's really a recent shift. -
Pawel Kraszewski about 7 years@bossi: as the mixed case issue is on a very sensitive server and I'm the only one peeking at it via browser (this is mainly a REST server for headless devices), I'd rather not touch anything - being aware the message about mismatch is a legit one and certs use a private CA anyway.
-
carlosvini almost 7 yearsThis guide helped me create a self-signed certificate on Mac OSX: alexanderzeitler.com/articles/…
-
TheFrost almost 7 years@PawelKraszewski now (v59) when you click on "advanced" while on error page you can read more info about it and there is: incorrect
subjectAltName
. -
Ben Johnson over 6 yearsBrilliant! "Your wildcard *.example.com does not cover the root domain example.com but will cover any variant on a sub-domain such as www.example.com or test.example.com." This was precisely the problem in my case. The fix was simply to include both
DNS.1 = example.com
andDNS.2 = *.example.com
under[alt_names]
inopenssl.cnf
. -
Ash over 6 years"As much as I prefer to use Chrome for development, I have found myself in Firefox Developer Edition lately. which does not have this issue." couldn't agree more here..
-
Sharpiro almost 6 yearsdespite the error saying nothing about subject alternative names, this fixed my issue. Thanks!
-
Artem Stepin over 5 yearsThere is a typo in
DNS.1 = *.myserver.net
. Should beDNS.2 = *.myserver.net
. Works just fine for me. -
George over 5 yearsif you are on windows this can be done using openssl installed with git by using a cmd running as admin and the following location : "C:\Program Files\Git\usr\bin\openssl.exe" req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
-
Esqarrouth about 5 yearsI wrote CN = localhost, DNS.1 = localhost, DNS.2 = *.localhost:8080 and it is not working for me. What else should I be changing?
-
Timathon almost 3 yearsThis works in my angular app. Thanks James.
-
Ryan almost 3 yearsI haven't been able to get this working. (Chrome still says that the certificates are untrusted.) And I wonder why it says
default_keyfile = oats.key
.