Let’s encrypt the web! All of it.

Does your website still run on plain HTTP? Would you like it to run on HTTPS? You should, because soon you might not have a choice anymore. The HTTPS saturation of the Internet has passed its half-way point and the browsers are deprecating HTTP websites. Time is running out and Let’s Encrypt is here to drive that process by helping you get up to speed on serving HTTPS.

Let’s Encrypt was officially started in 2015 and became publicly available in early 2016. It is the brainchild of two Mozilla employees who soon gained the support of the Electronic Frontier Foundation. The Internet Security Research Group (ISRG) was created as the company behind the project which also became a Linux Foundation Collaborative Project. Today it has sponsors all across the industry, the major ones no doubt being Mozilla, Chrome, Akamai and Cisco.

Let’s Encrypt the web!

The declared goal of Let’s Encrypt is to make HTTPS the standard protocol for the web and let all communication be encrypted. Over the past years, most major websites already switched and the majority of the web traffic is already encrypted. Let’s Encrypt is spearheading the push to reach 100% encryption. Since its start the rate of HTTPS adoption has increased, a big chunk of which can be attributed to Let’s Encrypt.

A strong incentive to switch comes from the browser manufacturers. The current version of Chrome will tell you that your website is „insecure“ when you click on the ℹ in the address bar. The next version will go one step further by actually putting „insecure“ in the address bar, right next to the URL. Who would want their website to be labelled as „insecure“? In addition, new features like http/2 and Geolocation are only available on HTTPS sites and some features will actually be removed from HTTP in the future. And Mozilla is on the same track.

A word about „secure“ websites. There is some debate about the term as it might suggest a false sense of security to the uninformed user.

„Securing“ a website with HTTPS does two things: traffic encryption and site authentication. While the meaning of the former is quite clear, the latter is worth a closer look. TLS certificates are issued by certification authorities (CA) which offer different levels of validation for their certificates. Domain validation (DV) is the most basic form of validation where the CA checks and certifies that the certificate owner has control of the domain for which the certificate has been issued. That’s all. On top of that they offer organization validation (OV) and extended validation (EV) where they make a greater effort to verify the actual identity of the organization applying for a certificate. EV certificates make the browsers display the organization’s name next to the URL in the address bar.

The CAs neither check nor validate the content of the web pages being served using their certificates. An HTTPS website may rip you off or install a virus on your machine just as much as a traditional HTTP website might do. The little word „secure“ does not protect web users from malicious website operators. All it means is that the data being transferred cannot be read by anybody else along the way, because it is encrypted. It also ensures that the user is not a victim of a DNS spoofing attack by validating the ownership of the DNS or even company name. That’s all the „security“ you get from HTTPS.

Still, being sure that the data you are sending across the Internet can only be read by the intended recipient is a huge benefit. Privacy is a human right and the Internet does not get a free pass on human rights. Hence the mission of Let’s Encrypt to encrypt the web.

But setting up an HTTPS web server is hard!

I have done my share of setting up HTTPS web servers, each time trying to remember the openssl commands to use, finding a good way to distribute the certificates, paying the provider and remembering to renew the certificate a year or so later. It is not that hard but it sure is a hassle. These are known problems that have kept many website operators from implementing HTTPS and Let’s Encrypt tries to address these concerns.

Bad performance. Let’s get this one out of the way first. Yes, encrypting and signing HTTP traffic does require some computing power. But modern implementations of modern algorithms on modern hardware are very capable of processing that at a fraction of the CPU cycles needed for business logic and database processing. „TLS has exactly one performance problem: it is not used widely enough.“ That’s that.

Setup complexity. Let’s Encrypt wants to make the HTTPS setup fully automated by enabling the web server software to do all the configuration steps by itself. It will just need to have its domain names configured and can then obtain and install the certificate without human intervention. The implementation status in the major servers for this feature is still lagging behind, though. Apache already backported mod_md to the 2.4 version but it is still experimental. From the documentation it looks like it comes very close to the ideal described above. The standard client certbot has plugins for Apache, nginx and others as well as generic modes and ways to integrate it are well documented.

Signing complexity. This is where Let’s Encrypt shines. No need to run openssl to create a signing request, find out where to upload it to the CA and do the validation dance with the CA. Once installed and configured, the Let’s Encrypt client, e.g. certbot, can do all this automatically via the standard ACME protocol. Certificate providers have tried to simplify this, too, using web interfaces and going as far as generating your server’s private key for you. Let’s Encrypt makes sure that private keys are private, because it runs locally on the server, and there is no need to manually enter data on a web page.

Renewal reminders. Whatever can be automated once, can easily be repeated. Certificate renewal becomes a cron job. Let’s Encrypt certificates are issued for 90 days in order to minimize trouble from certificate revocation lists that nobody ever checks. With the automated process, the short renewal cycle is a non-issue.

Certificate costs. This is where Let’s Encrypt shines even brighter. Its certificates are issued for free! Doing it for free is central to the mission of Let’s Encrypt so I’d expect they will try and keep it free. The money to run the service comes from the numerous sponsors and I am optimistic that they will keep it running for free for a long time.

Details, please!

The service offered by Let’s Encrypt is built around the ACME protocol which has now been published in its second version. It has its own IETF working group and is published as an Internet Draft. It has been vetted by different experts to make sure it complies with modern security standards. The Let’s Encrypt website has a long list of client implementations but the reference implementation is the EFF’s certbot.

The certbot client handles all certificate-related communication with Let’s Encrypt and is able to directly configure the web server via plugins. Certbot comes with official plugins for Apache and nginx but other third-party plugins are available. It also has plugins for manual and standalone operation if the web server plugins do not work for your setup.

As you might have guessed, Let’s Encrypt can only create domain-validated certificates. Validation entails that the Certification Authority gives you a unique identifier string, possibly some checksum or signature. This string has to be displayed at a location that the domain name you are requesting the certificate for is pointing to. This may either be a file on the web server itself or a TXT record on the name server for the domain. The Apache and nginx plugins use the former method, for the latter you need the respective DNS plugin.

Here is a complete transcript of certbot getting and installing a certificate on an Apache web server that is running on the same machine. The web server had already been set up to serve the site www.example.com via HTTP. The Apache plugin takes care of setting up the HTTPS virtual host and reloading the Apache configuration. When certbot is finished you can go directly to https://www.example.com and enjoy the encrypted web.

You can make certbot run non-interactively by passing more command line parameters.

For subsequent renewals, certbot has a renew command. It reads the information stored in /etc/letsencrypt and renews any certificates that are due to expire soon. Put this into your /etc/cron.daily.d/ and you never have to worry about forgetting to renew your certificate again. Here is an example run which does nothing, of course. We just got this certificate a couple of minutes ago.

This is how simple it is to secure your site using Let’s Encrypt. Admittedly, for a production site, you might not want certbot messing with your configuration or write stuff to your docroot. Or your web server might be running in a docker container which is another story all together. Using the fully automated plugins is a good place to start, though, to see how it is done. Certbot can be configured to do as much or as little as you like and with some scripting foo you should be able to easily whip up a procedure that fits your needs. I suggest that you make use of certbot’s --staging option that connects to the testing servers at Let’s Encrypt and allows you to create as many (non-functional) certificates as you like without being rate-limited.

The State of ACME

ACME stands for „Automated Certificate Management Environment“ and it is in no way tied to Let’s Encrypt. In fact, it was one of Let’s Encrypt’s design goals to create an open system that can be re-used by other CAs and it is their hope that is will be universally adopted as the standard for requesting and issuing certificates. Some of the changes in version 2 of the protocol were introduced to make it better suited for enterprise and commercial usage. There is an interesting interview with one of the founders from right around the time of the release of ACMEv2.

The most prominent new feature in ACMEv2 is the support for wildcard certificates. This had previously not been included because through the automated process, each web server can easily have its own certificate. Let’s Encrypt encourages users to use separate certificates and therefore separate private keys per server. However, there is a demand for wildcard certificates as some usage scenarios are easier to manage with wildcard certificates and I’ll mention one in the next section. For the benefit of these users, Let’s Encrypt has been supporting wildcard certificates since 13 March 2018.

Is HTTP going away?

HTTP support will not go away any time soon. Everybody involved is aware that the transition needs to be gradual and smooth. Apart from that, I see continued usage outside the browser and inside private networks. Modern microservice architectures make heavy use of RESTful APIs over HTTP, often on the same machine and even between containers. There would be no obvious benefit in trying to switch all these to HTTPS, too.

Won’t intranet servers need certificates? Yes, if you want to save your employees the hassle of installing your own root certificate, or worse, subconsciously train them to click certificate warnings away. This is where wildcard certificates come in. In combination with DNS validation, where the web server does not need to be reachable from the outside, Let’s Encrypt can be used for intranet servers, too. Just use an internal subdomain of a public domain. Instead of something like „example.local“, put all intranet servers under „local.example.com“ and get a certificate for „*.local.example.com“ from Let’s Encrypt via DNS validation.

That was easier than I thought!

See, moving your website to HTTPS wasn’t so hard at all. Now your users can rest assured that only you know about their love for cute cat pictures—thanks to Let’s Encrypt!