Webgui Https error NET::ERR_CERT_COMMON_NAME_INVALID

[q_fleuren]

Dear people,

Just watched this video
https://www.youtube.com/watch?v=OT1Le5VQIc0

It explains how to make CA's and Certs for SSL/TLS

Following the steps its
Create internal CA
*common name random

export certificate and import into browser under trusted ca's
create internal Certificate.
*common name ip.

Reaching the webgui with edge works.
reaching the webgui with chrome (mainbrowser) gives a crossed out lock with following error.
NET::ERR_CERT_COMMON_NAME_INVALID


Did i miss something or is this just not working? and if its not working why do they have a video with a broken guide? ?
Can somebody point me in the right direction?

 

[dlavigne]

Sounds like a Chrome issue.

Did you try the steps in their FAQ?

 

[q_fleuren]

Sounds like a Chrome issue.

Did you try the steps in their FAQ?

None of those steps worked.

 

[danb35]

NET::ERR_CERT_COMMON_NAME_INVALID

This error means that the hostname you're trying to reach in your browser doesn't match the hostname(s) on the cert presented by your server. Starting with version 58 of Chrome, Chrome doesn't look to the Common Name field of a certificate, it looks only to the subjectAlternativeName field (see https://support.google.com/chrome/a/answer/7391219?hl=en). So, you'll need to generate a certificate with the hostname/IP in that field. Certificates generated by Let's Encrypt do this automatically.

 

[Spearfoot]

Dear people,

Just watched this video
https://www.youtube.com/watch?v=OT1Le5VQIc0

It explains how to make CA's and Certs for SSL/TLS

Following the steps its
Create internal CA
*common name random

export certificate and import into browser under trusted ca's
create internal Certificate.
*common name ip.

Reaching the webgui with edge works.
reaching the webgui with chrome (mainbrowser) gives a crossed out lock with following error.
NET::ERR_CERT_COMMON_NAME_INVALID


Did i miss something or is this just not working? and if its not working why do they have a video with a broken guide? ?
Can somebody point me in the right direction?

Did you define one or more Subject Alternative Name (SAN) settings when you created your certificate?

I recently created new certificates for all of my systems because modern browsers require a SAN instead of just the Common Name (CN) matching the fully-qualified domain name, like they used to. It's fairly simple to do; you need to add the SAN settings to your OpenSSL configuration file. I did this using the v3_req settings much like those shown here:

Code:

[ req ]
default_md = sha256
encrypt_key = yes
distinguished_name = req_dn
req_extensions = v3_req
prompt = no
[ req_dn ]
C=US
ST=NY
L=New York City
O=spoof.net
OU=Security Unit
CN=boxer.spoof.net
emailAddress=postmaster@spoof.net
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[ alt_names ]
DNS.0 = boxer
DNS.1 = boxer.spoof.net
DNS.2 = *.spoof.net

Where boxer is the short hostname of your FreeNAS server. Replace as needed, along with the bogus domain of spoof.net.

When you run openssl to generate the certificate, you'll need to add -extensions v3_req to the command, like this:

Code:

  openssl x509 -req -days $(CERT_DAYS) -in $(CSR_FILE) -CA $(CA_CER) -CAkey $(CA_KEY) -CAcreateserial -CAserial $(CA_SRL) -out $(CRT_FILE) -extfile $(OPENSSL_CONF_FILE) -extensions v3_req

I use make to create the certificates; the $() items are all makefile macros that define the various options. I hope they're more-or-less self-explanatory.

Hope this is enough to get you pointed down the right path. Good luck!

 

[q_fleuren]

This error means that the hostname you're trying to reach in your browser doesn't match the hostname(s) on the cert presented by your server. Starting with version 58 of Chrome, Chrome doesn't look to the Common Name field of a certificate, it looks only to the subjectAlternativeName field (see https://support.google.com/chrome/a/answer/7391219?hl=en). So, you'll need to generate a certificate with the hostname/IP in that field. Certificates generated by Let's Encrypt do this automatically.

Watch the stars
In cert ip is given as common name
Or should both ca and cert common name be ip?

 

[danb35]

The CA common name doesn't matter. But the cert needs to have the IP (or hostname--whatever you're entering in the browser's address bar) included in the subjectAlternativeName field as well. It looks like FreeNAS 11 supports this field (https://bugs.freenas.org/issues/23844, https://bugs.freenas.org/issues/23130), but 9.10 does not and won't (https://bugs.freenas.org/issues/24370). However, the manual (http://doc.freenas.org/11/system.html#certificates) doesn't indicate that the SAN field is available as it seems it should be.

Which version of FreeNAS are you using?

 

[q_fleuren]

The CA common name doesn't matter. But the cert needs to have the IP (or hostname--whatever you're entering in the browser's address bar) included in the subjectAlternativeName field as well. It looks like FreeNAS 11 supports this field (https://bugs.freenas.org/issues/23844, https://bugs.freenas.org/issues/23130), but 9.10 does not and won't (https://bugs.freenas.org/issues/24370). However, the manual (http://doc.freenas.org/11/system.html#certificates) doesn't indicate that the SAN field is available as it seems it should be.

Which version of FreeNAS are you using?

Sorry for my delayed reaction,
I'm using FN 9.10 U5

Waiting with upgrading to 11 because coral..

 

[danb35]

I'm using FN 9.10 U5

From the bugs I linked above, it sounds like:

• 11 automatically includes the commonName in the SAN field, and
• That feature won't be backported to the 9.10 series.

So, either you can not use Chrome, you can upgrade to 11 and generate the cert there, or you can manually generate the cert using some other means that will include the SAN field.

 

[zoomzoom]

I personally recommend using an openssl.cnf to generate a self-signed CA, then using that to sign certs. I created this prebuilt openssl.cnf with security in mind, and it contains all commands required in the Information section at the bottom of the config, starting at line 500

• The CA, and ICA if using one, needs to be imported into the proper certificate stores.
  • For Windows, the CA needs to go in Trusted Root Certification Authorities, whereas an ICA needs to go in Intermediate Certification Authorities
  • Once done,

 

[danb35]

I personally recommend using an openssl.cnf to generate a self-signed CA, then using that to sign certs.

While this may be a good recommendation, it doesn't address the issues that OP is running into.

 

[zoomzoom]

Code:

[ req ]
encrypt_key = yes

[ v3_req ]
basicConstraints = CA:FALSE

• encrypt_key should be = no for all server keys, else -nodes must be specified, as the server will require the passphrase every time the service is started or restarted, which is impractical
• basicConstraints should be critical: = critical, CA:FALSE
• extendedKeyUsage = critical, serverAuth should be added to v3_req
  • If generating multiple certs for 2 or more clients and servers, each should have an individual v3 section specific to that cert (i.e. [v3_freenas_ui), with [v3_req] containing only basicConstraints = critical, CA:FALSE & subjectKeyIdentifier = hash

 

[zoomzoom]

While this may be a good recommendation, it doesn't address the issues that OP is running into.

Yes it would, as one can then specify the SAN profile.

1. Request: openssl req -out '.\CSR\FreeNAS 11 WebUI.csr' -new -days 3650 -sha512 -newkey rsa:2048 -keyout '.\Key\FreeNAS 11 WebUI.key.pem' -config .\openssl.cnf -extensions v3_freenas_ui -nodes
2. Sign: openssl x509 -req -sha512 -days 3650 -in '.\CSR\FreeNAS 11 WebUI.csr' -CA '.\CA\FreeNAS 11 ICA.crt.pem' -CAkey ".\CA\FreeNAS 11 ICA.key.pem" -CAserial .\serial -out '.\CRT\FreeNAS 11 WebUI.crt.pem' -extfile .\openssl.cnf -extensions v3_freenas_ui
   
   openssl.cnf (FreeNAS Specific)
   
   Code:

   #####################################################################
   			  ##----- Establish ICA Client SANs -----##
   #--------------------------------------------------------------------
   
   # FreeNAS #
   #--------------------------------------------------------------------
   
     # Servers #
   	[ alt_freenas_ui ]
   	DNS.1				   = Fractals
   	IP.1					= 127.0.0.1
   	IP.2					= 192.168.200.23
   	IP.3					= 192.168.200.100
   
   
   #####################################################################
   		  ##----- Establish ICA Client V3 Profiles -----##
   #--------------------------------------------------------------------
   
   # FreeNAS #
   #--------------------------------------------------------------------
   
     # Servers #
   	[ v3_freenas_ui ]
   	basicConstraints		= critical, CA:FALSE
   	subjectKeyIdentifier	= hash
   	authorityKeyIdentifier  = keyid:always, issuer:always
   	keyUsage				= critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
   	extendedKeyUsage		= critical, serverAuth
   	subjectAltName		  = @alt_freenas_ui
   

   • Loopback IP should be specified on all servers with a WebUI, else cert errors will occur when tunneling to the WebUI over SSH
   Show : Full OpenSSL.cnf

   Code:

   			##::[[--  Windows OpenSSL Config  ---]]::##
   
   #####################################################################
   			 ##----- Establish working directory -----##
   #####################################################################
   
   dir							 = .
   
   
   #####################################################################
   		   ##----- Establish CA Profile and Policy -----##
   #####################################################################
   
   # Default #
   #--------------------------------------------------------------------
   
   [ default ]
   FN							  = "FreeNAS 11 ICA"
   CCA							 = "FreeNAS 11 ICA Chain.pem"
   
   [ ca ]
   default_ca					  = CA_default
   
   
   # CA Default #
   #--------------------------------------------------------------------
   
   [ CA_default ]
   certs						   = $dir\\CRT
   new_certs_dir				   = $dir\\CRT
   
   database						= $dir\\index
   RANDFILE						= $dir\\rand
   serial						  = $dir\\serial
   
   crldir						  = $dir\\CRL
   crlnumber					   = $crldir\\crlnumber
   crl							 = "$crldir\\$FN.crl.pem"
   default_crl_days				= 3650
   
   certificate					 = "$dir\\CA\\$FN.crt.pem"
   private_key					 = "$dir\\CA\\$FN.key.pem"
   
   default_days					= 3650
   default_md					  = sha512
   preserve						= no
   
   x509_extensions				 = usr_cert_not_dn
   copy_extensions				 = copy
   unique_subject				  = yes
   
   policy						  = policy_match
   name_opt						= esc_2253,esc_ctrl,esc_msb,sep_comma_plus_space,ignore_type
   cert_opt						= ca_default
   
   
   # Policies #
   #--------------------------------------------------------------------
   
   [ policy_match ]
   countryName					 = match
   stateOrProvinceName			 = match
   organizationName				= match
   organizationalUnitName		  = match
   commonName					  = supplied
   emailAddress					= optional
   
   
   #####################################################################
   			##----- Establish Certificate Options -----#
   #--------------------------------------------------------------------
   
   [ req ]
   encrypt_key					 = yes
   default_bits					= 2048
   default_md					  = sha512
   
   utf8							= yes
   string_mask					 = utf8only
   
   attributes					  = req_attributes
   distinguished_name			  = req_distinguished_name
   
   req_extensions				  = v3_req
   x509_extensions				 = v3_ca
   copy_extensions				 = copy
   
   
   # Password Attributes #
   #--------------------------------------------------------------------
   [ req_attributes ]
   challengePassword			   =
   challengePassword_min		   = 20
   challengePassword_max		   = 40
   
   
   # DN options #
   #--------------------------------------------------------------------
   [ req_distinguished_name ]
   countryName_min				 = 2
   countryName_max				 = 2
   commonName_max				  = 64
   emailAddress_max				= 64
   
   countryName_default			 = US
   stateOrProvinceName_default	 = US
   localityName_default			= Davinci
   0.organizationName_default	  = Sophos UTM
   organizationalUnitName_default  = FreeNAS 11
   
   
   #####################################################################
   			  ##----- Establish ICA Client SANs -----##
   #--------------------------------------------------------------------
   
   # FreeNAS #
   #--------------------------------------------------------------------
   
     # Servers #
   	[ alt_freenas_ui ]
   	DNS.1				   = Fractals
   	IP.1					= 127.0.0.1
   	IP.2					= 192.168.200.23
   	IP.3					= 192.168.200.100
   
   
   #####################################################################
   		  ##----- Establish ICA Client V3 Profiles -----##
   #--------------------------------------------------------------------
   
   # FreeNAS #
   #--------------------------------------------------------------------
   
     # Servers #
   	[ v3_freenas_ui ]
   	basicConstraints		= critical, CA:FALSE
   	subjectKeyIdentifier	= hash
   	authorityKeyIdentifier  = keyid:always, issuer:always
   	keyUsage				= critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
   	extendedKeyUsage		= critical, serverAuth
   	subjectAltName		  = @alt_freenas_ui
   

   • If encrypt_key = yes -nodes must be specified at the end of the request command for server certs with a WebUI

 

[Spearfoot]

• encrypt_key should be = no for all server keys, else -nodes must be specified, as the server will require the passphrase every time the service is started or restarted, which is impractical

I respectfully defer to your superior knowledge regarding openssl.

It puzzles me, though, that I created a CA certificate in July of 2015 and have used it to sign dozens of certificates for my servers using the schema I described above, including web and mail servers, and have never had to key in a passphrase.

 

[danb35]

specify the

I still don't think the CA itself has anything to do with SANs on the certs, but certainly your use case as a whole accounts for that.

Or the OP can upgrade to FN11, where the issue is supposedly resolved.

 

[zoomzoom]

I respectfully defer to your superior knowledge regarding openssl.

Not superior, no... I'm just familiar with openssl configs from having spent so much time editing mine and reading the man pages.

It puzzles me, though, that I created a CA certificate in July of 2015 and have used it to sign dozens of certificates for my servers using the schema I described above, including web and mail servers, and have never had to key in a passphrase.

If you provide the entire openssl.cnf output, along with the commands you use, I can let you know why. My guess is, if you haven't been using -nodes, it's likely with a misconfiguration/misapplication of one of the req or attributes sections.

 

[zoomzoom]

I still don't think the CA itself has anything to do with SANs on the certs, but certainly your use case as a whole accounts for that.

Or the OP can upgrade to FN11, where the issue is supposedly resolved.

You're mixing up two separate things... the issue the OP has is no SAN is specified for the WebUI cert, due to not using an openssl.cnf, and has nothing to do with the CA (though a CA/ICA should have a SAN profile as well... certain CAs won't function properly within certain daemons without a SAN profile, such as the CA for a Sophos UTM).

In regards to FN11, unless the FreeNAS server's WebUI is the only cert one will need to create on their network, it's not a solution if all FN11 does is copy the common name into DNS.1/IP.1 under the SAN profile. If FN11 allows the user to specify multiple SAN values, this is moot, else it's a massive hindrance.

• For example, take NextCloud/ownCloud: if using a local IP, along with a FQDN for access from WAN, both need to be specified in the SAN profile.

Most have a router with a WebUI, coupled with IPMI for server boards, a VPN server, multiple FreeNAS plugins, etc. and the cleanest, most efficient way to generate SSL certs for them is via an openssl.cnf. For someone who's never worked with an openssl.cnf before, grabbing one off the internet and attempting to make heads or tails of it is quite overwhelming, which is why I created a pre-built openssl.cnf and linked to it in my signature.

• I laid out the different sections in a sane manner, keeping commenting to a minimum and placing most comments at the end of the config in their own section. I wanted to streamline the process for users, so I give the required commands for generation and signing at the bottom of the config, with creating a self-signed CA taking 3 commands and generating and signing a certificate with that CA taking 2.

 

[danb35]

If FN11 allows the user to specify multiple SAN values, this is moot, else it's a massive hindrance.

It doesn't appear to do this:

I'll assume (based on the bugs noted above), though I haven't yet tested, that 11-U1 does actually use the commonName as a SAN as well, but there's no field allowing you to specify additional SANs. But certs in general should cover hostnames rather than IP addresses--if you need to use an IP, you have an infrastructure issue.

 

[zoomzoom]

But certs in general should cover hostnames rather than IP addresses--if you need to use an IP, you have an infrastructure issue.

If creating certs for WAN servers, yes, for local networks no. For example, everyone likely manages their FreeNAS box through it's LAN IP, not through <hostname>.<workgroup/local domain>, just like one accessing their router's WebUI utilizes an IP.

SAN profiles are not just for IPs, hostnames, or FQDNs... pretty much anything can go in a SAN profile (via OIDs), from user names for authentication and login to a network, to email addresses for email encryption/signing, details of the author for code signing certs, etc. From the OpenSSL x509 man:

The subject alternative name extension allows various literal values to be included in the configuration file. These include email (an email address) URI (a uniform resource indicator), DNS(a DNS domain name), RID (a registered ID: OBJECT IDENTIFIER), IP (an IP address), dirName(a distinguished name) and otherName.

The email option include a special 'copy' value. This will automatically include any email addresses contained in the certificate subject name in the extension (results with RFC822 Name=<email> under SAN in the signed cert).

The IP address used in the IP options can be in either IPv4 or IPv6 format.

The value of dirName should point to a section containing the distinguished name to use as a set of name value pairs. Multi values AVAs can be formed by prefacing the name with a +character.
otherName can include arbitrary data associated with an OID: the value should be the OID followed by a semicolon and the content in standard ASN1_generate_nconf(3) format.​

OIDs alone are endless, can be combined to create new OIDs (see OID Database), and almost all WAN certs from professional CAs/ICAs are issued with OIDs as apart of their SAN profiles. I've attached a screenshot of Google's SSL cert, which has two OIDs (1.3.6.1.4.1.11129.2.5.1 & 2.23.140.1.2.2)

 

[danb35]

For example, everyone likely manages their FreeNAS box through it's LAN IP, not through <hostname>.

Well, not everyone; I use the hostname.

just like one accessing their router's WebUI utilizes an IP.

Same here.

It's been long enough since I used a consumer router that I don't know if it's a common capability, but my pfSense router, and my Linux server/router before that, both provid(ed) local DNS, and both make it easy to add a hostname -> IP mapping. Given that capability, why would you prefer to remember IPs for whatever you need to manage? Isn't that kind of the point of DNS?

You might be thinking at this point that this is getting a bit overly obsessive. You're probably right, but I'd counter that wanting to use SSL on a home LAN is probably a bit overly obsessive as well. And I'd suspect that pretty much anyone who has the ability to do anything even remotely intelligent with SSL, probably also has the capability to set up local DNS so they can use hostnames.

As a side note, and touching on a discussion we had some time back in another thread, your response here illustrates a drawback to your preferred MO of "continuously edit your post unless/until someone else has replied to the thread." I got an email notification of your reply, which at the time contained only one sentence. After I visited the thread to see that, I got no further notification of anything else (since there were no new posts).