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 [email protected] https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
