How to Fix Common Let’s Encrypt/Certbot Errors

If you are a Linux server administrator, you probably know that Let’s Encrypt is a free, automated, and open certificate authority (CA) that issues domain-validated TLS certificates, so you can enable HTTPS on your website or web application without spending a dime.

Previously we discussed the proper procedure for obtaining and installing Let’s Encrypt TLS certificate.

• How to Properly Enable HTTPS on Nginx with Let’s Encrypt on Ubuntu
• How to Properly Enable HTTPS on Apache with Let’s Encrypt on Ubuntu

But as with many things in the Linux world, unexpected errors can happen and this article will share some tips on how to fix them.

1. Use the Latest Version of Certbot

It’s recommended that you always use the latest version of Certbot. When an error occurred, it produces more detailed error messages that help you quickly pinpoint the problem. Sometimes an error can be fixed just by installing the latest version of Certbot.

You can use Snap to install the latest version.

sudo snap install certbot --classic

Then use the /snap/bin/certbot binary instead of the default /usr/bin/certbot binary.

sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp -d example.com

You can also create a symbolic link with the following command, so that when you type certbot in the terminal window, it automatically uses the Snap version.

sudo ln -sf /snap/bin/certbot /usr/bin/certbot

For more details about Snap packages and how to enable Snap on various Linux distributions, please read the following article.

• How to Install and Use Snap Packages on Linux

2. Use the Webroot Plugin

You can use the webroot plugin instead of apache or nginx plugin to obtain TLS certificates. I found it’s more stable and less error-prone.

So instead of running this command:

sudo /snap/bin/certbot --nginx --agree-tos --redirect --hsts --staple-ocsp -d example.com

You should use

sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp -d example.com -w /var/www/html

The -w flag specifies the webroot directory of your website/web application. In the above example, I use the /var/www/html/. You can find the exact location in your web server config file.

In Apache you should find a line like this:

DocumentRoot "/var/www/nextcloud"

In Nginx, you should find a line like this:

root /var/www/nextcloud/;

3. Timeout during connect (likely firewall problem)

Some folks might encounter an error like this:

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: mail.example.com
   Type:   connection
   Detail: Fetching
   http://mail.example.com/.well-known/acme-challenge/8aNsZkYzpbFXyWUAECaJEj1eBsVhPOokDYeNTgw4nq8:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.
Can't open /etc/letsencrypt/renewal/mail.example.com.conf: No such file or directory.

It might be that:

• Your DNS A record is wrong. Do you put the wrong IP address for mail.example.com? Please don’t enter a private IP address in the DNS A record. You must use a public IP address.
• Your DNS record isn’t propagated yet. Go to https://dnsmap.io to check if it’s propagated.
• You didn’t open TCP ports 80 and 443 in the firewall. The Certbot HTTP-01 challenge needs to access a particular web page, so you must open these two ports. If you use UFW, please read this guide: How to Use UFW Firewall on Debian, Ubuntu, Linux Mint

4. Nginx Configs don’t Take Effect.

Some folks might encounter this error:

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

This means your virtual host file didn’t load in Nginx. You should restart Nginx.

sudo systemctl restart nginx

Sometimes there’s an error in your Nginx config file. Run the following command to test it.

sudo nginx -t

Also, check the Nginx journal log.

sudo journalctl -eu nginx

I once encountered the above error because I forgot to add a server_name directive in my Nginx config file, so Nginx doesn’t know which config file to use for the Certbot request.

5. Unauthorized (404 not found)

Example error message:

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: onlyoffice.linuxbabe.com
   Type:   unauthorized
   Detail: 2606:4700:20::681a:c47: Invalid response from
   https://onlyoffice.linuxbabe.com/.well-known/acme-challenge/piqJOZM3CYsCGAmT-ZdfKI2XrvteQQEyKgtIHM6DNo4:
   526

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

You can usually find out why this error occurs by checking the error log of your web server. For example, I encountered this error when trying to obtain a TLS certificate for OnlyOffice online office suite. The Nginx web server error log has the following lines.

022/12/01 04:53:23 [error] 26124#26124: *14 open() "/var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA" failed (2: No such file or directory), client: 127.0.0.1, server: webmail.sk8deal.com, request: "GET /.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA HTTP/1.1", host: "onlyoffice.linuxbabe.com", referrer: "http://onlyoffice.linuxbabe.com/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA"

So I need to create a directory for Let’s Encrypt ACME protocol.

sudo mkdir -p /var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/

Change the owner to www-data.

sudo chown www-data:www-data /var/www/onlyoffice/documentserver/letsencrypt/ -R

Try to create a file as the www-data user.

sudo -u www-data touch /var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA

If it’s successful, then you can run certbot again to obtain TLS certificate. If you see a “permission denied” error, then you need to grant permission to the www-data user.

sudo apt install acl
sudo setfacl -R -m u:www-data:rxx /var/www/onlyoffice/

6. Dry Run

If there are too many failed attempts to obtain Let’s Encrypt TLS certificate during a period, then you will likely be refused to make further requests to the Let’s Encrypt CA server. To prevent this from happening, you can use --dry-run flag for testing.

For example:

sudo /snap/bin/certbot certonly --dry-run --webroot --agree-tos --redirect --hsts --staple-ocsp -d example.com -w /var/www/html

A dry run only works with the certonly subcommand, so you must use them together. Once you fix the error and the dry run is successful, you can obtain TLS certificate.

sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp -d example.com -w /var/www/html

Wrapping Up

I hope this tutorial helped you use certbot. As always, if you found this post useful, then subscribe to our free newsletter to get more tips and tricks. Take care 🙂