Troubleshooting Let's Encrypt Errors

Manually debugging /.well-known/acme-challenge/letsencrypt_12345

When trying to install a Let's Encrypt certificate, if you're hitting this error for :

Getting challenge for domain.com from acme-server...
Error:
http://domain.com/.well-known/acme-challenge/letsencrypt_1472046285
is not reachable. Aborting the script.
Please make sure /.well-known alias is setup in WWW server.

we can manually test this to see what's going on.

1. First, ensure that you have letsencrypt=1 in your directadmin.conf. You can use this guide to help you do this.

2. Next, we'll want to confirm the Alias /.well-known has been added to the file

/etc/httpd/conf/extra/httpd-alias.conf

If this is not set, add it using

da build rewrite_confs

and the build script should add it into the httpd-alias.conf file for you.

3. To manually test things, create a file like this:

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

and then test it via:

http://domain.com/.well-known/acme-challenge/test.txt

which should show you "test" in the output if all is working.

4. If that works, but you still get the error, then try out exactly what curl is running. Login to ssh as root, and type:

curl -I -L -k -X GET http://domain.com/.well-known/acme-challenge/test.txt

where we'd be testing with the test.txt, while the letsencrypt.sh is testing on the letsencrypt_12345678, which is just a unix timestamp used to keep the file name moderately unique for the test.

Let's Encrypt: Manually forcing the automated renewal to test for errors

Sometimes you might want to force DirectAdmin to think a Let's Encrypt certificate needs to be renewed. We can do this by manually changing the certificate's creation time file to an older time (e.g., 61 days prior):

Assume:

Directadmin User:

Domain:

and that the Let's Encrypt SSL is currently valid with a renewal time somewhere in the future.

Once that info is filled out, type:

cd /usr/local/directadmin
echo `date +%s --date='61 days ago'` > "data/users/user/domains/domain.com.cert.creation_time"
/usr/local/directadmin/directadmin taskq --run 'action=rewrite&value=letsencrypt&domain=domain.com' --debug 3100

Let's Encrypt certificate creation works, but takes 15 minutes

Report that if your system **has IPv6 **present, but is not on a valid IPv6 network, Let's Encrypt calls may try and used IPv6, and timeout after 15 minutes, then using the IPv4.

Related discussion

Solution for the DirectAdmin setup is to edit:

/usr/local/directadmin/scripts/letsencrypt.sh

and add the -4 option to all curl calls.

The simplest way to do this is to add -4 into the ${CURL} variable, after it's been checked for existence. Find this code:

CURL=/usr/local/bin/curl
if [ ! -x ${CURL} ]; then
       CURL=/usr/bin/curl
fi

and right below it, add a line, so that it looks like this:

CURL=/usr/local/bin/curl
if [ ! -x ${CURL} ]; then
       CURL=/usr/bin/curl
fi
CURL="${CURL} -4"

so that all calls using ${CURL} will have the -4 option added.

Note, the file will be rewritten with the next letsencrypt update. Better to fix IPv6 or disable it completely.

"type": "urn:acme:error:unauthorized", "detail": "Must agree to subscriber agreement before any further actions"

When creating a certificate, if you run into this error:

{
"type": "urn:acme:error:unauthorized",
"detail": "Must agree to subscriber agreement before any further actions",
"status": 403
}. Exiting...

For User , delete your file:

/usr/local/directadmin/data/users/username/letsencrypt.key

and try again. The issue relates to a change in policy that must be approved, and the old letsencrypt.key file has to be wiped and re-generated as a sign of approval.

Related forum thread

How to revoke a Let's Encrypt hostname certificate

To revoke the certificate, please run the following (if the cert is still in-place):

cd /usr/local/directadmin/scripts
./letsencrypt.sh revoke $(hostname -f)

To stop the auto-renewal:

rm -f /usr/local/directadmin/conf/cacert.pem.creation_time

CAA record prevents issuing the certificate

This error indicates either a DNS error or a CAA record exists for one of the domains included in the request and prevents the Certificate Authority "letsencrypt.org" from being authorized to issue an SSL.

Check the following for each domain/subdomain included in the SSL request to troubleshoot this error:

1. Check for an existing CAA record that would prohibit the SSL to be issued by "letsencrypt.org" by running the following command in a terminal (change 'DOMAIN.TLD' to your actual domain):

dig caa +short DOMAIN.TLD

Keep in mind that a subdomain can have its own CAA record that overrides the parent domain. Check any other domains included in the request for the existence of this record, too.

2. If no CAA records exist for the domains included in the SSL request, you should move on to check the DNS for the domains. Run the same CAA dig this time without the "+short" and look for "SERVFAIL" in the output. If this exists in the output, it signifies a DNS problem for the domain checked. At this point, you should check for the following:

• invalid DNSSEC
  • check DNSSEC here
• general DNS errors, such as mismatched nameservers, for example.
  • check your domain's overall DNS health using IntoDNS.com

A vast compilation of tools for checking your configuration exists here:

https://community.letsencrypt.org/t/third-party-tools-to-check-your-configuration/76272

3. Make sure that you are running the latest letsencrypt.sh that uses POST-as-GET requests and that you have LEGO installed:

da build letsencrypt

4. Run the command via the command line via debug and staging modes. If you had previously requested the SSL via the DirectAdmin SSL interface, you should use the DirectAdmin-generated san_config file containing all of your selections made via the DirectAdmin SSL GUI (make sure to replace "DOMAIN.TLD" & "USERNAME" below with your actual domain and username):

bash -x /usr/local/directadmin/scripts/letsencrypt.sh request 'DOMAIN.TLD' 4096 /usr/local/directadmin/data/users/USERNAME/domains/DOMAIN.TLD.san_config /var/www/html

Now, review the output and check for errors. Pay close attention to the domains that are being tested. For example, a domain request may fail with a SERVFAIL because of an expired domain pointer included in the request. The actual domain may exhibit no DNS issues itself when checked, but if the domain pointer does, it will prevent the issuance of the SSL.

5. If you still can't figure it out, feel free to submit a ticket to DirectAdmin for examination. Please include all tests and output from said tests in your request.