letsencrypt.sh dns verification on external dns server before proceeding with acme challenge.

WizardX

Verified User
Joined
Aug 1, 2006
Messages
21
Hi there,

When customers try to request wildcard dns-01 certificates, or renew we often run into the issue that the TXT record propagates too slow over all external hosted dns servers. Therefore we got a lot of timeouts like the one below.
I was digging in the letsencrypt.sh script and was wondering if there's an option to verify the TXT record against a random dns server (for instance Google Public DNS) before proceeding the challenge with letsencrypt? Maybe one of the DA guru's already has a solution to this issue and is willing to share it with me :)

*@da2:/usr/local/directadmin/scripts# ./letsencrypt.sh renew *.nl
Found wildcard domain name and http-01 challenge type, switching to dns-01 validation.
DNS challenge test fail for _acme-challenge-test.*.nl IN TXT "pre-check", retrying...
Retry failed, trying again in 15s...
Requesting new certificate order...
Processing https://acme-v02.api.letsencrypt.org/acme/authz-v3/*...
Processing authorization for *.nl...
Challenge is valid.
Processing https://acme-v02.api.letsencrypt.org/acme/authz-v3/*...
Processing authorization for *.nl...
DNS challenge test fail for _acme-challenge.*.nl IN TXT "9IgN5LIredmqCFEhKTXhBkG2a80_Q5bkcg6nZeUbPAo", retrying...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
Retry failed, trying again in 15s...
DNS validation failed. Exiting...
 
Unfortunately not. It seems wildcard certs using external dns does not work.
 
Correct. Wildcard certs on external DNS do not work. However, you can select every checkbox present which will work. Only difference is that future subdomains added will not be included already.
 
Correct. Wildcard certs on external DNS do not work. However, you can select every checkbox present which will work. Only difference is that future subdomains added will not be included already.
But why is it? It used to work in the past....
 
But why is it? It used to work in the past....

IMHO validation simply happens too fast .. pre-check starts immediatly - that is ok , but it takes up to 20 secs for the challenge record to appear in local-dns-master-config .. while then the validation-check on 8.8.8.8 is already happening .. not even the nsslaves may have recieved the updates by then .. so i think delaying the 2nd validation by x seconds would address the issue. (customoption required)
 
not even the nsslaves may have recieved the updates by then ..
Isn't that something which can be adjusted by the solution smtalk pointed to in post #2 here?

However, I guess this is not the reason that it won't work on external nameservers anymore if it worked before.
In Plesk it does not work either, Logically, because the panel can not put a validation record in the external nameserver automatically.

So I think it has to do with validation methods.
However I don't understand why it does work when you just all selection options present. Maybe there is a difference in validation. I wouldn't know.

Maybe DA support or smtalk can explain that to you.
 
I don't believe that. I think Letsencrypt changed the way verification was done some time ago.

As far as I could understand from the letsencrypt community:
a.) Normal SSL (and also selecting all options) requires only http-01 challenge.
b.) For wildcard SSL a DNS challenge is required.

So B is not possible with external dns, maybe when you would pause the request and then create the challenge line manually in the external dns before the actual verification takes place.

I also found a topic with a kindlike request for this, which prooves it's not a DA thing:
 
i actually set "MAXTRIES=60" and "DIG_SECONDS=15"

but i think i was missing "named_rndc 1" so enabled it and recreated the zone to start clean.

now ns-slave sync happens much faster .. resulting in a functional challenge .. i will test if it will work without tweaking the script
 
This might help slightly: I have fiddled around a bit trying to get the wildcard working; I have two slave servers at GoDaddy who will almost immediately transfer the zone files on notify. When you have your watch synced with your server-time, you could try pressing the button 10 or 5 seconds before the top of the minute. That way, DA will catch the changes in the zone file and reload the name server.
This gives the LE-script a bit more time to do its magic.
When pressing 'Save' at --:05 or so, DA has to wait for the next top-of-the-minute before it updates the slave servers and that could just be the few seconds you'll miss. I have tried this for about 5 domains now, working my way down the list and they all come up as 'Successful'.

Hope this helps..
 
Working further down my list of domains, I have noticed that DA doesn't always trigger a transfer from GoDaddy (not even sending notifies). To circumvent this, I have a terminal session open tailing the named log file to check whether named is sending notifies. If not, I'll quickly either restart named, triggering sending notifies of all domains, or adding or deleting one entry, triggering a notify at the next run. I have found that DA doesn't 'catch' the change in the zone file about 5-10% of the time. Might be a bug?
 
There is native GoDaddy integration in version 2.0 of Let's Encrypt (not yet public). I may guide you personally, if you'd like to give it a try :)
 
That would be awesome! I have all my domains on GoDaddy and some domains are suited for testing purposes. I would be happy to help testing.
 
I don't believe that. I think Letsencrypt changed the way verification was done some time ago.

As far as I could understand from the letsencrypt community:
a.) Normal SSL (and also selecting all options) requires only http-01 challenge.
b.) For wildcard SSL a DNS challenge is required.

So B is not possible with external dns, maybe when you would pause the request and then create the challenge line manually in the external dns before the actual verification takes place.

I also found a topic with a kindlike request for this, which prooves it's not a DA thing:

For B this one works perfectly for me (wildcard + external DNS): https://forum.directadmin.com/threads/letsencrypt-issue.59017/post-316694

I would like to thanks to @smtalk for mentioning about taskq_dns_post.sh
 
Back
Top