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
in my caddy file I get this error
run: adapting config using caddyfile: /opt/caddy2/test-server/caddy.conf:2: unrecognized directive: dns
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.
dns lego_deprecated route53
because the lego_deprecated provider needs to know which provider to use and which credentials to look for.
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.
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.