Resource icon

Let's Encrypt with FreeNAS 11.1 and later 0.3

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Code:
[root@freenas ~]# .acme.sh/acme.sh --issue -d freenas.example.com --dns dns_cf --reloadcmd "/root/git/deploy-freenas/deploy_freenas.py"
It seems that you are using sudo, please read this link first:
https://github.com/Neilpang/acme.sh/wiki/sudo


Do I not want to initially run this script as root?
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
Do I not want to initially run this script as root?
It doesn't directly matter, but it has to have access to your root password, so it might as well run as root. But the warning acme.sh is giving you is erroneous, as you aren't using sudo in any case. Probably would be worth filing a bug against acme.sh, though: https://github.com/Neilpang/acme.sh/issues
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
It doesn't directly matter, but it has to have access to your root password, so it might as well run as root. But the warning acme.sh is giving you is erroneous, as you aren't using sudo in any case. Probably would be worth filing a bug against acme.sh, though: https://github.com/Neilpang/acme.sh/issues

Yea but the script won't proceed as intended. I filed a bug as you suggested and I'll guess I'll go with the --force option to overcome this limitation
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Hmm something doesn't seem right -- of course I'm trying to push the envelope here and use ec-256 keys -- likely the source of the error (see below) :
Code:
[root@freenas ~]# .acme.sh/acme.sh --issue --force -d freenas.example.com --keylength ec-256 --dns dns_cf --reloadcmd "/root/git/deploy-freenas/deploy_freenas.py"
[Wed Oct  9 10:48:31 CDT 2019] Create account key ok.
[Wed Oct  9 10:48:31 CDT 2019] Registering account
[Wed Oct  9 10:48:31 CDT 2019] Registered
[Wed Oct  9 10:48:31 CDT 2019] ACCOUNT_THUMBPRINT='CT5imcY2pZdVLYoXvr5v6P7ljjf2DOrE1M-F-gksTec'
[Wed Oct  9 10:48:31 CDT 2019] Creating domain key
[Wed Oct  9 10:48:31 CDT 2019] The domain key is here: /root/.acme.sh/freenas.example.com_ecc/freenas.example.com.key
[Wed Oct  9 10:48:31 CDT 2019] Single domain='freenas.example.com'
[Wed Oct  9 10:48:31 CDT 2019] Getting domain auth token for each domain
[Wed Oct  9 10:48:35 CDT 2019] Getting webroot for domain='freenas.example.com'
[Wed Oct  9 10:48:35 CDT 2019] Adding txt value: qwC4ugiCfXCp8JvcnInRs6I6GAX1RKCxSL03Jdxkhz0 for domain:  _acme-challenge.freenas.example.com
[Wed Oct  9 10:48:43 CDT 2019] Adding record
[Wed Oct  9 10:48:43 CDT 2019] Added, OK
[Wed Oct  9 10:48:43 CDT 2019] The txt record is added: Success.
[Wed Oct  9 10:48:43 CDT 2019] Let's check each dns records now. Sleep 20 seconds first.
[Wed Oct  9 10:49:04 CDT 2019] Checking freenas.example.com for _acme-challenge.freenas.example.com
[Wed Oct  9 10:49:05 CDT 2019] Domain freenas.example.com '_acme-challenge.freenas.example.com' success.
[Wed Oct  9 10:49:05 CDT 2019] All success, let's return
[Wed Oct  9 10:49:05 CDT 2019] Verifying: freenas.example.com
[Wed Oct  9 10:49:08 CDT 2019] Success
[Wed Oct  9 10:49:08 CDT 2019] Removing DNS records.
[Wed Oct  9 10:49:08 CDT 2019] Removing txt: qwC4ugiCfXCp8JvcnInRs6I6GAX1RKCxSL03Jdxkhz0 for domain: _acme-challenge.freenas.example.com
[Wed Oct  9 10:49:10 CDT 2019] Removed: Success
[Wed Oct  9 10:49:10 CDT 2019] Verify finished, start to sign.
[Wed Oct  9 10:49:10 CDT 2019] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/68918676/1251010423
[Wed Oct  9 10:49:14 CDT 2019] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/03ddde6a215b532621e3ce66ab0fea7108f8
[Wed Oct  9 10:49:14 CDT 2019] Cert success.
-----BEGIN CERTIFICATE-----
xxxxx <Cert ommited>
-----END CERTIFICATE-----
[Wed Oct  9 10:49:14 CDT 2019] Your cert is in  /root/.acme.sh/freenas.example.com_ecc/freenas.example.com.cer
[Wed Oct  9 10:49:14 CDT 2019] Your cert key is in  /root/.acme.sh/freenas.example.com_ecc/freenas.example.com.key
[Wed Oct  9 10:49:14 CDT 2019] The intermediate CA cert is in  /root/.acme.sh/freenas.example.com_ecc/ca.cer
[Wed Oct  9 10:49:14 CDT 2019] And the full chain certs is there:  /root/.acme.sh/freenas.example.com_ecc/fullchain.cer
[Wed Oct  9 10:49:14 CDT 2019] Run reload cmd: /root/git/deploy-freenas/deploy_freenas.py
Traceback (most recent call last):
  File "/root/git/deploy-freenas/deploy_freenas.py", line 59, in <module>
    with open(PRIVATEKEY_PATH, 'r') as file:
FileNotFoundError: [Errno 2] No such file or directory: '/root/.acme.sh/freenas.example.com/freenas.example.com.key'

Hmm -- I see the problem -- Maybe script doesn't work for ecc keys -- keys are in /root/.acme.sh/freenas.example.com_ecc and script is trying to access them at /root/.acme.sh/freenas.example.com

Update
I just changed the path in the config file since script was looking for them elsewhere
 
Last edited:

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
Maybe script doesn't work for ecc keys
I'm not sure if FreeNAS supports them. The path for the private key is configurable in the deploy_config file.
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
I'm not sure if FreeNAS supports them. The path for the private key is configurable in the deploy_config file.

You were 100% correct about support since I shortly received an email from the FreeNAS system:
Code:
New alerts:
* HTTP server does not support certificates with keys shorter than 1024 bits. HTTPS cannot be enabled until a 1024 bit keylength or greater certificate is added


Well that's a bummer -- anyway -- I just grabbed some new RSA keys and made the switch over within the GUI (which seemingly takes forever to load!!--another problem). Thanks. I'm wondering if I need the force option on the crontab?
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
I'm wondering if I need the force option on the crontab?
I wouldn't expect so, but it should be easy enough to test--just run acme.sh --cron at the shell prompt and see if it works or errors out.
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
I wouldn't expect so, but it should be easy enough to test--just run acme.sh --cron at the shell prompt and see if it works or errors out.

I ran that command -- and at least for me I needed the force option to make it work.

Couple of other questions about the python script.
I see the script uploads the cert named letsencrypt-(date,time), and then sets that cert to active, however what does it do in this case if there is multiple certs -- which one is active? After running the acme.sh --cron command manually -- I see the certs were recopied within freenas and although the gui was supposed to mark one as active -- the GUI entries are no all again screwed up. I have to manually select http/https/or combination and actually select a certificate -- however again with multiple certs being renewed each is labeled letsencrypt-date/time giving me no indication which cert is what. I recently did something like this on my unifi controller key, and their post hooks scripts, made a tarball out of all the old scripts and then uploaded the new ones keeping their original name. The tarball was kept with a date/time affixed to the name. Seems like a little bit more elegant solution that what the api is offering. I can imagine for example acquire a very.very long list of keys which I'm definitely not sure what is what.

Where are these keys placed on the main installation anywhere?
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
what does it do in this case if there is multiple certs -- which one is active?
The script uploads the specified or default cert (the default is /root/.acme.sh/domain_name/fullchain.cer, which is a symlink to the most-recently-issued cert), assigns it the name as you've seen (based on the time that deploy_freenas.py was run--in normal use this will be the same time that the cert was issued), and sets it to active. It should not affect any of the other settings.
I can imagine for example acquire a very.very long list of keys which I'm definitely not sure what is what.
Nothing in the script deletes old certs, so yes, the list will grow over time. In normal operation, a new cert will be issued about every 60 days, so there should be roughly six new certs every year. You can always delete old certs if you don't want them there.
Where are these keys placed on the main installation anywhere?
AFAIK, they're stored in the config database, and the active cert is written to disk by the middleware.
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Hmmm thanks for the clarification. I guess my big problem is I have to use the force flag because of the sudo problem when running the renewal. Use of the force option gets passed sudo but in doing so -- it force renews the certificate -- I've already have like 4 copies of the certificate from just trying things.

In addition I'm trying to remove the -ecc certificate:
Code:
[root@freenas ~/.acme.sh]# sudo ./acme.sh --remove -d freenas.example.com --ecc
Sorry, user root is not allowed to execute './acme.sh --remove -d freenas.example.com --ecc' as root on freenas.example.com.


What the heck is going on!!!!
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Why are you using sudo?
Yea sorry -- I posted the wrong command line:
Here is the corrected version:
Code:
root@freenas:~ # .acme.sh/acme.sh --remove -d freenas.example.com --ecc
It seems that you are using sudo, please read this link first:
https://github.com/Neilpang/acme.sh/wiki/sudo
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
Interestingly, it doesn't give that error if you just invoke acme.sh without arguments. As a quick fix, you could simply edit the _checkSudo() function at lines 6314-6329 of the script to look like this:
Code:
_checkSudo() {      
  return 0      
 }

...which would get rid of the check entirely. Or simply run it as a non-root user, but you shouldn't need to do that (and then you're giving that non-root user access to the root password, which seems kind of pointless).
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Interestingly, it doesn't give that error if you just invoke acme.sh without arguments. As a quick fix, you could simply edit the _checkSudo() function at lines 6314-6329 of the script to look like this:
Code:
_checkSudo() {     
  return 0     
}

...which would get rid of the check entirely. Or simply run it as a non-root user, but you shouldn't need to do that (and then you're giving that non-root user access to the root password, which seems kind of pointless).


Maybe you can explain something to me -- since I may have figured this mess out on my own.
I usually ssh to main freenas install as a user.
Once inside user shell I login as root.

If I do a:
sudo su
Then run the commands -- I get the errors as listed above

If I do a:
su root
Then run the commands -- I dont get the errors listed above.

I didn't honestly recognize there was a difference between sudo su and su root. Clearly there is however.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
Interesting, but that would explain why I wasn't seeing it--I just ssh as root. It'd be worth adding that detail to the bug report, though.
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
Interesting, but that would explain why I wasn't seeing it--I just ssh as root. It'd be worth adding that detail to the bug report, though.


***ADDED. Thanks
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
A review from @Monkey_Demon raises a few points worth discussing, though there's no good to do that in the review context, so I'll address them here:
more than just the Cloud Flare example. I used DuckDNS and had to figure things out (see below). Maybe juxtapose the relevant documentation w/ the implementation and give some guidance of how things may vary.
I've edited the guide to more clearly specify that the example I'm giving uses Cloudflare credentials, and that you'll need to change them (with a reference to the updated doc page) to deal with your preferred provider. I've also addressed the use of csh-y shells.
I put everything in a jail and think this is good practice.
You're certainly free to do it that way, but I really don't see any reason that this is in any way beneficial compared to running it in the base system. It's a shell script, after all. I'm certainly open to being persuaded, but at this point I just don't see any reason to do it that way if you can use DNS validation (obviously it'd be necessary if you're doing HTTP validation).
Because current versions of FreeNAS (11.2+) use iocage, some discussion of appropriate iocage commands.
Not sure why this would be necessary; those same current versions fully support creating an iocage jail through the GUI if you want or need one.
 

Semmel

Dabbler
Joined
Dec 6, 2019
Messages
14
Ihave tried to load lets encrypt certificates on my freenas

i worked all fine until the last command and i got the error:
[Thu Dec 5 12:23:01 PST 2019] Run reload cmd: /root/deploy-freenas/deploy_freenas.py
Traceback (most recent call last):
File “/root/deploy-freenas/deploy_freenas.py”, line 59, in
with open(PRIVATEKEY_PATH, ‘r’) as file:
FileNotFoundError: [Errno 2] No such file or directory: ‘/root/.acme.sh/freenas.local/freenas.local.key’
[Thu Dec 5 12:23:01 PST 2019] Reload error for :

After this i moved the certificates and load the .key and .cer in to Freenas manually… But now the certificates show up as “Invalid” in my web browser when I load the GUI.

Please keep in mind I am very new to all this.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
freenas.local
You're telling it that your FQDN is freenas.local, which it can't be. Correct your config file and your system configuration.
 
Top