Can't figure out how to get started w/ wildcard cert w/Route53 and Letsencrypt

Help
1

1. Caddy version (caddy version):

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

2. How I run Caddy:

a. System environment:

Ubuntu 20.04 / obtained from Caddy download site / systemd to manage service

b. Command:

not applicable / run via systemd at startup

c. Service/unit/compose file:

# caddy.service
#
# 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.

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

reticulum.us www.reticulum.us broken.works {
  reverse_proxy * 192.168.9.23:80
}

checkwithscience.com {
  reverse_proxy * 192.168.9.40:80
}

directory.broken.works {
  reverse_proxy * 192.168.9.24:80
}

git.reticulum.us {
  reverse_proxy * 192.168.9.35:443 {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

manage.broken.works {
  reverse_proxy * 192.168.9.10:8006 {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

cepheii.reticulum.us {
  reverse_proxy  * 192.168.9.22:8112
}

registry.broken.works {
  reverse_proxy * 192.168.9.20:8080
}

bwarv.broken.works {
  reverse_proxy * 192.168.9.80:443 {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

keep.bwarv.broken.works {
  reverse_proxy * 192.168.9.81:25107
}

download.bwarv.broken.works {
  reverse_proxy * 192.168.9.81:9002
}

collections.bwarv.broken.works {
  reverse_proxy * 192.168.9.81:9002
}

*.collections.bwarv.broken.works {
  reverse_proxy * 192.168.9.81:9002
}

ood.broken.works {
  reverse_proxy * 192.168.9.200:80
}

3. The problem I’m having:

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:

tls {
  dns route53 {
    max_retries 10
    aws_profile "real-profile"
  }
}

But there is no indication as to

  • Where in the Caddyfile this directive goes
  • Where it is supposed to get an AWS profile from

I’m kind of theorizing that in my example Caddyfile it would be something like this, putting the “tls” directive at the same level as the “reverse_proxy” directive:

*.collections.bwarv.broken.works {
  reverse_proxy * 192.168.9.81:9002
  tls {
    dns route53 {
      max_retries 10
      aws_profile "wildcard-user"
    }
  }
}

But even assuming that is true, I have no idea what to do next. How is it supposed to know what “wildcard-user” is? Why can’t I just specify a path to a file with the credentials in it?

Thanks in advance for any help.

2

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):

3

Hi,

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.

4

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)

5

This topic was automatically closed after 30 days. New replies are no longer allowed.