Resource icon

Let's Encrypt with FreeNAS 11.1 and later 0.3

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
Why hasn't dan35b suggested using Caddy to achieve the same thing even more simply?'
  • You'll notice that I wrote this resource first--I wasn't thinking about reverse proxies at all at the time
  • The real issues I had in mind in the reverse proxy guide were
    • Services operating on strange, non-standard ports, and
    • Services that weren't easily amenable to terminating their own TLS
      Neither of these is an issue with the FreeNAS web GUI.
  • I'm not at all certain that creating a new jail, downloading Caddy into it, and writing a Caddyfile is more simple than downloading a couple of scripts and doing minimal configuration to them.
Caddy resource is that the latter requires a permanent CNAME entry for the host whereas this does not.
I'm not sure why you believe this to be the case.

This resource is preferred for FreeNAS servers as it encrypts host communication on the local network, but does not expose the server to the internet. Caddy, on the other hand, would expose the server to the internet, making the server vulnerable;
I'm not sure I'd agree with either of these. I'm loath to call either system "preferred", as what's preferred is going to depend on your requirements. It's correct that nothing in this guide exposes the FreeNAS GUI to the Internet, but the Caddy guide doesn't need to do that either (my own installation, for example, doesn't).
I might use this resource to encrypt communication for jails that I do not want exposed to the internet. On the other hand, I would use Caddy if I wanted the jail resource (e.g. Nextcloud) accessible externally?
Again, I don't think I'd agree--certainly not with the first sentence; nothing in this guide will do anything for communications with jails. For Caddy, it's entirely up to you if it's accessible externally or not. If you wanted to reverse proxy several services, with only some being accessible externally, I can think of two ways to do that:
  • For the resources you don't want to be accessible externally, restrict them in the Caddyfile to local IPs
  • Install two Caddy jails, one for private stuff and the other for public
 
Joined
Jan 4, 2014
Messages
1,644
So much for my flawed logic. Thanks for the clarification. This is all new territory for me and I'm still trying to get my head around it. My revised thinking below. Can you please check that this is getting closer to the truth?
  1. For either resource (this or Caddy), for encrypted server communication, the FQDN of the server must resolve to the server LAN IP address.
  2. The reverse proxy is the enabler that makes a LAN resource (server or jail) accessible externally.
  3. The CNAME allows a resource, that's been made available externally, to be identified as cname.mydomain.com.
I'm not at all certain that creating a new jail, downloading Caddy into it, and writing a Caddyfile is more simple than downloading a couple of scripts and doing minimal configuration to them.
Yes, you're right. I guess for me, Caddy starts to look really appealing when more than a handful of jails and servers involved. I also like that server passwords don't need to be stored in a file with the Caddy solution.

nothing in this guide will do anything for communications with jails.
I stand corrected. I've misread or misinterpreted something.

For the resources you don't want to be accessible externally, restrict them in the Caddyfile to local IPs

I'm still missing something. Isn't the Caddy block below what is required for certificate renewal of the host and therefore performs an equivalent function to this Let's Encrypt resource?

Code:
host.mydomain.com {
  tls {
        dns cloudflare
  }
  gzip
  proxy / 192.168.1.5/ {
    transparent
  }
}


If so, what then decides whether the host is available externally or internally restricted? I previously thought that the enabler for this was CNAME=host.

Install two Caddy jails, one for private stuff and the other for public
Not a direction I'd personally pursue. However, Caddy load balancing capabilities make failover with Caddy jails on separate servers and synced Caddyfiles an interesting pursuit.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
For either resource (this or Caddy), for encrypted server communication, the FQDN of the server must resolve to the server LAN IP address.
Close. For encrypted server communication without certificate errors, the FQDN must resolve as you say.
The reverse proxy is the enabler that makes a LAN resource (server or jail) accessible externally.
Not really--that results (if at all) from port forwarding on your router (or, with a different configuration, running the proxy directly on your router). The reverse proxy makes it easy to reach resources on several internal IPs (jails, other hardware, and/or VMs), but isn't necessary to make LAN resources available externally.
The CNAME allows a resource, that's been made available externally, to be identified as cname.mydomain.com.
I guess, though I don't know that I'd phrase it that way.
I guess for me, Caddy starts to look really appealing when more than a handful of jails and servers involved.
I'd agree here, with the additional factor of the odd ports used by many of the web apps involved.
If so, what then decides whether the host is available externally or internally restricted?
You can use the ipfilter plugin:

Then add a block to the appropriate host(s) in the Caddyfile that looks like:
Code:
ipfilter /
{
    rule allow
    ip 192.168.1.0/24
}
 

KevDog

Patron
Joined
Nov 26, 2016
Messages
462
@danb35

I know there are multiple ways to skin the cat, but why Caddy? I usually use nginx as my reverse proxy, and I've tried HA proxy that was built into FreeNAS, however being that the version was very old I can't say the experience was great. I've been aware of Caddy for awhile, but just found there was a lot of tutorials on the web and such for setting up nginx as a reverse proxy for a bunch of different scenarios. I like when I delve into areas I don't know a lot about that there is ample documentation and examples.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
why Caddy?
Seems like this question would be better on that thread than this, but the biggest reasons are probably automatic TLS and simple configuration. The block Basil posted above would be the entire server config file for Caddy to act as a reverse proxy for a single server on your LAN, automatically obtain and renew TLS certs, apply a secure TLS configuration (including being the only server that really has a sensible implementation of OCSP stapling), etc. That's a total of nine lines. Proxying for additional hosts would be another 3-6 lines each, depending on a few details (many of which I discuss in the resource on using Caddy).

With my Nextcloud script, the Apache config was several hundred lines long. The Caddyfile is more involved for that than it is for a simple reverse proxy, but it's still just over 100 lines--and almost all of that was an example from the Caddy docs.
 
Joined
Jan 4, 2014
Messages
1,644
I'm not at all certain that creating a new jail, downloading Caddy into it, and writing a Caddyfile is more simple than downloading a couple of scripts and doing minimal configuration to them.
I'm having to agree now that the Let's Encrypt resource rather than the Caddy resource is the way to go for providing secure communications for FreeNAS servers.

From my investigation and limited understanding, what I've found is, while Caddy is able to obtain and renew certificates for FreeNAS servers, as a fresh FreeNAS installation already has a default certificate, the result is a certificate mismatch with Caddy when attempting to connect securely to the server. The missing link appears to be a mechanism for deploying and renewing the certificates that Caddy holds into the respective FreeNAS servers. This, I suspect, would entail exposing the .caddy directory where the certificates are stored and using something like deploy_freenas.py for certificate renewal. Apart from being beyond my mental capacity to implement, I wonder if it's even worth pursuing given the Let's Encrypt resource does a sterling job of this already.
 
Last edited:

veldthui

Dabbler
Joined
Nov 28, 2019
Messages
47
Having an issue with this renewing the certs. Or rather getting the new cert installed. I have it set up in the jail and it does renew the cert but does not install the cert. I use the following cron job.

iocage exec Acme_Letsencrypt /root/.acme.sh/acme.sh --cron

When I check the cert has been renewed but I have to manually run ./deploy-freenas/deploy_freenas.py from the jail shell to get it to install the cert into freenas. Don't really understand why this is not working as it should.

Any suggestions?
 

Kelly Hays

Dabbler
Joined
Apr 25, 2017
Messages
16
Anyone know if the deploy_freenas.py part of this resource will work on TrueNAS 12? I'm sure that I can get the acme.sh part to work.

I know that acme support is being added to TrueNAS but until it supports my DNS provider (Beta 2 just supports Route53) I will still need this.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
Anyone know if the deploy_freenas.py part of this resource will work on TrueNAS 12?
I recently merged a PR to update it to use version 2 of the API. With that change, it should work with TN12.
 

Herr_Merlin

Patron
Joined
Oct 25, 2019
Messages
200
The ECC working report is really nice if it will be integrated!
I disabled for whatever reason ECC in bios on one of the servers.. rest well you may assume! so it would not only help for wrong hardware as well as wrong configuration much more common.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
The ECC working report is really nice if it will be integrated!
Does this have something to do with this thread? Because it doesn't look like it does.
 

budmannxx

Contributor
Joined
Sep 7, 2011
Messages
120
Scripts and cron job have been working flawlessley for me, but now I'm running into an issue. Something broke, and the update process stopped working. I didn't notice for a while, but now that I have...I'm getting a "new" cert issued, but it has an expiration date in the past. I'm sure I'm doing something wrong, but not sure what.

The first time I ran the script manually, it completed successfully. Subsequent runs required the --force option because I'm within the 60-day period, of course, but even doing that still generated a new cert with an expiration date in the past.

Any help would be appreciated. I'm on FreeNAS 11.3-U2, and deploy-freenas is located at /root/
 
Joined
May 4, 2016
Messages
4
Just wanted to share in case anyone else has a similar issue. I was having an problem renewing the cert via a cron command in the FreeNAS GUI. I was calling "/root/.acme.sh/acme.sh --cron" but it wasn't renewing unless I ran the same command from the command line and I was getting the following almost empty output from the acme script when it was run by cron:

Code:
[Thu Sep 10 14:02:44 AWST 2020] ===Starting cron===
[Thu Sep 10 14:02:44 AWST 2020] ===End cron===

I changed the cron job command to "/root/.acme.sh/acme.sh --cron --home /root/.acme.sh/" and it works now. I probably missed a step somewhere in the process or installed it to the wrong location.
 

airflow

Contributor
Joined
May 29, 2014
Messages
102
This script (https://github.com/danb35/deploy-freenas/) is awesome and I use it already for quite some time successfully to update the certificate of the GUI's certificate on a regular basis.

I'd like enhance the functionality of the script to not only enable the certificate for the GUI of FreeNAS, but also for the WebDAV sharing service of FreeNAS (which also uses a certificate when used with HTTPS).

I checked the freenas/api/docs/, and there are some api-calls which refer to the webdav-service, but I lack the understanding about how to use it and put it in the deploy-freenas script. Has anybody tried this or even pulled it off?
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
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.
 

thepixelgeek

Patron
Joined
Jan 21, 2016
Messages
271
Unsure if it's related to updating to 12.0-U1, but it appears that my acme.sh is "not found" after running the cron job.

/bin/sh: /root/.acme.sh/acme.sh: not found
 

thepixelgeek

Patron
Joined
Jan 21, 2016
Messages
271
Curious; I updated to 12.0-U1 a few days back and haven't seen this. Is the .acme.sh/ directory still present under /root/?
Oddly enough, no, I don't see it.

1608895480395.png
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,464
What happens if you boot into the previous boot environment? Is it there then? If so, might want to run a copy of it onto your pool.
 
Top