Let's Encrypt with FreeNAS 11.1 and later 0.3

[thepixelgeek]

Haven't tried that, and it will be a first. Not sure how. Found this: https://www.truenas.com/docs/hub/tasks/advanced/boot-environments/

I'm resilvering at the moment.

 

[danb35]

Boot environments are snapshots, so it should be possible to access them through the filesystem, but I'm not sure how.

 

[thepixelgeek]

Looks like it's working now. I copied the .acme directory from the previous environment and successfully ran the cert renew cron job.

 

[airflow]

I just merged a PR that says it updates the cert for WebDAV, but I haven't tested it as I don't use WebDAV. Update the script (git pull) and see how it works.

I tested this in the meanwhile - works fine. Thanks!

 

[Patrick M. Hausen]

Boot environments are snapshots, so it should be possible to access them through the filesystem, but I'm not sure how.

beadm mount ...

 

[KevDog]

@danb35

After upgrading to 12.0 I'm having a problem using your acme.sh script.
I see all the files from your github are present, the cronjob is still present, acme.sh directory is still present, but the GUI isn't reflective of the certificate.

Where does the cronjob run within the GUI log? I've run the cronjob from within the GUI manually but for some I don't see a new certificate listed within the GUI. The date of the certicate issue was 10-8-2020. If I look within the /root/.acme.sh/<domain> subdirectory, I see a certificate last renewed 12-8-2020 -- which would be exactly 2 months after the original certificate was issued which would imply the actual acme.sh cron job is successful.

The 12-8-2020 script doesn't show up in the GUI. Confirmed however it sits with .acme.sh subdirectory

 

[danb35]

Is your script up to date? I've merged a few PRs recently, which might affect this. If you aren't sure, change to the directory where the script lives and run git pull. Then try running the script manually and see if it imports the cert. If it succeeds, the cert will show in the GUI with a name reflecting the date and time when you run the script (which, in this case, won't match the date and time when the cert is issued as it normally would).

 

[KevDog]

@danb35 Sorry I did try a git pull after awhile (after the last post but before replying here) and I don't see any difference. I restarted the freenas nginx service to see if it would pick up changes (not sure if its an nginx issue anyway -- just grasping at straws), but no renewed certificate shows up. I've re-run the cron job manually and still see the old SSL cert. I'm not exactly sure what going on other than it would seem the cert isn't being imported into the API -- it's clearly been renewed.

 

[danb35]

What's the output when you run deploy_freenas.py at the CLI?

 

[KevDog]

Weird -- so when I run the python script manually everything seemed to work:

# ./deploy_freenas.py
Certificate import successful
Certificate list successful
Setting active certificate successful
Deleting certificate letsencrypt-2020-10-10-042228 successful
Reloading WebUI successful
deploy_freenas.py executed successfully

So possibly my acme.sh deploy hook is misconfigured?

 

[danb35]

Maybe (kind of grasping at straws here) acme.sh has forgotten about the deploy script, maybe it never knew about it. /path/to/acme.sh --install-cert -d your_freenas_fqdn --reloadcmd /path/to/deploy_freenas.py should reset this.

 

[KevDog]

Yea -- you and me were thinking the same about corrupted acme deploy hook. Ok just posting the acme domain conf file to see if anything looks suspicious:

Code:

Le_Domain='freenas.domain.com'
Le_Alt='no'
Le_Webroot='dns_cf'
Le_PreHook=''
Le_PostHook=''
Le_RenewHook=''
Le_Keylength=''
Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/68918676/6629097970'
Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/68918676/6629097970'
Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03b885a0d1be64c2fade605a00b1eeccfe52'
Le_CertCreateTime='1607422948'
Le_CertCreateTimeStr='Tue Dec  8 10:22:28 UTC 2020'
Le_NextRenewTimeStr='Sat Feb  6 10:22:28 UTC 2021'
Le_NextRenewTime='1612520548'
Le_RealCertPath=''
Le_RealCACertPath=''
Le_RealKeyPath=''
Le_ReloadCmd='__ACME_BASE64__START_L3Jvb3QvZ2l0L2RlcGxveS1mcmVlbmFzL2RlcGxveV9mcmVlbmFzLnB5__ACME_BASE64__END_'
Le_RealFullChainPath=''

I ran the ReloadCmd through base64 checker: https://www.base64decode.org/ and it decoded correctly. I'm going to chalk this up to a faulty acme.sh config since I don't have a copy (well I do in snapshots but I'm not going to go back and check).

 

[danb35]

Nothing looks suspicious--though if you don't want to expose your domain name, the links there will give that information.

I wonder if it's something simple: the deploy script only runs (normally) after cert issuance. If it was out of date at the time the last cert was issued (about a month ago), such that it wasn't able to import the new cert, updating it doesn't automatically run it. And running the cron job won't change anything, as acme.sh knows the cert isn't due for renewal.

 

[Basil Hendroff]

A couple of ideas...

The acme.sh.log may provide some additional clues as to what went wrong.

Have a look at the acme.sh configuration file account.conf. If AUTO_UPGRADE='0', acme.sh could have previously been out-of-date. It's in constant development so it's worth setting it up for auto-upgrade acme.sh --upgrade --auto-upgrade. More info here.

acme.sh --list provides a summary view of the domain conf file.

 

[MrBucket101]

works great.

Only suggestion I have, would be to utilize the .acme.sh/acme.sh.env or .acme.sh/acme.sh.csh

Upon installation of acme.sh, this file is added to your .bashrc or .zshrc - meaning any environment variables you store in the file, will be permanent.

I would put your environment variables in those files to maintain consistency.

Code:

export CF_Token="sdfsdfsdfljlbjkljlkjsdfoiwje"
export CF_Account_ID="xxxxxxxxxxxxx"
export CF_Zone_ID="xxxxxxxxxxxxx"

 

[danb35]

Upon installation of acme.sh, this file is added to your .bashrc or .zshrc - meaning any environment variables you store in the file, will be permanent.

Why is this desirable? Once you issue the cert, the credentials are stored in the acme.sh configuration (account.conf, specifically)--what is the benefit in having those variables available to any process that wants them in the future?

 

[MrBucket101]

Why is this desirable? Once you issue the cert, the credentials are stored in the acme.sh configuration (account.conf, specifically)--what is the benefit in having those variables available to any process that wants them in the future?

I wasn't aware this was the case. I was having issues, and this was the resolution.

I'll go check and see if my account.conf file is accurate, and if so, remove these from my shell

 

[Basil Hendroff]

Some feedback on what I'm seeing when I execute deploy-freenas on a server recently upgraded from FreeNAS 11.3-U5 to TrueNAS 12.0-U3. I still get a secure connection to the server after certificate deployment so there's no outward impact. It's just that deploy_freenas.py chucks a wobbly towards the end of the process.

Code:

root@letsencrypt:/truenas # /root/deploy-freenas/deploy_freenas.py --config /truenas/truenas-t.udance.com.au.conf
Certificate import successful
Certificate list successful
Setting active certificate successful
Deleting certificate letsencrypt-2021-04-14-104228 successful
Error reloading WebUI!
405: Method Not Allowed

EDIT: I have to reboot the server before I can establish a secure connection. Is there a way to reload the WebUI and avoid a server reboot?

 

[danb35]

Error reloading WebUI! 405: Method Not Allowed

That should have been fixed in a PR I merged back in September. What's in lines 225-229 of the script?

 

[Basil Hendroff]

That should have been fixed in a PR I merged back in September. What's in lines 225-229 of the script?

When I first saw the error, I did think I might not be on the latest version of deploy-freenas so I did a refresh with git clone https://github.com/danb35/deploy-freenas, however, the error persists.

# cd /root/depoly-freenas && ee deploy_freenas.py

Lines 225-229:

Code:

try:
  r = session.get(
    PROTOCOL + FREENAS_ADDRESS + ':' + PORT + '/api/v2.0/system/general/ui_restart',
    verify=VERIFY
  )

I'm not sure that it makes any difference, but I should point out the context and that is, I am running deploy-freenas from within a jail using the resource Let's Encrypt Local Servers and Devices to deploy Let's Encrypt certificates to FreeNAS/TrueNAS servers from a central location. I've had good success with this to date. The jail patch level is 12.2-RELEASE-p6.

EDIT: If I run the script with the target being a FreeNAS 11.3-U5 server, the target WebUI reloads successfully, though it should also be noted that, apart from the OS version difference, this uses the root password, while the TrueNAS servers I've configured to use the API key,