About a year ago, I wrote a script to automate installing Nextcloud in a FreeNAS jail. Since the best guides available to me at the time used Apache, so did my script. More recently, I’ve been working on using Caddy in the script instead, which is going well, except…
With the current release, users have four options regarding TLS: don’t use it at all (i.e., only use HTTP), enable it using a self-signed cert (in which case a self-signed cert is created which is valid for 10 years), or obtain a cert from Let’s Encrypt using either DNS or HTTP validation (both of which are handled by acme.sh). I have Caddy working with an equivalent to the first, third, and fourth options, but I’m not sure about the second.
The docs say I can use tls self_signed to generate and implement a self-signed cert, but that cert is only valid for 7 days (and apparently doesn’t get saved to disk). Is there a way to make that self-signed cert valid for a longer period of time? Or do I have to manually generate the cert, do tls cert key, and manually implement the HTTP->HTTPS redirect?
Caddy’s a bit opinionated in this regard - the goal is to have people using valid, secure HTTPS - so the self-signed certificate functionality is designed primarily with local development in mind, and does not renew itself past 7 days.
You would have to continually restart the web server before that point if you want a non-expired self-signed certificate indefinitely. Alternately you could generate your own 10-year self-signed cert and give that to Caddy, as you proposed.
Of course. But in the setting where I’m using it, not everyone will have a domain and/or the ability to get a cert from Let’s Encrypt (open ports and/or suitable DNS provider).
…which would generate a new cert, and therefore new cert warnings, right?
…and in that case, Caddy doesn’t automatically do the HTTP->HTTPS redirect, right?
Indeed. As I said, Caddy’s a bit opinionated about this. In my experience, though, it’s not too hard to meet these requirements, especially the suitable DNS provider (Cloudflare performs admirably and is free).
Edit: I should also mention - you’re very welcome to open an issue on the Github repo if you want to make a case for this. The devs listen to just about all requests, but given that this was a purposeful decision on the implementation, the bar might be high to argue for it to be changed.
Yes.
Correct. Automatic HTTPS also sets the default ports, so Caddy won’t do that, either; you’ll need to override the default port 2015 as well for each when you set up the site and its HTTP redirect listener.
I agree, but I’m on a static IP, I already have a domain, and I’m already using Cloudflare. And I’m already fairly familiar with how Let’s Encrypt works. Yes, Cloudflare works pretty well (though I still wish Caddy supported acme-dns), and a domain doesn’t even have to cost anything (though Freenom does seem a little sketchy). I guess DNS-O-Matic could handle the dynamic DNS piece if needed. But those are a lot of moving pieces that need to be configured by what are sometimes not very tech-savvy users (which was kind of the point of my writing the script, to automate as much of the setup as possible).
But with all that said, the changes to the Caddyfile aren’t that big. Just add a block of
http://hostname {
redir https://hostname{uri}
}
…change the main block to open with https://hostname and add the line of tls cert key. If I were smarter with automated text processing, I might be able to make this all work with a single template; since I’m not, I just have three separate Caddyfile templates (one for no SSL, one for self-signed, and one for “normal” using Let’s Encrypt) and run a couple of sed commands on them. Maybe not very elegant, but effective.