LetsEncrypt SSL generation failing

[Syphere]

Hi!

Whenever I generate an SSL certificate using DA's LetsEncrypt function, it seemingly fails on doing so to any standard subdomains but www. (mail, pop, smtp and ftp fail). It will instead complain how the challenge files are inaccessible, like the usual:

Error: http://mail.exampledomain.com/.well-known/acme-challenge/letsencrypt_1584716630 is not reachable. Aborting the script.
dig output for mail.exampledomain.com:
2001:db8::8a2e:370:7334 (example IPv6)
Please make sure /.well-known alias is setup in WWW server.

This seemingly started happening after an update was done a few weeks ago, and I'm at a loss to know where the problem lies. The server is running OpenLiteSpeed and had always been running fine. This also happens when doing a full-request using letsencrypt.sh

I'm hoping someone knows where to look to fix this issue.
Thanks!

 

[scriptkitty]

Do you need the SSL to cover the mail subdomain? If not, you can remove it from the list of domains to cover and run LE again:

You can run the following to see what subdomains are selected to be covered by LE SSLs by default:

 /usr/local/directadmin/directadmin c | grep letsencrypt_list_selected

Run the following to change that list:

/usr/local/directadmin/directadmin set letsencrypt_list_selected www:webmail

Alternatively, If you need the LE SSL to cover the mail subdomain, make sure the .well-known/acme-challenge directories exist:

ls -lah /var/www/html/ | grep well
ls -lah /var/www/html/.well-known/

These should be owned by webapps.webapps

Make sure the mail subdomain resolves:

dig a +short mail.yourdomain.com @8.8.8.8

Now, create a test file:

echo "test" >> /var/www/html/.well-known/acme-challenge/test.txt

Now, from a terminal outside of the server, run a curl:

curl http://mail.yourdomain.tld/.well-known/acme-challenge/test.txt

The following article suggests ensuring that the .well-known Alias exists in the Apache configuration as well:

https://help.directadmin.com/item.php?id=646

 

[Richard G]

Error: http://mail.exampledomain.com/.well-known/acme-challenge/letsencrypt_1584716630 is not reachable. Aborting the script.

You might be experiencing the same issue that I had some time ago, which has to do with the order in which a challenge was made.

In my case also the www needed to be the first. So if the order is:
Certificate Hosts: www, smtp, mail, ftp etc. then all works fine.
However, if for some reason the order of things change and it will be like:
Certificate Hosts : mail, www, smtp, ftp etc, then the problem occured.

To me the reason seemed that whatever you have first, like mail, the challenge will try to reach http://mail.yourdomain.com/.well_known etc. which does not exist because it's not a website within public_html and creates the error.

I pointed this out but was told this should not make any difference. But then why did this go wrong? I have no clue.
Had this issue 2 times, after that not anymore.

If I remember correctly I solved it by changing the order back to anything where www was the first in line at Certificate Hosts. By selecting the selection options again but with www first and then create a new certificate.
But as stated, in fact this should make no difference, but I have no clue why it happens.

Be sure you're using the latest lestencrypt script. otherwise just to be sure:
cd /usr/local/directadmin/custombuild
./build update
./build letsencrypt
makes sure you have.

 

[Syphere]

...

If I remember correctly I solved it by changing the order back to anything where www was the first in line at Certificate Hosts. By selecting the selection options again but with www first and then create a new certificate.
But as stated, in fact this should make no difference, but I have no clue why it happens.

...

I just tried generating a new one again without changing the order and it failed again. Then did it again with the order changed which somehow DID work.
Yes, it *shouldn't* matter but somehow it does. Thanks for that!

...

Thanks for that, but the issue was with a user's mail subdomain, not the servers'.

 

[scriptkitty]

You might be experiencing the same issue that I had some time ago, which has to do with the order in which a challenge was made.

In my case also the www needed to be the first. So if the order is:
Certificate Hosts: www, smtp, mail, ftp etc. then all works fine.
However, if for some reason the order of things change and it will be like:
Certificate Hosts : mail, www, smtp, ftp etc, then the problem occured.

Thanks for that, but the issue was with a user's mail subdomain, not the servers'.

This is interesting! Thank you both for sharing this information. I'll definitely be taking note!

 

[Richard G]

Maybe @smtalk wants to have a look at this also. Because I also reported this in the past, in a ticket if I remember correctly, can't find it on the forums anymore, so must have been a ticket. Maybe he can find out why this happens if the correct order of things is not used and fix it.