LetsEncrypt Issue
- Thread starter AidySmith
- Start date
Hi Richard,
actually in all the other domains I've imported from cPanel I only have _acme-challenge and it's the first time I see _acme-challenge-test... but it's also the first time I created an account straight from inside DA so I thought it was a DA standard.
I'm only a user with a reseller plan and no root access to the server, so I can't tell you how DA is configured.
Where do you think should be the config problem about the added "-test"?
actually in all the other domains I've imported from cPanel I only have _acme-challenge and it's the first time I see _acme-challenge-test... but it's also the first time I created an account straight from inside DA so I thought it was a DA standard.
I'm only a user with a reseller plan and no root access to the server, so I can't tell you how DA is configured.
Where do you think should be the config problem about the added "-test"?
Hi Richard,
actually in all the other domains I've imported from cPanel I have _acme-challenge and it's the first time I see _acme-challenge-test... but it's also the first time I created an account straight from inside DA so I thought it was a DA standard.
I'm only a user with a reseller plan and no root access to the server, so I can't tell you how DA is configured.
Where do you think should be the config problem about the added "-test"?
actually in all the other domains I've imported from cPanel I have _acme-challenge and it's the first time I see _acme-challenge-test... but it's also the first time I created an account straight from inside DA so I thought it was a DA standard.
I'm only a user with a reseller plan and no root access to the server, so I can't tell you how DA is configured.
Where do you think should be the config problem about the added "-test"?
Richard G
Verified User
Huh? You just wrote you added this yourself?
You said:
So you created that line. In that case I wonder which code you used, because normally the acme challenge looks like this (just a fake example):
Code:
_acme-challenge 14400 TXT "7eg-sddgOAEOw34FeQwWY53CmHvyUVFLjasdFASLGKAL3_B"You said it worked immediately when you added the -test behind it, but in that case I wonder. Did you use a normal certificate request or a wildcard request?
I wouldn't know. Never seen that -test before.
I presume you're using the newest Letsencrypt (which would be 1.1.30 at the moment?
I was wondering... even if the record name is not the proper name, why it's not written in the DNS with such name? And why once I created it manually it is then automatically updated correctly? In the end the problem seems still the same: DA not creating the DNS record, whatever the name.
I mean, I could understand the scenario where
- DA writes a wrong challenge record name in the DNS
- Let's encrypt looks for the proper one and not finding any it gives up
But this scenario is different:
- DA do not write any challenge record name
- Let's encrypt is looking for _acme-challenge-test, but there isn't such record so it gives up
- I create an empty _acme-challenge-test
- DA is then able to update it
- Let's encrypt finds it and everybody happy!
So basically, regardless of the challenge record name, if DA were able to write into the DNS it would have worked anyway. om the contrary it seems that DA can only update the record but not creating it.
I mean, I could understand the scenario where
- DA writes a wrong challenge record name in the DNS
- Let's encrypt looks for the proper one and not finding any it gives up
But this scenario is different:
- DA do not write any challenge record name
- Let's encrypt is looking for _acme-challenge-test, but there isn't such record so it gives up
- I create an empty _acme-challenge-test
- DA is then able to update it
- Let's encrypt finds it and everybody happy!
So basically, regardless of the challenge record name, if DA were able to write into the DNS it would have worked anyway. om the contrary it seems that DA can only update the record but not creating it.
Hi Richard,
I was writing when you posted so I didn't see your previous post. I created an empty acme challenge record and the value was added by DA/Let's encrypt mechanism. As I said, the problem is that DA cannot create the record from scratch but it can update the record if it's already present in the DNS (empty or with something... even a simple 0).
I was writing when you posted so I didn't see your previous post. I created an empty acme challenge record and the value was added by DA/Let's encrypt mechanism. As I said, the problem is that DA cannot create the record from scratch but it can update the record if it's already present in the DNS (empty or with something... even a simple 0).
Richard G
Verified User
Still, is this a wildcard certificat what you tried to use or a normal certificate?
If it's a wildcard certificate and you are using external nameservers then this is normal behaviour since DA needs to be able to put the DNS entry in there, which is not possible if yo do not run your own nameservers locally.
If you are not using a wildcard dns, or you're using a wildcard and you're running your own nameservers and also using Letsencrytp 1.1.30 then you're experiencing an issue which should not occur.
Best is to send in a ticket or since you're a reseller, complaint with your host so he can either update Letsencrypt or send in a ticket to solve this issue.
Hi Richard,
it only happens with wildcard.
About the nameservers: the web server and the nameservers have very different IPs (one in Birmingham and the other in London).
Are you sure the nameserver must be local? In any case, why DA cannot create the _acme-challenge record but if already present (empty) DA can updated it? That means DA, regardless of the NS location, has access and can write into the DNS. So the main question is: why DA is unable to create the record from scratch but succeeds in adding the value?
it only happens with wildcard.
About the nameservers: the web server and the nameservers have very different IPs (one in Birmingham and the other in London).
Are you sure the nameserver must be local? In any case, why DA cannot create the _acme-challenge record but if already present (empty) DA can updated it? That means DA, regardless of the NS location, has access and can write into the DNS. So the main question is: why DA is unable to create the record from scratch but succeeds in adding the value?
Richard G
Verified User
Hello Rik.
As far as I know it doesn't matter if the nameservers and web server have different ip's.
But I'm sure for wildcard that for wildcard you must run your nameservers locally like the ip's don't matter but it should look like:
ns1.yourserver.com A ip.of.your.server
youserver.com NS ns1.yourserver.com.
For NS1 this can be different.
Then wen you do a lookup like
dig -t NS yourdomain.com
the result should be the ip of your server. That's what I mean with having the nameservers running locally.
If your nameservers are like:
ns1.registrar.com
ns2.registrar.com
then your nameservers are running externally and you can't use wildcards. However, you can select every option present in the normal way.
If you tell me your domain name, I can check for you and give you better examples, unless you know already what I mean.
As far as I know it doesn't matter if the nameservers and web server have different ip's.
But I'm sure for wildcard that for wildcard you must run your nameservers locally like the ip's don't matter but it should look like:
ns1.yourserver.com A ip.of.your.server
youserver.com NS ns1.yourserver.com.
For NS1 this can be different.
Then wen you do a lookup like
dig -t NS yourdomain.com
the result should be the ip of your server. That's what I mean with having the nameservers running locally.
If your nameservers are like:
ns1.registrar.com
ns2.registrar.com
then your nameservers are running externally and you can't use wildcards. However, you can select every option present in the normal way.
If you tell me your domain name, I can check for you and give you better examples, unless you know already what I mean.
Hi Richard,
the nameservers are those provided by the hosting provider and the dig command doesn't return an IP but
<domain> IN 14400 NS <ns1.nameserver.com>
So in regard to you explanation this is not local.
However wildcard works OK, the only problem is that DA can't create the _acme-challenge from scratch, can only UPDATE it.
Basically, if I remember to create _acme-challenge="0" by hand once for every new account, everything will work OK forever. In fact calling Let's Encrypt from DA will update the _acme-challenge content as it should, even with wildcard.
So the only problem is that I have to remember to create the empty DNS entry one-off along with the creation of the account, and all will be fine.
So we are back to the main question: Why DA cannot create _acme-challenge but can update it? Doesn't sound a problem of nameservers, sounds more like a bug.
About the record name _acme-challenge-test
I've asked my provider and he has found that such name is inside scripts/letsencrypt.sh
cat scripts/letsencrypt.sh | grep _acme-challenge-test
if ! ${DIG} TXT _acme-challenge-test.${1} @${DNS_SERVER} +short | grep -m1 -q -F -- "pre-check"; then
echo "action=dns&do=add&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"&ttl=5&named_reload=yes" >> ${TASK_QUEUE}
echo "DNS challenge test fail for _acme-challenge-test.${single_domain} IN TXT "pre-check", retrying..."
${DIG} TXT _acme-challenge-test.${single_domain} @${DNS_SERVER} +short > /dev/null 2>&1
echo "action=dns&do=delete&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"" >> ${TASK_QUEUE}
That script comes with DA and I highly doubt that anybody in the webfarm wasted time renaming _acme-challenge in such script.
the nameservers are those provided by the hosting provider and the dig command doesn't return an IP but
<domain> IN 14400 NS <ns1.nameserver.com>
So in regard to you explanation this is not local.
However wildcard works OK, the only problem is that DA can't create the _acme-challenge from scratch, can only UPDATE it.
Basically, if I remember to create _acme-challenge="0" by hand once for every new account, everything will work OK forever. In fact calling Let's Encrypt from DA will update the _acme-challenge content as it should, even with wildcard.
So the only problem is that I have to remember to create the empty DNS entry one-off along with the creation of the account, and all will be fine.
So we are back to the main question: Why DA cannot create _acme-challenge but can update it? Doesn't sound a problem of nameservers, sounds more like a bug.
About the record name _acme-challenge-test
I've asked my provider and he has found that such name is inside scripts/letsencrypt.sh
cat scripts/letsencrypt.sh | grep _acme-challenge-test
if ! ${DIG} TXT _acme-challenge-test.${1} @${DNS_SERVER} +short | grep -m1 -q -F -- "pre-check"; then
echo "action=dns&do=add&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"&ttl=5&named_reload=yes" >> ${TASK_QUEUE}
echo "DNS challenge test fail for _acme-challenge-test.${single_domain} IN TXT "pre-check", retrying..."
${DIG} TXT _acme-challenge-test.${single_domain} @${DNS_SERVER} +short > /dev/null 2>&1
echo "action=dns&do=delete&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"" >> ${TASK_QUEUE}
That script comes with DA and I highly doubt that anybody in the webfarm wasted time renaming _acme-challenge in such script.
Richard G
Verified User
Hello Rik.
You can also use a nslookup command for that like: nslookup ns1.nameserver.com
which should return an ip address.
Back to your issue. It must be known first if the nameserver is locally. If the dig does not work then use nslookup.
If it's not running locally then there might be a little issue in the script, but you could have another issue on the next update.
So if nameserver is not running locally then we have to talk to SMtalk about this. Because everybody including him is saying that auto update on wildcard domains is not possible when namesevers are running externally. Because DA can't create the challenge record.
So if it works if you create a test record manually, there must be something there which I can't explain but probably isn't working as designed either.
If nameservers are locally, then there is an issue anyway because DA should be able to create the record itself.
So I guess we need DA Support or SMtalk anyway to get more clarification about what's happening. But it would be good to know for sure if NS is running locally or not.
You could ask your host. Maybe you can also ask if you're the only one having this kind of issue on the server.
I just checked and indeed that line is in there. However I only said I've never seen it before.
Maybe a bug in the script for updating then.
That depends. If your hoster is using this nameserver and one of the nameserver ip's is from the server, then they are running locally.
You can also use a nslookup command for that like: nslookup ns1.nameserver.com
which should return an ip address.
Back to your issue. It must be known first if the nameserver is locally. If the dig does not work then use nslookup.
If it's not running locally then there might be a little issue in the script, but you could have another issue on the next update.
So if nameserver is not running locally then we have to talk to SMtalk about this. Because everybody including him is saying that auto update on wildcard domains is not possible when namesevers are running externally. Because DA can't create the challenge record.
So if it works if you create a test record manually, there must be something there which I can't explain but probably isn't working as designed either.
If nameservers are locally, then there is an issue anyway because DA should be able to create the record itself.
So I guess we need DA Support or SMtalk anyway to get more clarification about what's happening. But it would be good to know for sure if NS is running locally or not.
You could ask your host. Maybe you can also ask if you're the only one having this kind of issue on the server.
The nslookup returns
server 127.0.0.1
address 127.0.0.1#53
followed by non-authoritative answer:
name: ns2.name-different-from-domain.com
address: different ip than the domain (the same of ping to the nameserver and different than ping to the domain)
server 127.0.0.1
address 127.0.0.1#53
followed by non-authoritative answer:
name: ns2.name-different-from-domain.com
address: different ip than the domain (the same of ping to the nameserver and different than ping to the domain)
About the record name, I can read the same thing of my provider here
https://files.directadmin.com/services/all/letsencrypt.sh
looking at the script.... Is it normal that the precheck uses _acme-challenge-test and the check uses _acme-challenge?
https://files.directadmin.com/services/all/letsencrypt.sh
looking at the script.... Is it normal that the precheck uses _acme-challenge-test and the check uses _acme-challenge?
The _acme-challenge-test has been introduced with version 1.1.26. It wasn't present before because it wasn't present the DNS precheck
if [ "${2}" = "dns-precheck" ]; then
What is the ${2} parameter? Seems a temporary token "dns-preckeck".
Why then it remains _acme-challenge-test="proper definitive token"?
I don't know yet... not having an environment to test this script I can only test virtually in my mind...
if [ "${2}" = "dns-precheck" ]; then
What is the ${2} parameter? Seems a temporary token "dns-preckeck".
Why then it remains _acme-challenge-test="proper definitive token"?
I don't know yet... not having an environment to test this script I can only test virtually in my mind...
The only writing of _acme-challenge-test is with the literal value "pre-check"
echo "action=dns&do=add&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"&ttl=5&named_reload=yes" >> ${TASK_QUEUE}
and this record I understand from the code was intended to be deleted when the precheck is ended
echo "action=dns&do=delete&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"" >> ${TASK_QUEUE}
so I can't understand how it happens that I end up with _acme-challenge-test with a real, working, let's encrypt token. Maybe something renames "pre-check" inside the TASK_QUEUE?
In any case sounds like a bug.
echo "action=dns&do=add&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"&ttl=5&named_reload=yes" >> ${TASK_QUEUE}
and this record I understand from the code was intended to be deleted when the precheck is ended
echo "action=dns&do=delete&domain=${single_domain}&type=TXT&name=_acme-challenge-test&value="pre-check"" >> ${TASK_QUEUE}
so I can't understand how it happens that I end up with _acme-challenge-test with a real, working, let's encrypt token. Maybe something renames "pre-check" inside the TASK_QUEUE?
In any case sounds like a bug.
Last edited:
Richard G
Verified User
I don't know, I'm not a scripter and don't have the time to look exactly what is happening with that script. I only know that when external nameservers (meaning not on the shared server itself, so for example nameservers of registrar) are used, there will be issues with wildcards.
Since all ip's can be different, even server and nameserver ip's on the same server, the only solution is to ask your host. Next to that, we can't solve your problem since you're a reseller.
If @smtalk looks at this, maybe he can see if there is a bug in the letsencrypt.sh script. But without real info, he can't help you fix things either anyway.
So I guess we will have to with for him or DA support to fix this anyway if it's a bug, or otherwise your shared server host who has the DA license has to ask for support via the ticket system.
Or maybe it's best you start your own new thread about this issue, referencing to the posts in this thread.
That still does not proove anything. Domain and server ip can be on the same server but different ip. And you shouldn't look at all nameservers.
Since all ip's can be different, even server and nameserver ip's on the same server, the only solution is to ask your host. Next to that, we can't solve your problem since you're a reseller.
If @smtalk looks at this, maybe he can see if there is a bug in the letsencrypt.sh script. But without real info, he can't help you fix things either anyway.
So I guess we will have to with for him or DA support to fix this anyway if it's a bug, or otherwise your shared server host who has the DA license has to ask for support via the ticket system.
Or maybe it's best you start your own new thread about this issue, referencing to the posts in this thread.
I just update to last version and get same problem:
Found wildcard domain name and http-01 challenge type, switching to dns-01 validation.
DNS challenge test fail for _acme-challenge-test.xxxxx.net IN TXT "pre-check", 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...
Found wildcard domain name and http-01 challenge type, switching to dns-01 validation.
DNS challenge test fail for _acme-challenge-test.xxxxx.net IN TXT "pre-check", 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...
We're going better and better...
This morning, on a newly created account, LE with wildcard has worked at the first shot, but without any real challenge!
This is what happened:
- I have no added manually anything
- Run DA LE function
- DA has created the _acme-challenge-test record with the value "pre-check"
- Let's encrypt was happy with that and released the certificate
- In the DNS has remained _acme-challenge-test with value "pre-check"
- The domain is now working with a proper certificate validated by LE
I've run LE a second time and all remained this way.
So I ended up with a proper certificate without any real challenge.
PS: I'm talking privately with smtalk since yesterday and I'm going to give him the result of bash -x
This morning, on a newly created account, LE with wildcard has worked at the first shot, but without any real challenge!
This is what happened:
- I have no added manually anything
- Run DA LE function
- DA has created the _acme-challenge-test record with the value "pre-check"
- Let's encrypt was happy with that and released the certificate
- In the DNS has remained _acme-challenge-test with value "pre-check"
- The domain is now working with a proper certificate validated by LE
I've run LE a second time and all remained this way.
So I ended up with a proper certificate without any real challenge.
PS: I'm talking privately with smtalk since yesterday and I'm going to give him the result of bash -x
Last edited:
Richard G
Verified User
@Glio: I had the same with some other domain of mine. The day after it updated without issues. Looks like Letsencrypt has some reach issues sometimes.
@Rik: That's good news. Going better indeed. I still don't understand why tehre are challenges both with and without -test but I don't need to know everything and as long as it works it's good.
Good you're talking with smtalk privately, he is way more able to shed some lines on things or confirm a possible bug when present.
@Rik: That's good news. Going better indeed. I still don't understand why tehre are challenges both with and without -test but I don't need to know everything and as long as it works it's good.
Good you're talking with smtalk privately, he is way more able to shed some lines on things or confirm a possible bug when present.
Yes in a certain way it's true but
- with 2 different challenge record names used at random
- with _acme-challenge-test that get filled with "pre-check" without any token
- with more than 60 domains imported from cPanel that have _acme-challege and a proper token
I wonder what is going to happen when it's renewal time: if the automatism doesn't work I'd better go with the alaskan bush people to escape from my customers.