Register endpoint with configurable subdomain
Closed this issue · 3 comments
I am interested in using acme-dns but I am wondering something. What are reasons for acme-dns to choose the subdomain itself?
I see an opportunity to automate things even more if I could choose the subdomain myself, in advance.
- That would allow me to create the CNAME record early on.
- The first certificate issuance could therefore be fully automated.
depending on where you host your DNS zone , you can already do that with some tooling
when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA
i think having the subdomain be defined manually by human intervention is just asking for trouble
depending on where you host your DNS zone , you can already do that with some tooling
when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA
The point of ACME-DNS is to be able to automate renewal of TLS certificates with DNS-01 challenges securely: without storing a high-privilege API token on the server that needs the TLS certificates (see article from EFF: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation).
If the DNS hosting provider is already providing a API token with restricted-permission (update of a given TXT record only), then I do not need ACME-DNS.
If the DNS hosting provider is providing me with a high-privilege API token, then I am back with the problem that ACME-DNS was trying to solve initially.
So I do not understand how the solution you propose brings any value.
i think having the subdomain be defined manually by human intervention is just asking for trouble
What would those trouble be?
Certificate issuance and subdomain registration are already separate. When and how you perform those steps depends on the ACME client. Is there a particular ACME client you're using?
On the first run, LEGO's acme-dns provider will call /register to get a subdomain and will save the credentials to a file (see ACME_DNS_STORAGE_PATH). Then it prompts you to manually set the CNAME. You could instead call /register yourself (using curl, for example), set up the CNAME, and create that file manually. This causes LEGO to skip the registration process, since you're providing an existing subdomain, and issue a certificate right away. I'm doing this in one of my projects to pre-register subdomains.
acme-dns doesn't need any changes to support this, although your ACME client may. I may be able to point you in the right direction.
having the subdomain be defined manually by human intervention is just asking for trouble
What would those trouble be?
Presumably name collisions and ownership issues. If you're picking a subdomain name without checking if it's already been assigned then someone else may already own it. If you set up the CNAME then someone else can issue certificates for your domain. Even if you try to use an unguessable UUID, an attacker can look at your DNS records to see the dangling CNAME, then try to register the subdomain before you can.
The only way to do this safely is to register the subdomain with acme-dns before you set the CNAME. This way you know that no one else has credentials for the subdomain. Since you need to call /register first, you may as well let acme-dns pick the subdomain name for you. Then it's just a matter of configuring your ACME client.