Tls dns directive in V2

Ok giving this another shot with V2.0.0 official first release.

To migrate to V2 I absolutely have to have the route53 tls dns plugin working because: 1. wildcard cert is not supported at least not yet, 2. For security I never make public dns records (at route 53) for private/lan dns records in my dnsmasq server.

Ok so I just did a new xcaddy build with v2.0.0 and the old “fixed” route-53 tls dns plugin per

That looks successful

With this v1 directive

tls {
    dns route53

in my caddy file I get this error

run: adapting config using caddyfile: /opt/caddy2/test-server/caddy.conf:2: unrecognized directive: dns

what will be the new/correct directive in V2?

Hey David –

Here are the docs for the tls directive in v2: tls (Caddyfile directive) — Caddy Documentation

As you can see, the dns subdirective looks like:

dns       <provider_name> [<params...>]

And the example below shows:

tls {
	dns cloudflare {env.CLOUDFLARE_API_TOKEN}

So that’s what it would look like (except in your case it’d be route53 instead of cloudflare, obviously).

Route53 support hasn’t been implemented for Caddy 2 yet, but the lego-deprecated module brings in all 75+ providers that you can use today. How to configure it is described on its README: GitHub - caddy-dns/lego-deprecated: (DEPRECATED) DNS modules so Caddy can solve the ACME DNS challenge with over 75 providers

That should help!

So now bit confused. You say route53 is not supported but I already modified repo per this post V2 modules and cross compile - #13 by dkebler and used that with xcaddy build successfully.

Now you are saying that won’t work? Use this other (lego deprecated). Apparently @danlsgiga has this working so just trying to duplicate his work.

Further my credentials are already in env so now I have to explicitly state what they are in dns directive? In v1 this was not required. The code knew their correct env names.

export AWS_CONFIG_FILE=/opt/tls-certs/aws-route53-credentials
sudo /opt/caddy2/test-server/caddy start --config /opt/caddy2/test-server/caddy.conf --adapter caddyfile

finally the error says it doesn’t know the dns directive. It doesn’t say it doesn’t know route53.

You are encouraging me to migrate but then saying V2 can’t recreate what I have running in V1. Should I just wait a month or something. Just not feeling the love of V2 after several hours of effort.

I think you’ve already decided you don’t want to like v2, so I won’t be able to change your mind.

That will build but it probably won’t work. I upgraded the interface just a few days ago so now DNS provider modules need to be in the dns.providers namespace, not tls.dns namespace.

Yes, I’m saying that it won’t work using v2.0.0 (or newer) of Caddy. Perhaps @danlsgiga is using a build from before the 2.0 commit that still used the tls.dns namespace.

The lego-deprecated package uses your environment variables too. Using that package, you do not put them in the Caddyfile. Please read the instructions I linked to. You’ll notice that, using that provider, nowhere are the credentials placed in the Caddyfile. This is an unfortunate limitation as it does not allow the use of multiple accounts, which some of our customers require, hence one of the reasons we are moving to new APIs.

Then it sounds like your Caddyfile is malformed? What is your entire Caddyfile (without redactions)?

It precisely can using that shim, the only thing different is one extra word in the syntax.

Instead of:

tls {
    dns route53


tls {
    dns lego_deprecated route53

because the lego_deprecated provider needs to know which provider to use and which credentials to look for.

Please follow the instructions. It works great.


Ok the tls directive was in the wrong place in caddyfile :stuck_out_tongue_winking_eye:

My steps.

  1. Build caddy with xcaddy like so
DIR="$(dirname "$(readlink -f "$0")")"
echo Caddy Executable will be in $DIR/$ARCH
echo deleting any old executable
[ -f $DIR/$ARCH/caddy ] && rm $DIR/$ARCH/caddy
echo ...building
GOOS=$OS GOARCH=$ARCH xcaddy build $REL \
   --output $DIR/$ARCH \
   --with \
echo ...done building
[ -f $DIR/$ARCH/caddy ] && $DIR/$ARCH/caddy version

lego is there

./caddy build-info | grep lego v0.0.0-20200501163854-13fbe57f9942 h1:yWkzhqcbUVfN71CdCfz1Er0zDHEuE8UTabJmsdwDxHY= v3.6.0 h1:Rv0MrX3DpVp9Xg77yR7x+PCksLLph3Ut/69/9Kim8ac=
  1. Run caddy like so
export AWS_CONFIG_FILE=/opt/tls-certs/aws-route53-credentials
sudo /opt/caddy2/test-server/caddy start --config /opt/caddy2/test-server/caddy.conf --adapter caddyfile

with caddyfile

(r53) {
   tls {
      dns lego_deprecated route53
# Main http/https redirect for anything arriving on port 80/http
* {
   redir https://{label1}{uri}

# Git Server {
    import r53
    reverse_proxy /

RESULT: working but now getting acme error. Not a caddy problem.

Still. does this version pick up the credentials the same way as the old by reading the file given in
export AWS_CONFIG_FILE=/opt/tls-certs/aws-route53-credentials I’ll double check my credentials.

[] [] acme: error presenting token: route53: failed to determine hosted zone ID: zone net. not found for domain
1 Like

Yeah, that lego_deprecated module uses (only) environment variables the same way lego, Traefik, and Caddy 1 all do.

Glad you got it mostly working. Try checking the lego issues to see if people have encountered that error before – likely a misconfiguration in the route53 zone, or possibly a bug in lego’s route53 provider.

Caddy is supposed to parse/pass the FQDN based on the the url in the directive?

The route53 acme code is supposed to be able to lookup the zone ID based on that FQDN. That seems to be the holdup.

I double checked and my policy is the same as here. Welcome to certbot-dns-route53’s documentation! — certbot-dns-route53 0 documentation and hosted zone is correct so should be allowed to lookup…hmmm

caddy/lego/acme/aws four points of possible failure…sigh

So maybe another caddy user knows what for. In the meantime I’ll check with lego and acme.

Looks like in lego I need to supply the hosted zone as env variable.

I did. Still getting the same error

Arrrh. Turns out I had bad dns forwarding out my LAN for my FQDN so dns challenge couldn’t complete. Once I fixed that the dns challenge completed.

so be sure your DNS resolves your FQDN on the internet even if you have local subdomains resolving locally.

BTW the DNS challenge (although kinda slow to complete) does work as I wished which is it will supply certs for subdomains resolved only on my LAN without need of a public DNS record for that subdomain.

Now I’m back to a caddy2 issue which is the reverse proxy is not quite working. I’ll post that as another topic.

1 Like

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