mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 23:23:32 +01:00
DNS validation and subdomains #318
Reference in New Issue
Block a user
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 @sobcz on GitHub (Mar 25, 2018).
I have a little unusual problem, I searched for solution for hours and didn't find anything. I want certificate for ftp.example.net and the only option is DNS validation, because there's no HTTP service on ftp.example.net. I also want to use the "CNAME trick" (_acme-challenge.example.net CNAME example-net.acme.otherdomain.net) for one reason or another (either there's no automated access to example.net nameservers at all, or it's "all or nothing" and I don't like the idea that the client could change any record under example.net).
My expectation was that I simply set one CNAME for _acme-challenge.example.net and it will be enough. But it isn't, because Let's Encrypt is looking for _acme-challenge.ftp.example.net. If it was only one subdomain, it would be ok to add another CNAME. But what if I want ftp01 to ftp99? I don't want to add 99 CNAMEs.
Luckily, I can now solve it using wildcard certificate for *.example.net and just one CNAME will be enough for that. But if _acme-challenge.example.net is good enough for *.example.net, shouldn't it also suffice for ftp.example.net, which is only tiny subset? Is this something that dehydrated could influence, or is it limitation of ACME protocol?
@jobe1986 commented on GitHub (Mar 25, 2018):
Unfortunately you will require a CNAME for EVERY specific host name you want to include in a certificate. Additionally this decision is not within dehydrated's control. It is a decision made either by Let's Encrypt or by the authors of the ACME protocol specification.
I will admit I too am using the CNAME method so I don't have to enable dynamic DNS for all the domains I manage, and the keys I have setup for my dynamic DNS only allow setting TXT records as an added security precaution even though the dynamic DNS zone I use is hosted o the same DNS servers as the other domains.
@lukas2511 commented on GitHub (Mar 25, 2018):
Well, that isn't something I can really help you with, sorry.
Maybe you can find a DNS service which supports aliases like
_acme-challenge.*.example.net, or create yourself a more trusted gateway API for your DNS setup that has whitelists for_acme-challengesubdomains (that's what I'm going to do for my systems), but otherwise I don't really know how to solve this.About the last paragraph: Well, at least with dns-01 this probably will never change. Think about delegated subdomains, e.g.
customer01.example.comcould be under control by a customer who wants to get a SSL certificate but has absolutely no control over_acme-challenge.example.com. Changing this would break existing behaviour, that would be really bad.Maybe this will change in the future with something like dns-02 validation, but I don't really think so. You are supposed to prove that you are controlling DNS, so prove it ;)
Also if you are using ftp01 to ftp99 subdomains you could still use http based validation or use a wildcard certificate ;)
@sobcz commented on GitHub (Mar 26, 2018):
No problem, I will manage. I was just wondering about options. I thought that client could perhaps be allowed to choose which domain to use for DNS verification (the one it wants certificate for, or its parent). Changing it to require _acme-challenge only directly under main domain would be of course wrong, for the exact reason you gave. But as it is now, it's not exactly intuitive. If I control main domain, it means I also control subdomains, so it would make sense if I could prove ownership of either, when I want certificate for subdomain. Now it feels strange, it's like kid being refused to take one cookie (certificate for specific subdomain), but free to take a full bag of them (wildcard certificate), which includes originally wanted one. :) Anyway, thanks for info.