When I first read about the availability of free SSL certificates from Let’s Encrypt, I was skeptical. We have been purchasing SSL certificates and domains for years via our Tucows reseller account, and I can recall when certs would cost hundreds of dollars. How could something free be as valuable as something that used to be so expensive? As I researched further, I discovered how useful they could be.
Let’s Encrypt is a free, automated, and open certificate authority provided by the Internet Security Research Group (ISRG), an organization dedicated to increasing internet security which currently claims board members from impressive organizations like the Electronic Frontier Foundation, the ACLU, and Mozilla. Through Let’s Encrypt, ISRG hopes to encrypt the entire internet, making it simple for web users to keep their connections and information private.
Let’s Encrypt use has been growing dramatically over the past few years, and it’s used widely by small sites who can’t afford commercial certs.
There are lots of articles available on how to use Let’s Encrypt certs. Here, I want focus on the validation process since I found that to be the main difference between using Let’s Encrypt and commercial certs.
Validating Let’s Encrypt certs
If you’re used to using commercial certs, the biggest benefits you’ll notice with Let’s Encrypt are that it’s free and it automatically renews. While it takes a bit more work to get Let’s Encrypt set up, these perks make it a good choice for organizations with many small websites and cost-sensitive organizations.
The biggest downside to Let’s Encrypt certs is that they only have a three-month lifetime, so they must be renewed more frequently than commercial certs. This is intentional, and encourages users to opt for automated deployment and renewal. The Electronic Frontier Foundation has created a free tool called Certbot that automates the request and renewal process.
With most commercial certs, certificates are issued when a domain is validated through an email to the domain owner. This involves a multi-step process in which an email is sent to the domain owner, the owner clicks a link in the email, and the certificate is issued. To keep things simpler, Let’s Encrypt uses an API to automate the validation process — no emails or clicking needed.
Validating Let’s Encrypt on public websites
In practical terms, Certbot creates a validation file on your site, which Let’s Encrypt then accesses for confirmation. This means your site must be publicly accessible from their servers during the request process and every three months during renewal. For public websites running common web server software this isn’t an issue. Certbot has a standalone mode, as well as plug-ins that work with Apache and Nginx. There are additional plug-ins available as well.
Validating Let’s Encrypt on internal/firewall protected websites
The requirement to use Certbot and/or their API for certificates can pose some challenges to websites that are not typically publicly available, but there are ways around these. If you are using a site that is internal only, or firewall restricted to just some networks, you’re out of luck unless you can temporarily allow access from the Let’s Encrypt servers. I had this issue when using a Let’s Encrypt cert on my Sophos virtual firewall appliance, which I used at home. Fortunately, I found some scripts I installed on the appliance that copy the validation file to a separate server that has Apache running and is accessible via a port forward from the firewall.
Validating Let’s Encrypt when using a load balancer
Another challenge we ran into was using a Let’s Encrypt cert on servers behind a load balancer. Because the validation request could go to any one of the servers in the cluster, we needed a way to make sure the validation file would be immediately accessible when hitting the load balancer. We did this initially by scheduling the renewal request during off hours, and disabling access to all the web servers but the one running the Certbot instant validation. A better solution we later implemented was to put the Let’s Encrypt directory on shared storage that all the servers could access. In our case we used Gluster.
Validating Let’s Encrypt with SELinux
The biggest challenge we ran into was SELinux, a security module we use to enhance the security of our Linux servers. We run our servers in SELinux enforcing mode, and several SELinux permissions and file contexts must be enabled for Certbot to work properly. We tried testing certificate renewals via the Certbot dry run functionality (provided by Let’s Encrypt), which is only available about 30 days before the actual renewal. Even with testing, we couldn’t fully debug the SELinux issues until we had been through several real certificate renewal cycles. This was because the dry run tests can’t simulate all the steps in doing a real certificate renewal and validation.
Streamlining the Let’s Encrypt validation process
We use Puppet, a configuration management tool, to manage our servers. We have developed a Puppet module that we now use to manage Let’s Encrypt, and can deploy certificates easily with parameters specified via Hiera parameter files within Puppet. This has drastically reduced the work involved in rolling out these certs.
Let’s Encrypt released wildcard certs a few months ago, and I’m looking forward to using those as well. Wildcard certs will validate anything under your top level domain. This means you could have all of your websites under one cert instead of having different certs for each website. I have yet to dive in to the validation process for those.
If you’ve been afraid to try Let’s Encrypt or have been skeptical of it, you owe it to yourself to at least try it out. The benefits of it being free and renewing automatically will likely outweigh some of the workarounds you may need to find to make the API validation work. After years of relying on commercial certs, I’ve been moving Highland’s clients over to Let’s Encrypt with great success.
