Shouldn't verification via DNS record be a priority?

Issuance Tech
41

I’m looking at the case(s) where I want to use (non-HTTPS) certificate(s), and again having problem(s) with the HTTP file “dump” as these services are behind NATting firewall(s) and then to attempt to get HTTP (which is already NATted elsewhere) to the specific server without a different port (and upnp etc.) is close to impossible, so that is why I am also looking at a DNS authentication method, and I’m typically using at CloudFlare (which doesn’t do SSL certificates for my email/etc. :open_mouth: ) as the method to automate the DNS entries to be added.

42

Is there some kind of roadmap where progress on this highly anticipated feature can be tracked? Since it looks as if only Boulder needs some features added before we can start using it :slightly_smiling:

7 Likes
43

I’m looking forward to this too. All of my HTTP websites are just redirects to my HTTPS sites and having to open up an actual HTTP website just to do the cert upgrade every 90 days in a pain.

44

you dont even have to open an HTTP site. the http-01 already accepts redirects, so if you keep the path and stuff while redirecting then it should work without a problem.

45

DNS-01 is enabled in production. https://twitter.com/letsencrypt/status/689919523164721152

5 Likes
46

Cool! How does it work? I can’t find documentation anywhere.

47

Thanks so much for this. I was able to get it working a few hours ago.

48

The protocol specification is in ACME: draft-ietf-acme-acme-01

There are a few clients that support it already. letsencrypt.sh is one I know of.

1 Like
49

Ah, OK. So the letsencrypt-auto clients doesn’t support it yet. Thanks.

50

Just be aware the server support is broken currently for a few DNS providers (cloudflare, google domains, and dnsimple I believe are all affected). Hopefully new build of server code will make it to production soon.

51

Why or how is it broken? Doesn't DNS work the same way regardless of who provides it?

1 Like
52

If I understand correctly, there is an internal check done (at Boulder) that the DNS they check as the authoritative server is really the authoritative DNS server for that domain. Some ( such as those listed) return a null response - even though they are the authoritative server. Hence the request “fails an internal sanity check”

53

I’ve successfully completed a DNS verification with Google Domains, FYI (back when it was on staging)

54

Looks like the fix for this issue should be going in tomorrow (1/28 11am MST) according to https://letsencrypt.status.io - it’s already in staging and working there.

55

Can you please provide the steps or a mini walkthrough?

1 Like
56

The usage will really depend on your particular dns situation, but simplest - start with the letsencrypt.sh client - it’s pretty simple to set up the hook script for it - even if you do a hook that does nothing other than output the variables and wait for you to hit enter.

For example, in my case, I have a small hook script that calls out to the DNS api’s at DNSimple to add the dns record on the fly, wait for it to show up, and then let’s the letsencrypt.sh client proceed. There were others on that site that did similar hook scripts for other vendors.

57

Here’s a very simple hook that you could use for interactive population of the records:

Just point to that hook in config.sh, and set the CHALLENGETYPE in config.sh to ‘dns-01’, then issue “letsencrypt.sh -c -d mydomain.com”

58

LE team, I can’t thank you enough. It works perfectly with Cloudflare’s DNS and letsencrypt.sh.

59

Do we seriously have to add a challenge to DNS per subdomain?! And when we renew, does that mean a new challenge must be added?
If one owns a domain one owns all subdomains… :expressionless:

60

@maedox sadly yes, that's why I proposed this:

1 Like