mirror of
https://github.com/acme-dns/acme-dns.git
synced 2026-04-27 12:55:48 +03:00
[GH-ISSUE #171] Use DNS validation for tls = "letsencrypt" #69
Labels
No labels
Documentation
Documentation
bug
enhancement
feature request
feature request
help wanted
pull-request
question
security
security
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/acme-dns#69
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @danb35 on GitHub (Jun 29, 2019).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/171
In light of the recent update to README that seems to pretty strongly encourage using
tls = "letsencrypt'rather thantls = "cert"in the config file, IIRC, acme-dns uses HTTP validation for the former case. It would be nice if it would instead use DNS validation--many installations may not want to open web ports for this installation to the Internet. It seems this should be pretty straightforward to do (easy for me to say, of course), since it directly controls that validation mechanism.The only user-facing issue I see with this is setting up the initial DNS CNAME record for _acme-challenge.auth.domain.tld--what subdomain should it point to?As I think about it, this doesn't need to be an issue at all--since acme-dns acts as the authoritative DNS server for its subdomain, it can respond directly to TXT queries on _acme-challenge.auth.domain.tld; no CNAME record needs to be set.@HEP85 commented on GitHub (Jul 17, 2019):
+1 on this
I thought the purpose of this tool is to avoid using the http-01 challenge. I don't want to open another port. As @danb35 suggests, it is completely feasible to use dns-01 challenge, because we have already zone delegation. What is the reasoning behind this?
@cfazzini commented on GitHub (Aug 27, 2019):
+1 on this as well.. it would be nice to able to obtain a cert for acme-dns without opening an external port. ACME-DNS needs to be able to respond (and be updated) to _acme-challenge.auth.example.org.
@cfazzini commented on GitHub (Aug 28, 2019):
Turns out the solution to this is pretty simple. After registering a new subdomain to authenticate, you can add this CNAME to your config.cfg. You can other record types to the "records" structure. Add a new entry of "_acme-challenge.auth.domain.tld CNAME [uuid].auth.domain.tld", and now you have CNAME for your auth server in a perfectly fitting way. :)
@danb35 commented on GitHub (Aug 28, 2019):
Sure, that's the easy part. But you're still obtaining and renewing the certs outside of acme-dns, which the docs now explicitly discourage--they strongly encourage setting
tls = "letsencrypt", which would have acme-dns obtain and configure its own cert automatically. But it only does that using HTTP validation.@cfazzini commented on GitHub (Aug 28, 2019):
Certainly, if it could update it's own certificate via DNS validation that would be preferred. Another option mostly within the current framework, is to put the TXT record in the config file. This mostly worked, though I had to modify the ParseRecord function because it converts the record to lowercase, which invalidates the authentication string. This also requires a second restart of service (once for TXT record, another for new cert) This approach should prevent the chicken/egg situation of cert expiring, unless the service won't start with an expired certificate. Still requires an external client however.
@joohoi commented on GitHub (Oct 20, 2019):
This was implemented in #190 and is included in v0.8 just released!