HTTPS for all: Let’s Encrypt reaches one billion certificates issued

/ Encrypted communication has gone from "only if it‘s important" to "unless you‘re incredibly lazy" in four short years—and Let‘s Encrypt deserves a lot of the credit for that.

Share this story

Let‘s Encrypt, the ‘s free certificate signing authority, issued its certificate a little over four years ago. Today, it issued its billionth.

The ISRG‘s goal for Let‘s Encrypt is to bring the Web up to a 100% encryption rate. When Let‘s Encrypt launched in 2015, the idea was pretty outré—at that time, a bit more than a third of all Web traffic was encrypted, with the rest being plain text HTTP. There were significant barriers to HTTPS adoption—for one thing, it cost money. But more importantly, it cost a significant amount of time and human effort, both of which are in limited supply.

Let‘s Encrypt solved the money barrier by offering its services free of charge. More importantly, by establishing a stable protocol to access them, it enabled the Electronic Frontier Foundation to build and provide , an open source, free-to-use tool that automates the process of obtaining certificates, installing them, configuring webservers to use them, and automatically renewing them.

Managing HTTPS the traditional way

When Let‘s Encrypt launched in 2015, domain-validated certificates  be had for as little as $9/year—but the time and effort required to maintain them was a different story. A certificate needed to be purchased, information needed to be filled out in several forms, then one might wait for hours before even cheap domain-validated certificates would be issued.

Once the certificate was issued, it (and its key, and any chain certificates necessary) needed to be downloaded, then moved to the server, then placed in the right directory, and finally the Web server could be reconfigured for SSL.

On the widely used Apache Web server, the SSL portion of the configuration—alone!—might look something like this:

SSLEngine on SSLCertificateFile /etc/apache2/certs/sitename.crt SSLCertificateChainFile /etc/apache2/certs/sitename.ca-bundle SSLCertificateKeyFile /etc/apache2/certs/sitename.key SSLCACertificatePath /etc/ssl/certs/ # intermediate configuration, tweak to your needs SSLProtocol all -SSLv3 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLHonorCipherOrder on SSLCompression off # OCSP Stapling, only in httpd 2.3.3 and later #SSLUseStapling on #SSLStaplingResponderTimeout 5 #SSLStaplingReturnResponderErrors off # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security “max-age=15768000”

None of this configuration was done for you. In the real world, a dismaying amount of cargo-cult configuration got done via cut and paste from the first site that claimed to offer a working set of configs.

If an inexperienced admin guessed wrong when looking for something to copy and paste—or a more experienced admin got sloppy and didn‘t notice when standards changed—insecurity in the form of bad protocol and cipher arguments could easily creep in as well.

Every one to three years, you‘d need to do the whole thing over again—perhaps only replacing the certificate and key, perhaps also replacing or adding new intermediate chain certificates.

Further Reading

The whole thing was (and is) frankly, a mess… and can easily result in if an infrequently practiced procedure doesn‘t run smoothly.

Managing HTTPS with Let‘s Encrypt and Certbot

In both removing cost and establishing a stable, reliable protocol, Let‘s Encrypt also removed significant barriers to automation. The EFF stepped in to provide that automation to end users and admins with Certbot, one of the most popular ways to manage acquiring, installing, and renewing Let‘s Encrypt certificates.

On an Ubuntu 18.04 or newer system, EFF‘s Certbot and its various plugins are available in the main system repositories. It can be installed with two shell commands—one, if you‘re willing to fudge a little and use a semicolon:

root:~# apt update ; apt install -y python3-certbot-apache

  • If you‘re using the Apache webserver, run certbot –apache. Nginx? certbot –nginx. That‘s it. Jim Salter
  • All configured websites will display in a menu, and you can select any or all of them for update to use with Let‘s Encrypt. Jim Salter
  • I used to hand-write configs to redirect HTTP to HTTPS on my webservers. It wasn‘t hard, but it was tedious, and it didn‘t always happen. Certbot will do it for you. Jim Salter
  • That‘s it. You‘re done, and your sites are now configured properly for HTTPS. Jim Salter

With that done, a single command activates Certbot. As you interact with a simple plain-text menuing system, it fetches certificates for any or all of your sites, configures your Web server (properly!) for you, and adds a cron job to automatically renew the certificates when they‘re down to 30 days prior to expiration. The whole thing takes well under five minutes.

As an added touch, Certbot even offers—but doesn‘t demand—to automatically configure your Web server to redirect HTTP requests to HTTPS for you. It‘s just that easy.

Providing privacy and security at scale

In June of 2017, Let‘s Encrypt was two years old and served its ten millionth certificate. The Web had gone from under 40% HTTPS to—in the United States—64% HTTPS, and Let‘s Encrypt was servicing 46 million websites.

Today, Let‘s Encrypt‘s billionth certificate has been issued, it services 192 million websites, and the United States‘ portion of the Internet is a whopping 91-percent encrypted. The project manages this on nearly the same staff and budget it did in 2017—it has gone from 11 full-time staff and a $2.61 million budget then to 13 full-time staff and a $3.35 million budget today.

None of this would be possible without a commitment to automation and open standards. We gushed about how easy the EFF‘s Certbot makes it to deploy and renew Let‘s Encrypt certificates—but that contribution is only possible because of Let‘s Encrypt‘s own focus on standardizing an open ACME protocol that anyone can build a client to operate.

In addition to building and publishing a stable, capable protocol, Let‘s Encrypt put in the work to submit and ratify it with the Internet Engineering Task Force (IETF), resulting in .

Conclusions

There really isn‘t much excuse not to provide secure, end-to-end encrypted (and authenticated!) communication from websites to users anymore. Let‘s Encrypt, its ACME protocol, and the legion of clients that have sprung up to facilitate its use—including but not limited to Certbot—have made HTTPS configuration and deployment simple.

Leave a Comment

Your email address will not be published. Required fields are marked *

*