Letsencrypt SSL in 1.5 not working

Getting challenge for mywebsitename.com from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for www. mywebsitename.com from acme-server...
Waiting for domain verification...
Challenge is invalid. Details: Invalid response from http://www.mywebsitename.com/.well-known/acme-challenge/7EL5bRwHpeoxH6cdURaR7NynqCM7VuJ9Uzg0oTPsqSU [178.18.87.86]: 404. Exiting...

I have this same issue. Here I'm trying to give a certificate to a sub-domain (main domain is elsewhere). Normally, this is valid. However, the letsencrypt.sh script automatically adds a second check for "www" with letsencrypt=2 set. This will never work, so it always fails.

Why does the script do this? DA does this, too. I manage to ignore it until this point.

Sub domains do not need www!
 
letsencrypt=2 and httpd-alias.conf ./well-known/ alias clash

I have this same issue. Here I'm trying to give a certificate to a sub-domain (main domain is elsewhere). Normally, this is valid. However, the letsencrypt.sh script automatically adds a second check for "www" with letsencrypt=2 set. This will never work, so it always fails.

Why does the script do this? DA does this, too. I manage to ignore it until this point.

Sub domains do not need www!

Dan,

Apparently if you create a subdomain in DA it will also add a www. in the DNS records and have a fully self-contained location in the filesystem including it’s own webfoot.
As such, it should not be a problem.
If you created a DNS record only for the subdomain then it is probably pointing to the same location as the main domain it falls under if configured correctly.
If the certificate you are requesting needs to have both domain and subdomain in them, the webfoot for the certificate request needs to be identical for both subdomain.domain as well as the parent domain.
This is why e.g. you can enter mail.domain in the main aliases lists in the same location where the main servername is located as well.

If it is requesting a www.$domain which doesn’t exists, I suggest:
Check the subject_AltName= variable in the relevant /usr/local/directadmin/data/user/$user/domains/$domain.san_config file and remove the DNS:www.$subdomain$domain entry from the list there.
After that renew or create your certificate.

I see you have letsencrypt=2 set. Yesterday I discovered an issue with that setting in the DA 1.50.1 version.

Also with letsencrypt=2 set and DA version 1.50.1 installed,
To make sure it isn’t that issue, check if httpd- does NOT have an alias line for “/.well-known” listed.
If that entry is present it will clash with the letsencrypt=2 setting in the directadmin.conf file.
This is because it will also rewrite all $domain/.well-known/ url requests to the main document root in the filesystem which is precisely what you don’t want with letsencrypt=2 set.

For the DA team, be aware these two settings clash and give a /.well-known/acme-challenge/letsencrypt_$timestamp not reachable error in the DA message system because the curl check in the letsencrypt.sh script fails because of the above mentioned alias rule.
 
If it is requesting a www.$domain which doesn’t exists, I suggest:
Check the subject_AltName= variable in the relevant /usr/local/directadmin/data/user/$user/domains/$domain.san_config file and remove the DNS:www.$subdomain$domain entry from the list there.
After that renew or create your certificate.

I cannot do this for the 150+ sites that we host. DNS records are not managed by DirectAdmin (by that I mean, DA doesn't do the DNS for the public domains). Many of our sites use a subdomain for their hosting with us, as their main site is www.domain.com. This is normal and legit. And this is where DA fails us.

We normally manage to get around DA doing this, but now that OneClickSSL is being abandonded we have to look into LetsEncrypt. Looking more and more like we'd have to go back down the manual SSL route sadly :(

Also with letsencrypt=2 set and DA version 1.50.1 installed,
To make sure it isn’t that issue, check if httpd- does NOT have an alias line for “/.well-known” listed.
If that entry is present it will clash with the letsencrypt=2 setting in the directadmin.conf file.
This is because it will also rewrite all $domain/.well-known/ url requests to the main document root in the filesystem which is precisely what you don’t want with letsencrypt=2 set.

This isn't an issue it seems. Can't see evidence of it happening. It shouldn't ever be the case as DA has always been set up for the /home/user/domain format.
 
Back
Top