Hello,
Summary
Let’s Encrypt should host and provide access to a TXT-only DNS zone (e.g. acme-dns.net
), which will provide stable TXT names, to which domains using Let’s Encrypt can CNAME alias their _acme-challenge
records.
ACME clients will be able to call an API to update these TXT records, authenticated by their ACME Account Key Pair, that will allow successful and simplified use of the ACME DNS challenge.
Before/Now: We have to interact with our DNS Host every time we renew/issue a certificate.
After: We delegate authority of _acme-challenge
labels from the DNS Host over to acme-dns.net
as a once-off manual action, and then never worry about it again.
Background
The focus of the ACME DNS challenge has increased recently:
- TLS-SNI challenge is gone, meaning that clients that can’t use the ACME HTTP challenge are now reliant on it.
- Upcoming Let’s Encrypt wildcard support is reliant on it.
However, its usability is very poor, for a number of reasons:
- Clients choose a smattering of DNS hosts to support with their ACME DNS challenge support. Even projects like Lexicon are missing notable providers.
- The ability to automate/drive the DNS management of zones across providers is extremely spotty. There are many issues, from not supporting an API at all, to having wildly broad APIs that create a dangerous situation where ACME clients have too much privilege (in which @schoen points out the solution this idea uses) .
- Certbot has dependency/distribution issues, which makes it really hard to distribute plugins across all platforms.
Based on threads I’ve been reading/answering on these forums (where too often the fallback advice is: “you’ll need to implement an auth hook”), this seems like a major problem.
Idea
Let’s Encrypt would register a domain, such as acme-dns.net
.
Let’s Encrypt would operate nameservers to serve this zone to the internet.
Let’s Encrypt would provide an API (“ACME DNS”), authenticated by the ACME Account Key Pair.
ACME DNS would permit registration of stable TXT names ONLY within the zone. e.g. {random-128bit-base64url}.acme-dns.net
.
ACME DNS would permit update of TXT RDATA.
Domain owners would delegate authority of _acme-challenge.
names to ACME DNS via CNAME, minimizing the interaction with the DNS Host to a single event, rather than having to do it repeatedly. This also means that the interaction with the DNS Host no longer needs to be automated.
ACME Clients (e.g. Certbot) would optionally act as a client to ACME DNS while performing ACME DNS challenges, providing the user with a set of instructions (e.g. for example.org
):
- (If not already mapped previously, otherwise re-use) Automatically create new ACME DNS TXT name (e.g.
z2vkagf1y2fwdao.acme-dns.net
). - (If not already mapped previously, otherwise re-use) Prompt user to create CNAME record for
_acme-challenge.example.org
toz2vkagf1y2fwdao.acme-dns.net
). - Confirm mapping of
_acme-challenge.example.org
to known ACME DNS TXT name. - Proceed with ACME DNS challenge, but instead of requiring manual intervention or use of hook scripts, update mapped ACME DNS TXT record(s) using ACME DNS API.
Example
I am a Let’s Encrypt client.
I have a domain, example.org
. It has its DNS hosted with a provider that does not have an API.
I run:
certbot certonly --dns-acme -d "*.example.org" -d "*.foo.example.org"
I do not need to download certbot-dns-acme
because it is built into Certbot, as well as every other ACME client.
I am prompted to create _acme-challenge.example.org IN CNAME q3lks2fpy2tldgo.acme-dns.net
.
I am prompted to create _acme-challenge.foo.example.org IN CNAME cgl1a3nvz3dhzwo.acme-dns.net
.
I complete these tasks and continue. Certificates are issued.
+89 days, I go for renewal. Renewal happens non-interactively. I am not reliant on my DNS host to do anything except not delete the CNAME records.
Benefits
- Significantly simplified renewal story for ACME DNS Challenge
- All ACME clients can implement a single, lowest common denominator DNS challenge
- End-user only has to create a CNAME once per name, rather than updating a record once per issuance/renewal.
- Interaction with DNS Host is minimized to a once-off, manual event. Significantly reduces size and scope of all ACME client code.
- Does not break the ACME spec or the CAB/F BRs. Still works within the assumptions of the ACME DNS Challenge while cutting out the complexity.
- No need to trust more parties than already trusted
- Avoiding exposing additional and potentially dangerous domain registrar/DNS hosting credentials to the client environment.
- Re-using existing authentication model of ACME.
Risks
- More servers and CDN services, staff time required from Let’s Encrypt.
- Some kind of misuse of the zone? Being able to put rate limits against account keys/IPs and the fact that it only serves TXT records should mitigate this, though.
Why should Let’s Encrypt run this?
I was going to implement this myself and provide the service for free as acme-dns.net
.
However, why would anybody trust me with the delegation of their _acme-challenge
records? It creates a situation where I can fraudulently issue certificates for reliant domains.
If Let’s Encrypt runs this, all questions of trust are gone, and provides the opportunity to re-use the existing authentication mechanism of the ACME Account Key Pair.
Here’s the thing - I think this can only work with the trustworthiness of a major organisation behind it. I am fully willing to build it and run it myself, but the fact of me having to operationalize it would kill it, at least in my mind, for widespread use.
Thanks for reading …