Announcing the release of tnascert-deploy 2.2, an opensource tool used
for the deployment of TLS certificates to TrueNAS-SCALE and TrueNAS-CORE
systems. Release 2.2 introduces a new feature to help secure your
tnas-cert.ini configuration files through the use of OS environment
variables. In your tnas-cert.ini file, all configuration parameters
can be defined using bash like syntax to set the variables from the OS
environment. For example:
environment variable expansion in the INI config file settingsAdd support for more strict certificate base name matching via strict_base name_match config option.
Makefile updated for static builds
replaced expired unit test certificates
added checks to ensure that the connect_host config parameter is defined in the wsapi client
added checks to ensure that an authentication mechanism is configured ie, api_key or username and password.
fixed a bug in the wsapi client and added the cert_basename prefix check before deleting any unused certificates.
I’ve looked through the Readme, looked through the INI files.
ALL the info is about the TN API, env, except the TLS certs (apparently from LetsEncrypt).
My searching for info, informed me that your repo uses the LetsEncrypt API, which in turn, apparently needs a router port forward to the TN IP, or using a “DNS-01 challenge”. If I understand correctly, a DNS-01 Challenge is to do with the DNS portion of a public domain, so nothing to do with a TrueNAS server behind a firewall/NAT.
ALL your docs ASSUME that the TLS cert files are in place.
No. This tool uses the TrueNAS API to take a cert you’ve obtained by some other means (whether from Let’s Encrypt, some other certificate authority, or generated yourself), and deploy it to your NAS. It’s going to be most useful in connection with relatively short-lived certs (such as those issued by Let’s Encrypt) that need to be deployed/installed frequently, but it does nothing to obtain the certs.
@dan is correct, tnascert-deploy is used only to deploy a certificate you’ve obtained by some other means to a TrueNAS system. Personally, I use Certbot in a FreeBSD VM to initially obtain my certificate from LetsEncrypt and to renew it when needed. I then have a shell script that uses tnascert-deploy to automatically deploy the renewed certificate to my TrueNAS instances. The shell script is automatically called by certbot’s post deployment hook when it renews my certificate.
Yeah, that’s an exaggeration of my reaction, but I’m still not a fan of certbot, favoring either acme.sh or lego for those occasions when a standalone ACME client is called for (which are fewer than people seem to think). The system of mine that’s running tnascert-deploy is using lego to get the cert.
But to get back to @CryptoWizard’s question, there are several reasons for a tool like this (or my script). To mention a few:
You want to put a Let’s Encrypt cert on your NAS, but you aren’t using one of the handful of DNS providers with built-in support in TrueNAS.
You want to put a wildcard Let’s Encrypt cert on several systems, including your NAS (i.e., you don’t want the NAS to have its own dedicated cert, but rather one that’s shared by several systems).
You want to get a cert using HTTP validation, which would involve opening ports 80/443 at least briefly, and then deploy it to your NAS.
You want to use a cert from a different CA (one which may or may not support ACME).
You want to use a cert from a local CA.
There are no doubt others, but I think this is enough to get the idea. But once you’ve got the cert, however you get it, you can use this tool to deploy it to your NAS.
Thanks for this. I have user certbot on pfsense for all my cert requests. I was thinking about building something very similar. You saved me the trouble.
I’ve never had any trouble with Cerbot. I use the DNS authenticator plugin for it and an API key from cloudflare. It renews my certificate automatically without fail every time its needed and calls the deploy hook automatically updating my TrueNAS
Couldn’t agree more on Certbot and its… surface area. Egad.There might be one or more unrelated packages that people also call certbot, especially in K8s. It’s the EFF’s feral system takeover script that soured me to the name.
I’m all in on lego and have been using a reduction of your script to push wildcard certs to TrueNAS.
So this presents me with two opportunities:
Thank @dan for his Python/REST script — it’s been a great help!
Explore this cool new Go/JSON-RPC tool from @jjrushford — looking good so far!
I suppose we’re getting kind of far afield for a release announcement thread. But here’s how I see both tools being useful:
If you’re planning to run it on the NAS itself (e.g., using acme.sh on the NAS to get the cert, and then deploy it wherever, as described in Scripted Certificate Import for SCALE | Dan's Wiki), IMO my script is a better tool. The API client is already installed on TrueNAS, and it’s a few KB compared to several MB for truenascert-deploy.
OTOH, if you’re planning to install it anywhere else, the standalone Go binary for tnascert-deploy is probably going to be a lot easier to deal with–just put it in a convenient location and run it as necessary.
I’m using tnascert-deploy these days on a separate LXC.
Without getting into too much detail: my lego is running in a FreeBSD jail. When it has something to share, it reaches out to half a dozen machines via rsync.
A forced command script in authorized_keys on each of those hosts takes care of servicing the rsync and then triggering whatever needs to happen on that host. That might be to HUP nginxor haproxy, or to issue an API call to UniFi or CommuniGate Pro or TrueNAS… whatever that host needs. Both a separation of concerns and an isolation of credentials.
