Shouldn't verification via DNS record be a priority?

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.

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.

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

5 Likes

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

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

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

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

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.

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

1 Like

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”

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

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.

Can you please provide the steps or a mini walkthrough?

1 Like

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.

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

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

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:

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

1 Like

That kind of makes sense, since you can delegate subdomain to different parts of the business.
What they could do is to add two options, one per domain and one for all domains, but again they do not like the wildcard verification techniques.

@jonher937 just because the DNS can “walk up” that doesnt mean that you cant set different “accounts” which can also correlate to parts of business for subdomains, but since the owner of the root surely can complete the challenges for the subs, my Idea is that if you already have the root then it should be no problem using the subs without re-challenge.