Let’s Encrypt Reaches One Billion Certificates Issued

Let’s Encrypt, the Internet Security Research Group‘s free certificate signing authority, issued its first 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 Certbot, 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 could 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.

The whole thing was (and is) frankly, a mess… and can easily result in downtime 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@web:~# apt update ; apt install -y python3-certbot-apache

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 RFC 8555.

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.

READ MORE HERE