Looking for help deploying LetsEncrypt certs to TrueNAS Core while also using Reverse Proxy.

[GJSchaller]

I've been reading over this for a bit on various other posts, but seem to be hitting a wall... either I am missing something, or just not understanding a step. Hopefully I can clear things up with this post.

Here's my setup:

• Router, with Namecheap domain (aiskon.net) pointed to it via Dynamic DNS
• TrueNAS Core, currently with no certs other than the local one.
• A local jail running Caddy, as a Reverse Proxy pointing to various jails, using DanB35's script.
  • One reverse proxy points to my TrueNAS interface - it's a string of random letters followed by .aiskon.net
  • SSL is enabled / running in the Reverse Proxy jail for aiskon.net
• Ports 80 and 443 forward to the Caddy jail, port 21 forwards directly to the TrueNAS device for FTP use.

The end goal is to deploy the certs for aiskon.net to the TrueNAS itself, so that I can use some of the features on the NAS securely (like FTP).

When I try to run Acme.sh, it times out - I note an error that the address is already in use. I'm assuming there is a conflict between the Caddy Reverse Proxy jail, and pulling the cert to use with TrueNAS locally?

Any way to reconcile / resolve this?

 

[GJSchaller]

I'm thinking the way to do this is to point the deploy-cert.py script to the key in the Caddy jail. What I don't know is where the key is stored in the Caddy jail, or how to reference that path locally from the TrueNAS host. I'm guessing it's something like:

/mnt/(pool)/iocage/jails/(caddy jail name)/root/(this is the part I am missing)

Once I know this path, I should be able to configure deploy-cert.py to pull from that path, and deploy it to the NAS, on a nightly basis (assuming the Caddy jail renews the LE cert on an automated, regular basis).

 

[GJSchaller]

If I'm reading this article right, I should be able to set a CADDYPATH outside the Web Root, but still shared with the host via /mnt/(pool)/apps/caddy - I'll dig into this once I've had some sleep and a clearer mind, and report back if it works.

 

[danb35]

/mnt/(pool)/iocage/jails/(caddy jail name)/root/(this is the part I am missing)

The part you're missing is /var/db/caddy/data/caddy/certificates/{CA_URL}/{FQDN}/{FQDN}.{crt|key}.

 

[GJSchaller]

The part you're missing is /var/db/caddy/data/caddy/certificates/{CA_URL}/{FQDN}/{FQDN}.{crt|key}.

Perfect, thank you! Is it better for deploy-cert.py to use the .key, or the .cert, or no difference?

 

[GJSchaller]

Got the path in, now getting a new error when I run deploy_freenas.py:

Code:

root@HarlockNAS[/mnt/data/scripts/deploy-freenas]# ./deploy_freenas.py
Traceback (most recent call last):
  File "/mnt/data/scripts/deploy-freenas/./deploy_freenas.py", line 84, in <module>
    with open(FULLCHAIN_PATH, 'r') as file:
FileNotFoundError: [Errno 2] No such file or directory: '/root/.acme.sh/host.aiskon.net/fullchain.cer'

 

[GJSchaller]

Side note - if there's an easier way to do this (calling & deploying the cert from the Host itself, instead of extracting it from the Caddy server), I'd be all for it. I just haven't seen any clear documentation on how to do it yet, and with the port forwarding pointing to the Proxy, I'm not sure how to call the cert from the Host and have it verify the FQDN.

 

[danb35]

Perfect, thank you! Is it better for deploy-cert.py to use the .key, or the .cert, or no difference?

You need to use both (and therefore specify the paths to both). The .key is the private key; the .crt contains the corresponding public key (along with the certificate). One won't work without the other.

One reverse proxy points to my TrueNAS interface - it's a string of random letters followed by .aiskon.net

Be aware that all certificates (from any trusted CA; this isn't uniquely a Let's Encrypt thing) are stored in a public log--you (and anyone else) can find yours at crt.sh, among other places, and thereby determine that that string of random letters starts with fhq. I wouldn't recommend doing this unless you also integrate some authentication into the Caddy configuration for that virtual host. Security through obscurity is illusory here.

You could mitigate this somewhat by using a wildcard cert--Caddy can get them (though you'd need to check its docs to find out how), but they're only available if you're using DNS validation for the cert. But that way, the only thing logged would be *.aiskon.net; the individual hostnames wouldn't be logged.

if there's an easier way to do this (calling & deploying the cert from the Host itself, instead of extracting it from the Caddy server), I'd be all for it.

The way I did it, before I started using an internal CA for most of my LAN stuff, was with DNS validation and acme.sh. The latter works with lots of DNS hosts (around 130, last time I looked at the docs); I use and like Cloudflare. Set up an API token, and acme.sh can automatically update the required DNS records for domain validation. That way, there's no need for the system to be directly accessible from the Internet.

This way, you can also access your NAS internally by a somewhat nicer name than fhq....aiskon.net without getting a certificate error. But it might mean changing DNS providers.

 

[GJSchaller]

Got it. I do have 2FA enabled, but this is good to know. (The letters aren't COMPLETELY random, ten internet points and a bottle of Advil to anyone who gets the reference...)

Thank you for the lead on DNS Validation - since I'm using Namecheap, it looks like I should be able to get this to work, I just need to drink more coffee and dig into it later today.

 

[danb35]

This would be relevant:

GitHub - caddy-dns/namecheap

Contribute to caddy-dns/namecheap development by creating an account on GitHub.

github.com

 

[GJSchaller]

Thank you - it's applicable to the Caddy jail, but if I am going to call it locally from the Host, I'll need to go another route. I think I have it figured out using Namecheap's API, but they limit it to accounts that either have 20 domains, have spent enough money over 2 years of history, or have $50 in credit on their account. Looks like I'll need to top off my account to get access to the API to make this work.

 

[danb35]

…or move your DNS to Cloudflare…

 

[GJSchaller]

I have a bitter, irrational hatred of Cloudflare after wrestling with it multiple times over the course of my IT career. It's never worked out of the box for me, and they always seem to do a bait and switch for paid services. Maybe it's just me, but after the 3rd or so time I got burned by them, I'm avoiding them.

The less variables / vendors involved, the happier I'll be. As the saying goes, "one throat to throttle."