Tls dns directive in V2

[dkebler (David Kebler)]

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

V2 modules and cross compile

ok that worked. For others who might need more explicit directions In your github account fork https://github.com/danlsgiga/tls.dns Rather than pull down change/commit and push you can edit the file in place in your browser https://github.com/<username>/tls.dns/blob/master/go.mod Edit the first line replacing caddyserver with your github username At the bottom set a commit message and save Go to repo main page and click on commits. Find your last commit and click on the copy the commit ha…

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?

[matt (Matt Holt)]

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!

[dkebler (David Kebler)]

So now bit confused. You say route53 is not supported but I already modified https://github.com/danlsgiga/tls.dns 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.

#!/bin/bash
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.

[matt (Matt Holt)]

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

@dkebler

So now bit confused. You say route53 is not supported but I already modified https://github.com/danlsgiga/tls.dns repo per this post V2 modules and cross compile and used that with xcaddy build successfully.

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.

@dkebler

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.

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.

@dkebler

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 name

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.

@dkebler

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

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

@dkebler

You are encouraging me to migrate but then saying V2 can’t recreate what I have running in V1

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

Instead of:

tls {
    dns route53
}

it’s:

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.

[dkebler (David Kebler)]

Ok the tls directive was in the wrong place in caddyfile

My steps.

1. Build caddy with xcaddy like so

#!/bin/bash
DIR="$(dirname "$(readlink -f "$0")")"
ARCH=${1:-amd64}
echo Caddy Executable will be in $DIR/$ARCH
OS=linux
REL=v2.0.0
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 github.com/iamd3vil/caddy_yaml_adapter \
   --with github.com/caddy-dns/lego-deprecated
echo ...done building
[ -f $DIR/$ARCH/caddy ] && $DIR/$ARCH/caddy version

lego is there

./caddy build-info | grep lego
github.com/caddy-dns/lego-deprecated v0.0.0-20200501163854-13fbe57f9942 h1:yWkzhqcbUVfN71CdCfz1Er0zDHEuE8UTabJmsdwDxHY=
github.com/go-acme/lego/v3 v3.6.0 h1:Rv0MrX3DpVp9Xg77yR7x+PCksLLph3Ut/69/9Kim8ac=

2. Run caddy like so

#!/bin/bash
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
*.adomain.net:80 {
   redir https://{label1}.adomain.net{uri}
}

# Git Server
https://git238.adomain.net {
    import r53
    reverse_proxy / http://nas.adomain.net:3000
    }

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.

[git238.xxx.net] [git238.xxxx.net] acme: error presenting token: route53: failed to determine hosted zone ID: zone net. not found for domain _acme-challenge.git238.xxxx.net.

[matt (Matt Holt)]

@dkebler

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.

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.

[dkebler (David Kebler)]

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.

[dkebler (David Kebler)]

Looks like in lego I need to supply the hosted zone as env variable.
https://go-acme.github.io/lego/dns/route53/

I did. Still getting the same error

[dkebler (David Kebler)]

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.