Troubleshooting Let’s Encrypt/Certbot: Common Errors and Solutions

As with any issues with errors in DNS or HTTPS configuration, finding a root cause may take a while.

However, common issues arise when you need to change DNS records or enable SSL/HTTPS certificate support for a web server through a certificate provider like Let’s Encrypt.

In this article, we will go through common issues you might face in your server configuration and ways to troubleshoot them.

Navigating the World of DNS Records 

Domain is an integral part of web navigation. Without domains, it would be hard to find and identify websites.

• DNS (Domain Name System) records are what DNS consists of. They keep the information about a domain and allow you, the domain owner, to control the data DNS records preserve (you can point out what content you keep under a domain). If you have multiple domains, you'll have separate DNS records for them.
• A record is one of the most common DNS records, which signifies an IP address of your server. A type of DNS record allows browsing a website through the domain. Thus, even if the IP address of the website is unknown, a website can be browsed through A records. A records can also be used for a blackhole list on the DNS; with it, you can block unwanted content, like spam mail.
• AAAA DNS records allow assigning IPv6 addresses to hosts (computers or devices) on the web. IPv6 is a communication protocol that can locate and identify computers across the web. AAAA records are a part of IPv6 and allow assigning an address to a host or a host to a specific address. Network administrators widely use this type of DNS record for linking their devices with custom addresses. AAAA is similar to A records. However, it offers more recent data on addresses. So, if a website already uses IPv6 protocol, you must use AAAA DNS records.
• Nameserver records are used to identify which DNS server your domain belongs to. It tells users which DNS to access to find an IP address for your domain.
• .CHAME records create an alternative directory for your domain so that when, for example, a user types your domain name in the wrong order, it can still redirect them to your website.
• Mail exchange records hold data about mail servers for receiving messages sent to your domain; they also direct users to A or AAAA DNS records to point to an address where your mail server is hosted.
• And finally, TXT records allow you to add additional information about your domain in DNS.

DNS records are essential for connecting a domain to a hosting server, thus ensuring that your website is up and running.

There are options to create, edit, or delete DNS records. Further, we'll see what it means.

Mastering the Art of Updating or Migrating DNS Records

So, DNS records can be updated and migrated. Both processes take some time, depending on the records you want to change. When you update DNS records for a domain, it can take up to 48 hours for changes to apply.

The waiting period is called DNS propagation. DNS propagation is when ISP (Internet Service Provider) nodes update their database with the new DNS information regarding your domain.

Some users are redirected to your old server during DNS propagation, while others can access your website on a new server if you decide to migrate your DNS records.

The duration of DNS propagation is influenced by TTL (Time-To-Live), your ISP, and location, and therefore, is hard to predict generally. However, you can use online DNS checkers to see whether the DNS record data has propagated across multiple servers randomly selected worldwide. With the help of a DNS checker, you get to see whether your website has propagated in accordance with changes made for all servers across the world.

In some cases, your ISP might update slower than your remote server. To check if this is the root of the error, you can use "nslookup" command to see if the local update results match global DNS resolvers. If there are no errors with this aspect, but your results still don't match, the error could lie in a longer value of TTL.

The TTL value should be indicated next to the A records and can be customized. If you want to apply changes to the DNS records faster, you can lower the TTL value; this might help eliminate the error.

Let's cover the basics.

HTTPS protocol uses encryption for secure communication between web browsers and web servers. The "S" part of the HTTPS stands for "secure" and is governed by TLS or SSL encryption. Many performance issues have been avoided due to LetsEncrypt and its accessible SSL/HTTPS certificates.

A website that cannot provide a secure connection usually has errors with HTTPS configuration, not necessarily HTTPS itself. In any way, if errors are unresolved, users will see error notifications while trying to access your website.

If you have an application for an HTTPS gateway like Nginx Reverse Proxy, and the gateway has the wrong configuration, errors like 502 "Bad Gateway" error might appear.

Similarly, if you're not using a commercial HTTPS certificate but a LetsEncrypt certificate instead, errors might occur due to the need for certificates from LetsEncrypt to be renewed after some time. In this case, you'll get an error notification that says, "Your connection is not private", with an error being described as "NET::ERR_CERT_DATE_INVALID". That means that you should update your LetsEncrypt certificate.

Usually, with the initial configuration of LetsEncrypt, you get an option of automatically renewing your certificate. Alternatively, LetsEncrypt will send a notification to your email saying that your certificate is about to expire. If, for some reason, both ways fail to work, you can renew your certificate manually through "sudo certbot renew --nginx -d example.com -d www.example.com".

You need to restart your web server to eliminate the error associated with an expired certificate. If you want this operation to run automatically, you can use the command "systemctl restart nginx" after manually renewing your certificate.

Solving the Mixed Content Issue

The mixed content error appears when the website a user is trying to access is loading both HTTPS and HTTP protocols simultaneously. HTTPS and HTTP are inherently different protocols. Thus, when you switch to HTTPS but do not transfer all of your data to HTTPS, and HTTP governs some of your content, you'll get a Mixed content error.

Most browsers will display an error notification like "Your connection to this site is not fully secure".

In any case, most mixed content errors in a browser appear right after a user migrates from HTTP to HTTPS. However, there can be additional sources of this problem, including:

• Your graphic content (video or images) not being in HTTPS.
• You've added a plugin or a new service to your site that doesn't match with HTTPS.

It might be hard to find the root cause of a browser error until you start troubleshooting.

The most important steps in troubleshooting mixed content browser errors are installing SSL certificates and transferring from HTTP to HTTPS site-wide.

For example, if you're using an Nginx proxy and an application for your web server, you can add additional SSL certificate configuration to a location section.

If you're not using a Nginx proxy and an application for your web server, see if the HTTP content is available via HTTPS. You can replace "http" with "https" at the beginning of your content's URL. Then, you can update URLs in your database.

Running Let's Encrypt's Certbot Script

LetsEncrypt's Certbot script can have internal errors for a variety of reasons.

Sometimes, you get a non-responsive Certbot script that can result in your session running out with the firewall dropping the traffic.

If the problem is with the firewall, you'll get the following notification: "certbot --nginx -d example.com -d www.example.com".

If this is the case, ensure you can open 80 and 443 ports before you run Certbot, and there's no firewall blocking them. If you're using an Uncomplicated Firewall with Nginx, try the "Nginx full" configuration through "sudo ufw allow 'Nginx Full'".

After you change the settings within your firewall, restart Certbot. If upon Certbot reboot, you get "too many failed authorizations recently", you'll have to wait for some time to access Certbot.

If any other Certbot errors that don't concern DNS or connection are present, consider reinstalling Certbot.

Troubleshooting HTTPS When There Are No Visible Errors

Now, if you have reinstalled Certbot and ensured that the DNS is working correctly, but some content of your website is still on HTTP, there might be an issue with the web server configuration.

Certbot usually tries to update web server configuration files automatically (this is usually done by specifying "nginx" in the command window). But if your web server configuration is complex, automated Certbot operation may not cut it, and you need to resolve the issue manually.

For Certbot to automatically configure SSL, it needs to know the "server_name" in the Nginx proxy that matches the certificate's domain. Usually, a server_name should be at the end of "/etc/nginx/sites-available/…".

You can find your server name using "nano" in Certbot, and it should look like this: "$ sudo nano /etc/nginx/sites-available/example.com", with example.com being your web server name.

If your server name isn't there, you should put it there, save the file, and verify changes through "sudo nginx -t". Then, reload Nginx. After completing this, Certbot will know which configuration file to update.

If you still encounter errors, you should manually configure your web server to HTTPS.

Nginx HTTPS configuration will have "listen 443 ssl" and a path and a key to the SSL certificate.​

In the process of Nginx proxy configurations, we recommend saving Ngnix changes through "sudo nginx -t". After you save changes, restart the Nginx proxy.

Over Let's Encrypt/Certbot Hurdles

Potential errors might seem intimidating if you lack experience using SSL or DNS.

But even though LetsEncrypt is successful and relatively easy in configuration when it runs error-free, you might need some troubleshooting insights to save time and unnecessary stress.

That's why we went over some of the common errors with LetsEncrypt and Certbot so that you can manage the arising issues efficiently.

Hope that helped!