There’s a new certificate authority in town, and it seeks to change the way we think about web security. Let’s Encrypt, run by the Internet Security Research Group (ISRG), a partnership of a number of Internet-focused organizations like the EFF, Mozilla, Cisco, Akamai, and now Facebook, entered it’s public beta period this week and is now issuing free, browser-trusted, domain-validated certificates to pretty much anyone who wants them.
I’ve been doing some experimenting with Let’s Encrypt for the past few weeks as part of their limited beta program, and this post was already in the works. In fact, I hadn’t even noticed that they entered public beta until after I started writing it and I went to the site to check on some facts.
While there are many issues with the SSL/TLS current certificate issuing paradigm, Let’s Encrypt aims to solve one of the biggest: the barrier of entry. Not only are Let’s Encrypt certificates free, the process for getting them is mostly automatic. To contrast, I’ve used another CA to obtain free certs for a number of my personal sites and projects for years and the process to get them is not easy. With that CA, getting a new certificate is a multi-step process which includes creating a client certificate to authenticate with the service, installing it in my browser, multiple steps of verifying domains, email addresses, and the like, waiting for verification codes to come by email, and manually installing the certificates when they arrive. That CA also doesn’t support Subject Alternative Names (SANs), so I’m limited to creating certificates that work with only one domain or subdomain.
With Let’s Encrypt, after a little bit of one-time server setup, I just run a single shell command and it does everything for me (or most of it, anyway).
Before going too much further, let’s point out that Let’s Encrypt is not for everyone. The certificates they issue are domain validated (DV), which means that the only validation done is a check that the server responding to the domain name in the certificate request is actually aware of the request. As such, there is no information about the organization running the site in the certificate, so while a Let’s Encrypt certificate will enable encrypted connections in browsers (and without any certificate warnings), it does nothing to validate that the server is actually being run by the entity that it purports to be. Because of this, Let’s Encrypt certificates probably shouldn’t be used for most production-level sites, especially not for ecommerce, banking, or anything else where a high level of trust is required. On the other hand, they could be perfect for dev and test servers, where the level of trust is not required.
Let’s Encrypt intends their certificates to be used on the millions of personal sites, running software like WordPress, where site owners log in in the clear. These kinds of sites are often the targets of hackers because (among many other reasons) people tend to reuse passwords, so the clear-text passwords they use to log in to their blog may very well be the same ones they use to log in to their banks.
So how does automatic certificate generation work? In a nutshell, you install the Let’s Encrypt software on your server and use it to request a certificate for one or more domains. The client uses the Automated Certificate Management Environment (ACME) protocol, which was developed by Let’s Encrypt, to submit the certificate request (which it generates for you), to the Let’s Encrypt CA. The CA then verifies the request by checking that a specific file, created by the client software, is available from your server via the web. If the server finds the file, the domain is verified, and the certificate is issued. If the request is made for a domain that isn’t hosted by the server, the verification will fail, and the certificate won’t be issued. When the certificate is issued, it’s returned to the client which will save it to the server and, depending on the implementation, may also reconfigure the web server to use the certificate for the domains it covers.
Let’s Encrypt supports SANs on it’s certificates, so it’s possible, for instance, to cover the .com, .net, and .org variants of a given domain, with both and without www prefixes, in a single cert (this isn’t even possible with the most commercial CAs, unless you are willing to pay for it—SANs are usually a premium feature and it usually costs almost as much to add an additional domain as it does to get a whole new cert). Let’s Encrypt also says that wildcard certs are in the works, though there are some issues they need to work through concerning how to validate them, since a wildcard certificate would be valid for any subdomain on the domain it was issued to. Fortunately, since there’s no limit to the number of SANs you can add or the number of certificates you can request (within reasonable limits, for now, at least), wildcard certificates would only be necessary in some very specific use cases.
The biggest downside to Let’s Encrypt is also one of it’s biggest strengths: certificates are only valid for 90 days. This is a stark contrast to the current industry standard that allows certificates to be issued for up to two years and terms of five years or more being common not that long ago. The 90-day limit means that site owners need to stay vigilant of expiration dates, but in a world of script-kiddie exploits and expired domains getting scooped up by domain squatters faster than you can say “connect,” it’s a pretty smart idea to recycle certificates quickly. Plus, renewing is as easy as running the ACME client again, and an auto-renewal process is promised somewhere down the road. For now, most monitoring tools can warn about certificate expiration in advance of it happening. Let’s Encrypt recommends renewing every 60 days to ensure there’s plenty of time to fix any issues that may come in in the renewal process.
If a public key ever gets compromised, revoking a certificate is easy, too…it’s just another command to the Let’s Encrypt client. Remember that other CA I mentioned? They actually charge a fee to revoke a cert and won’t issue a new one until either the old one expires or you revoke it, even if you just lost the private key because of stupidly copying another file on top of it…not that I’ve ever done that!
I figure I’ll probably start replacing my free certs with Let’s Encrypt certs as they expire. Using them will be a bit more work in that I’ll have to remember to renew them every couple months, but I’m working on a script that handles the installation process with Vesta, where most of my sites reside, so the process will be much, much easier than it is now. I plan to release this script once I’ve done some thorough testing, so watch for another post in the next week or so.