Re: [Acme] Assisted-DNS challenge type

[Alan Doherty <[e-mail]>]

but then if example.com sets up such a record

pointed at letsencrypt (or other)

how does my client (or theirs)
ever prove which is actually a legitimate applicant for certs for example.com??

the idea of a challenge is its only known to the client that requested the cert
thus has to be returned to the CA by the client via DNS/http whatever

now if you were to suggest the CA(or any other third party) provide a dns api to modify/update 1234.challenges.whoever.example.net. txt records

thus client receives challenge modifies the dynamic zone 1234.challenges.whoever.example.net.

thus proves to acme server following the cname it does control the zone that cnamed there

if so normal dns-01 does follow cnames? (dosn't it)

thus all you need to do is find a dns provider thats api is supported by your chosen letencrypt client
delegate a subdomain to them challenges.yourdomain.net, cname challenges to that zone and get your le client to update the txt when challenges received?

or just delegate directly _acme-cahallenges.yourdomain.net to that provider cut out the cnames entirely ;)




At 01:09 23/01/2018  Tuesday, Jacob Hoffman-Andrews wrote:
>Inspired by a thread on Let's Encrypt's community forum (https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1), I'd like to propose a new challenge type, "assisted-dns-01". The existing DNS challenge is good for a number of reasons, but it has a couple of key problems: Â - It's hard to automate, and many DNS providers may offer no automation at all. Â - Automating it may mean putting DNS credentials on a web frontend, which may increase risk. To fix that, the CA could assist the user by providing narrowly-scoped DNS hosting: It would serve only TXT records used in validating DNS challenges. The CA instruct subscribers to delegate the _acme-challenge subdomain to a subdomain of the CA's hosted DNS domain. For instance, if a subscriber has account number 1234, the CA would say: Please deploy a CNAME record like so: _acme-challenge.example.com. CNAME 1234.challenges.ca.example.net. The assisted-dns-01 challenge would th
en be validated like dns-01, except: As the first step in validation, the CA would deploy the expected TXT value at 1234.challenges.ca.example.net. Then the CA would continue to look up "TXT _acme-challenge.example.com." In a way, fetching final TXT record would be a formality: the CA could in theory stop once it saw the CNAME pointed at the right location, though most likely abiding by the terms of the BRs would require following the formal lookup steps. This challenge has the big advantage that subscribers only need to do a one-time CNAME setup, and renewals can be reliably automated without requiring that renewing systems have permission to update DNS. In effect, the CNAME record would act like a long-term delegation permitting the CA to issue continuously for the base domain. The challenge object would contain a field telling the client what the CNAME target should be. Based on this, clients can check the existing DNS and prompt a user to add the CNAME if needed, or continue a
utomatically if it's already present. Example assisted-dns-01 challenge: {   "type": "assisted-dns-01",   "token": "abc123",   "cnameTarget": "1234.challenges.ca.example.net.", } If people think this challenge type has merit, my proposal is that it be part of an extension document, not part of the core ACME doc. Credit to Joona Hoikkala, Matt Nordhoff, and forum user @_az for helping to develop this concept.    _______________________________________________ Acme mailing list [e-mail] https://www.ietf.org/mailman/listinfo/acme