Ubuntu 20.04 / obtained from Caddy download site / systemd to manage service
not applicable / run via systemd at startup
c. Service/unit/compose file:
# For using Caddy with a config file.
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
# See https://caddyserver.com/docs/install for instructions.
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
I have been reading through the documentation and I simply cannot grok what we are supposed to do to get DNS-01 challenges working for wildcard certs with Letsencrypt. I have gotten so far as installing the custom build for Route53 and creating an IAM user with the appropriate policies for the hosted zone, but the “example” directive is missing information. The Github documentation shows you this to put into your Caddyfile:
That’s correct. The tls directive is a directive like any other, it goes in a site block. It is not an HTTP handler directive though, so it doesn’t support matchers, and you can only have one per site.
The libdns repo’s README describes how authentication is done (as linked to from the caddy-dns README):
Respectfully, no, it doesn’t. If one wants to learn how to configure this thing, they go to the module documentation: GitHub - caddy-dns/route53: Caddy module: dns.providers.route53
Which 1) does not contextualize the tls() directive for a new user and 2) says nothing itself about configuration but instead links you to the libdns documentation, which if you’re an inexperienced user looks like you’re already “off the reservation” because there is no longer any reference to Caddy: GitHub - libdns/route53: AWS Route53 provider implementation for libdns
Then the libdns documentation also says nothing about where to put configuration variables and instead refers you to the AWS documentation: Configuring the AWS SDK for Go - AWS SDK for Go (version 1)
Which is full of extraneous information and only tells you what you already knew: “golly, just put your IAM API creds into ~/.aws/credentials under the profile name you picked!” Except that doesn’t get you much closer to a working DNS entry unless you have also figured out that the service account the Caddy package you originally picked to install has a “homedir” in /var/lib and that’s where you can put the .aws/credentials file.
I love Caddy, but this is really terrible UX from a documentation perspective. I hope the maintainer will accept PRs.
People generally find their way there via this wiki, which covers what you need to know:
The expectation for the docs in plugin repos are that you already understand how to use Caddy and have read the docs. It can’t teach you everything, because then information would be repeated and more easily made outdated over time. Bitrot etc.
That’s because you are “off the reservation” as you put it. libdns plugins are community maintained.
Right, because it would be redundant to repeat that information when it’s best described by the official AWS docs.
That’s fair, we could better document that the $HOME for the systemd user is /var/lib/caddy. Assuming you went through Install — Caddy Documentation then you could have clicked the caddy.service link and seen in the service file User=caddy which should lead you to find that user’s home (tip: run eval echo ~<the user you want>, e.g. eval echo ~caddy which will output /var/lib/caddy)