I’m trying to run two Caddy servers (one bound to IPv4, one to IPv6) from a single Caddyfile (to avoid dual-maintenance). The IPv4 server uses automatic HTTPS/TLS with Let’s Encrypt certificates, the IPv6 server should load said certificates explicitly (to prevent expiry renewal race conditions between the two servers using the same keys).
To achieve this, I need to use an environment variable as part of the import statement to properly form the tls statement in the imported file.
The tls statement in the import file uses placeholders (which I think should be OK), but the import of the file is failing with this:
ADDRESS is defined at startup (and used successfully elsewhere in the Caddyfile for bind), so I can only assume that import’s pattern matcher doesn’t expand variables before matching.
If that’s the case, any suggestions on how I might be able to achieve the same effect?
2016/08/18 07:32:19 2001:470:8a59::27.tls:1 - Parse error: Unable to load certificate and key files for ‘www.friendsr.us’: open /etc/ssl/caddy/.caddy/acme/acme-v01.api.letsencrypt.org/sites//.crt: no such file or directory
Aside from vague concerns about the directory structure (as I fear tying the directory path to the upstream cert provider will one day bite someone in the ass), is there any way (short of many variables, which in my use case simply wouldn’t work) to get imports to grok $hostonly?
I naively assumed that placeholders were supported by the tls directive - if not, it’s going to make a mess out of trying to refer to the automatic HTTPS certs directly.
Since Caddy won’t allow more than one bind, the only way to achieve automatic HTTPS with dual-stack without taking ports 80 and 443 for every interface on the box is to run two instances (preferably from one Caddyfile to avoid dual-maintenance headaches, hence the above) - one for v4 and one for v6.
When doing this, the last thing you want is for both instances of Caddy to try to automatically manage the certs, so the concept was to have the v4 instance auto-manage them and the v6 instance “inherit” them as above.
It may well have been moot, however - it occurred to me that the “inheriting” instance probably won’t notice when the certs are swapped out from underneath it when updated by the managing instance and would have to be manually restarted to pick up the change…also not very clean.
My kingdom for multiple binds… LOL
(As an aside, if multiple binds are ever going to be permitted, I’d like to throw my hat in the ring for requesting considerable flexibility in this regard…and I think I have a pretty common and valid use case for it. If you’re interested, I’ll open another thread to discuss that specific issue.)
Okay, right, well definitely don’t do that. You don’t want Caddy instances stepping on each other. We can continue the multiple bind discussion in the issue on GitHub if we want to start taking action on that.
I’ve taken a first stab at a possible configuration description/spec for the Caddyfile, at least, as a comment to the Github issue. It’s by no means perfect, but hopefully it spurs further discussion - I feel pretty passionately that this is -very- important for wider adoption of Caddy (something I would really like to see!).