Help installing a certificate from an external CA?

[surfrock66]

I am using TrueNAS Core 12. I have tried and failed to get an SSL certificate to install from my separate certificate authority and am seeking some guidance.

Background, I have easy-rsa installed on an Ubuntu server, acting as my CA. The root certificate has been installed on my client machines, and separately registered in chrome. I have validated that chrome recognizes the certificates issued by this CA via other services and apache sites.

I do NOT want TrueNAS acting as my CA, which I know it can do. That being said, I have followed steps which would result in that, and still it has not worked.

No process I have tried in TrueNAS' GUI has allowed for successful import or installation of a certificate. First, I imported the root CA cert, separately I have imported the root cert AND Private Key (which would enable TrueNAS to be the CA, which I don't want). Neither of these mattered down the line.

First, I tried generating a CSR in the TrueNAS GUI. Once I did that, I exported it and imported it into my CA. I signed it, then took the resulting certificate and imported it in the TrueNAS Certificiates GUI. I tried this several times, sometimes acknowledging that the CSR was on the host with "CSR exists on this system" and sometimes not. When not, I included the private key. If I did this, selected the new cert in the "General" tab, then restarted the web UI, the cert failed to validate. One curious thing, I could not get the entry for the original CSR to ever register as signed, even when a new import of a cert with the same key and csr was also in the list.

Then, I tried generating a whole separate CSR on the CA (which is my preferred situation). I generated a private key in openSSL and a CSR, imported the CSR in TrueNAS, and imported the resulting cert. After switching to it, same thing. It says "common name invalid" though the cert shows the correct common name.

I do not believe, when importing the cert, it is correctly linking with the CA cert, thus the chain is not validating properly. I do not see in the GUI how to do this for an imported CSR/Cert. I have validated that the cert and key validate each other in openssl, and sites using certs from the same CA (in apache and other services) validate fine in chrome, but something about this isn't working. Is this a thing where rather than inputting the Root Certificate separately, I should concatenate them into a chain file?

In the apache site with the working cert from my CA, if I do "openssl s_client -CApath /etc/ssl/certs/ -connect testsite.subdomain.domain.com:443" I get a chain like this in the output:

Certificate chain
0 s:C = US, ST = California, L = City, O = OrgName, OU = domain, CN = testsite.subdomain.domain.com, emailAddress = sysnotice@domain.com
i:CN = subdomain.domain.com
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 23 18:06:07 2022 GMT; NotAfter: Nov 25 18:06:07 2024 GMT
1 s:CN = subdomain.domain.com
i:CN = subdomain.domain.com
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 22 22:23:14 2022 GMT; NotAfter: Aug 19 22:23:14 2032 GMT

But if I do the same for the nas, I get this, no CA cert in the chain:

Certificate chain
0 s:C = US, ST = California, L = City, O = OrgName, OU = domain Homelab, CN = nas-2.subdomain.domain.com
i:CN = subdomain.domain.com
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 23 22:59:36 2022 GMT; NotAfter: Nov 25 22:59:36 2024 GMT

Ultimately, I have a CSR, key, cert and root cert issued from my root CA. Is there any advice for how to get those pieces into TrueNAS?

 

[danb35]

A web server should serve its leaf cert, and any intermediate CA certs between the root CA cert and that leaf cert. It should not serve the root CA cert; that should already be in the trust store of whatever clients are going to use it. So if you're using your root CA cert to directly sign the leaf certs, the only thing that needs to be (or, indeed, should be) imported into TrueNAS is the leaf cert.

So, for "how to add the cert", go to System -> Certificates -> Add, set Type to Import Certificate, enter a name, and paste in the cert and key. Then go to System -> General and set GUI SSL Certificate to the name of the cert you've just entered. TrueNAS 13, at least, will happily import and use a cert in that way even if the CN/SAN are completely wrong.

You can enter a certificate chain here, if you have an intermediate CA cert, and TrueNAS will serve that chain--but from what you've said and shown of your situation, there shouldn't be any need to do that.

I tried generating a whole separate CSR on the CA (which is my preferred situation).

This really seems like an odd preference. I get that there isn't a particular security concern if it's all in your lab, but as a general best practice it seems the CA shouldn't ever see the end-entity private keys.

But if I do the same for the nas, I get this, no CA cert in the chain:

That looks as it should--as above, the self-signed root cert shouldn't be part of the chain.

If you're getting "invalid domain" errors with modern browsers, two likely reasons come to mind: (1) you aren't accessing the NAS using an address that's on the cert (e.g., the cert is for a FQDN, but you're using an IP address); or (2) there's no SAN on the cert, which are now required by modern browsers.

 

[surfrock66]

Ok, you're giving me great info, specifically you're making me question if the root cert is properly installed on chrome. I know on Ubuntu, chrome doesn't necessarily respect the system cert store and I installed it in settings, so when I validate the cert in openssl vs. in chrome I'm getting different results. As I understand it, including the rootca in the apache site as an intermediate is incorrect and is masking the problem for that example. I'll test removing the intermediate line, then seeing if that site still validates in chrome and other browsers.

I'm trying to develop an internal CA for learning, so I'm super early in the setup, which is why I would prefer to keep csr generation on the ca for now, mostly for backup and versioning. As I'm testing and setting things up I'm doing a lot of issuing and revoking. All the stuff like syncthing, internal web services like octoprint, etc will get certs from this CA.

The common name is the same as the address I'm using for sure, and also I have SAN in the request. This is outside the scope of this question, but here's the process I've built:

This is the contents of 0.SR66CertDefaults.cnf:

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
req_extensions = req_ext

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
commonName = Common Name (e.g. server FQDN or YOUR name)

# Optionally, specify some defaults.
countryName_default = US
stateOrProvinceName_default = (My State)
localityName_default = (My City)
0.organizationName_default = (My Company)
organizationalUnitName_default = Surfrock66 Homelab
emailAddress_default = sysnotice@domain.com

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = [DNS1]
DNS.2 = [DNS2]

Then, I can basically copy/paste the following to make the request. Afterwards, I copy/move/delete the csr/private key/cert as needed.

_now=$(date +"%Y.%m.%d.%H.%M")
read -p "Enter The Host Name (Not FQDN, so nas-2 and not nas-2.subdomain.domain.com): " subjectName
read -p "Enter The IP Address: " subjectIP
sed -i "s|\[DNS1\]|$subjectName|g" /etc/easy-rsa/0.SR66CertDefaults.cnf
sed -i "s|\[DNS2\]|$subjectIP|g" /etc/easy-rsa/0.SR66CertDefaults.cnf
openssl req -newkey rsa:4096 -subj "/C=US/ST=(My State)/L=(My City)/O=(My Company)/OU=Surfrock66 Homelab/CN=$subjectName.subdomain.domain.com/" -nodes -sha256 -keyout "/etc/easy-rsa/0.PrivateKeys/$subjectName.subdomain.domain.com.key" -out "/etc/easy-rsa/0.CertRequests/$_now.$subjectName.subdomain.domain.com.csr" -config /etc/easy-rsa/0.SR66CertDefaults.cnf
sed -i "s|$subjectName|\[DNS1\]|g" /etc/easy-rsa/0.SR66CertDefaults.cnf
sed -i "s|$subjectIP|\[DNS2\]|g" /etc/easy-rsa/0.SR66CertDefaults.cnf
~/easyrsa import-req "/etc/easy-rsa/0.CertRequests/$_now.$subjectName.subdomain.domain.com.csr" "$_now.$subjectName.subdomain.domain.com"
~/easyrsa sign-req server "$_now.$subjectName.subdomain.domain.com"

 

[danb35]

If you're wanting to run your own CA, take a hard look at Smallstep. That's what I'm running on a standalone Raspberry Pi following this guide:

Build a Tiny Certificate Authority For Your Homelab

Let's make a tiny, standalone CA! We'll use a Raspberry Pi 4, YubiKey 5 NFC, and Infinite Noise TRNG.

smallstep.com

...with some later alterations to support SSH user and host certificates with SSO. It could naturally run on any Linux machine, but at the time a Pi was cheap. It's providing certificates for a whole lot of my infrastructure, and doing it with no real problems for the last couple of years.

But the big takeaway, when you're seeing certificate errors, is to be very clear what the error is, because there are a number of possible reasons--and a browser will tell you, though it may take some convincing to do so.

 

[Patrick M. Hausen]

Given that there are builtin CAs with a UI in both TrueNAS and OPNsense I prefer to stick with one of them. Currently I use my OPNsense one.

 

[surfrock66]

I solved it. Even though I had a SAN in, I didn't realize the entire CN had to be replicated as a SAN. You learn something new every day!

 

[danb35]

It's a relatively recent change in the browsers--it's been a few years, but not that long. The CN is pretty much meaningless any more--it does need to be populated, but it doesn't seem to actually be used by the current browsers.

 

[danb35]

Given that there are builtin CAs with a UI in both TrueNAS and OPNsense I prefer to stick with one of them. Currently I use my OPNsense one.

The big win of Smallstep over these is that it can be automated in many ways, including ACME (and SSO using OpenID Connect). The CAs in TrueNAS and OPNsense (and pfSense, for that matter) insulate you from the CLI, but they're still entirely manual. For some things, that's what you want. For others, not so much.