Solved LetsEncrypt can't request SSL key for its own VPS

P

patrickkasie

Verified User
Joined
Sep 21, 2021
Messages
241
Location
Een echte Hollander
Dear forum,

Since a week or 2, I have a VPS that can no longer retrieve its own SSL key. It basically comes down to this:


[root@vps04 ~]# cd /usr/local/directadmin/custombuild
[root@vps04 custombuild]# vi options.conf
[root@vps04 custombuild]# vi /etc/resolv.conf
[root@vps04 custombuild]# cd /usr/local/directadmin/scripts
[root@vps04 scripts]# ./letsencrypt.sh request_single vps04.dhost.nl
Setting up certificate for a hostname: vps04.dhost.nl
vps04.dhost.nl was skipped due to unreachable http://vps04.dhost.nl/.well-known/acme-challenge/ file.
No domains pointing to this server to generate the certificate for.
[root@vps04 scripts]# cd /usr/local/directadmin/scripts
[root@vps04 scripts]# ./letsencrypt.sh request_single vps04.dhost.nl 4096
Setting up certificate for a hostname: vps04.dhost.nl
vps04.dhost.nl was skipped due to unreachable http://vps04.dhost.nl/.well-known/acme-challenge/ file.
No domains pointing to this server to generate the certificate for.

I've been trying to get this fixed with @Richard G , who was a great help for this matter, but we're stuck at trying the following things:

-Check if the directadmin.conf (/usr/local/directadmin/conf/directadmin.conf) has the following lines in it:
Code: 
cacert=/usr/local/directadmin/conf/cacert.pem
cakey=/usr/local/directadmin/conf/cakey.pem
carootcert=/usr/local/directadmin/conf/carootcert.pem

This is indeed present on the VPS. So I've tried the letsencrypt script with and without the 4096 keygen parameter. Neither of them work as seen above.

For the time being, I'd like to disable force ssl as it's about to expire. Where is that present? Also in the same directadmin.conf file where I have to add it?

Kind regards,

Patrick
 
It always gives a forbidden message when you visit such link, on my servers it will also give a forbidden error.

The only difference with him is that it gives this extra notice about the error document:
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
Click to expand...
 
Richard G said:
it always gives a forbidden message when you visit such link,
Click to expand...
Yes you are right :)
I have mixed this with checking that .well,known directory with SSH when checking for the test file when generating SSL key :P
That said I am still certain that there some problems with permissions., Lets wait what the topic starter has to say
 
Well should be webapps:webapps if all is correct, I already mentioned that to him in our latest conversation from December. But hopefully he hasn't missed that line. ;)
 
Active8 said:
be sure that this is accesable , check your permission setting or resetting them woth the directadmin permission script
Click to expand...
Basic question but where does the VPS manage its own public folder? I am not sure if the directadmin permissions script breaks anything. Is there anything I should check besides users being in /etc/passwd, /etc/shadow and /etc/group before executing this script?

Besides, I don't know where the VPS accesses/uses/passes the webpages to a browser. Very basic thing, I'm very well aware, I've just never had to look into that up until now.
Edit:
But hopefully he hasn't missed that line. ;)
I've actually missed that line :O
 
Hi Patrick , resetting permissions dont break anything normally.
All permissions are set to the default like you have just installed DA
If you dint have any fancy permission apllied to some folders you are safe to go
 
patrickkasie said:
I've actually missed that line :O
Click to expand...
Oeps. ?

But I hope you checked now then. Resetting permissions shouln't break anything indeed. You could also try via SSH.

Code: 
cd /var/www/html
chown webapps:webapps ./well-known -R
but this would only fix the .well-known directory, not others if needed.
 
I'm afraid I'm owning you guys a pretty response oncoming monday. Nitpicky stuff like this is ought to be done when I'm done with my main work. I'll keep you guys up to date :)
 
Alright so I've executed the script, and after an initial freeze up of my workstation 2 hours into the execution, I've tried it again. Afterwards, I've executed the commands as are seen in the screenshot. No success thusfar.
 

Attachments

  • mRemoteNG_J7b0rptijl.png
    mRemoteNG_J7b0rptijl.png
    68.5 KB · Views: 89
Nickske00 said:
Do you have ipv6 correctly setup? I see an ipv6 AAAA record, but when I test it via https://ipv6-test.com/validate.php there is an error with ipv6 on the webserver...
Click to expand...
Is this relevant to request a key? I mean, vps04.dhost.nl is a subdomain of dhost.nl, and it's included in its DNS zone, therefore it should not be having to deal with any IPv6 issues it may have
 
The script will check the challenge over http, so it is relevant. You can try adding -4 to the CURL_OPTIONS in the letsencrypt.sh script.

So change
Code: 
CURL_OPTIONS="--connect-timeout ${GENERAL_TIMEOUT} -k --silent"

To
Code: 
CURL_OPTIONS="-4 --connect-timeout ${GENERAL_TIMEOUT} -k --silent"

If this works you know it's an ipv6 issue.
 
I have changed the curl option to your reply. Sadly, there's no difference. It's still saying "No domains pointing to this server to generate the certificate for."
 
Hmm, you can try one more change to see the command the script is trying to run.

Change
Code: 
CHALLENGE_TEST=`challenge_check ${domain_name} silent`

To
Code: 
CHALLENGE_TEST=`challenge_check ${domain_name}`

So we remove the silent parameter, and now the script should also output the curl command it runs.
 
Done that, but it seems it's not doing anything right now, though idk what to make out of this. I've reverted the changes afterward.
 

Attachments

  • mRemoteNG_tQ6jN8LlrF.png
    mRemoteNG_tQ6jN8LlrF.png
    25.4 KB · Views: 93
You see in the curl command he is also using your ipv6 address. My guess is something goes wrong there..
 
But why is it doing that right now? I mean, the other VPS-es that we have are all perfectly fine with requesting an SSL certificate for those that we want, and they are most likely set up the same way as this particular one has been. Not to mention every single time an SSL certificate had been requested in the past was always succesful on this particular machine. What changed?
 
I have no idea... Maybe @smtalk can enlighten us? :D What is the reason for using the --resolve option and not letting curl figure this out by itself?

EDIT:
Trying a curl command myself to you server also fails over ipv6
Code: 
root@zeus ~ # curl -6 -k vps04.dhost.nl
curl: (7) Failed to connect to vps04.dhost.nl port 80: No route to host
root@zeus ~ # curl -4 -k vps04.dhost.nl
<html>Apache is functioning normally</html>
root@zeus ~ #

Maybe the letsencrypt script changed recently to prefer ipv6 over ipv4? So when it finds ipv6 dns records it will use them, only when they are not present ipv4 will be tried (if I read the script correctly). But if your webserver doesn't accept ipv6 connections it will fail.
 
Last edited:
I vagely remember some issue with Letsencrypt for ipv6 users. So it might be found it's way in there to fix this. Also ipv6 is the future so it's not that odd that ipv6 will be tried first before ipv4.

If you're using ipv6, it should just be installed and working correctly. If you don't use it, then removing it from the system (disable ipv6) is better.
 
You must log in or register to reply here.
Back
Top