During the summer of 2012, Eric Rescorla and I decided to start a Certificate Authority (CA). A CA acts as a third-party to issue digital certificates, which certify public keys for certificate holders. The free, automated, and open CA we envisioned, which came to be called Let’s Encrypt, has been built and is now one of the larger CAs in the world in terms of issuance volume.

Starting a new CA is a lot of work—it’s not a decision to be made lightly. In this article, I’ll explain why we decided to start Let’s Encrypt, and why we decided to build a new CA from scratch.

We had a good reason to start building Let’s Encrypt back in 2012. At that time, work on an HTTP/2 specification had started in the Internet Engineering Task Force (IETF), a standards body with a focus on network protocols. The question of whether or not to require encryption (via TLS) for HTTP/2 was hotly debated. My position, shared by my co-workers at Mozilla and many others, was that encryption should be required.

The need for encryption to become the rule rather than the exception on the Web was obvious to us then, even before the Snowden revelations broadened and accelerated discussions about the role and need for encryption. The increasing complexity of interactions on the Web, combined with its intimate role in our lives, has led to a situation in which users cannot reasonably exercise complete control over—or even be aware of—all of the sensitive data and metadata they are transmitting. This probably won’t change any time soon, and it’s probably a price worth paying for the benefits that the modern Web provides us. At the very least, though, we could encrypt people’s data while it’s in transit. At this point everything needs to be encrypted by default because trying to guess what needs to be encrypted and when is just too difficult and is a strategy that will let people down again and again.

There was one particularly good argument against requiring encryption for HTTP/2—getting and managing the certificates required for encryption via TLS was too difficult and costly. If we required TLS, we’d exclude many potential HTTP/2 adopters. Also, because certificates at the time almost universally cost non-trivial amounts of money, requiring TLS would effectively make HTTP/2 pay-to-play.

I felt like I had to be willing to contribute to addressing this criticism if I were going to maintain my position that HTTP/2 should require TLS. I wasn’t willing to give up on my belief that new Internet protocols should be secure by default, so thinking about the problem became a high priority.

The HTTP/2 specification did not end up requiring TLS, in large part because the certificate problem I just outlined had no reasonable road map for resolution. TLS did become a de facto standard for HTTP/2 because Google and Mozilla implementations require it, but the problem with certificates remained. The difficulty and cost associated with obtaining and managing them would work against HTTP/2 adoption and, perhaps even more importantly, prevent many people from securing their HTTP/1 sites.

Free, fast, and automated

Eric and I believed that the Web needed a free and entirely automated way for anyone to get a certificate, ideally in a matter of seconds. We wanted the system to be capable of automating all management on the client side, so that turning on TLS wouldn’t require knowing any details about how to request, pay for, properly install, configure, or renew certificates. Almost none of our ideas were entirely original, yet they weren’t being adopted into the mainstream CA ecosystem. At least not all in the same offering. The incentives just weren’t there.

We spent a lot of time thinking and talking about what could be done to make such a system a reality. By late summer 2012 we had concluded that the only way to accomplish our goals, relatively quickly and in a lasting fashion, was to start a new CA. Advocacy and evangelism, generating new standards, and begging existing CAs to do things differently wasn’t likely to result in major changes any time soon.

Building Let’s Encrypt wasn’t easy. The team had a lot to learn because we started out with precious little experience building or operating a CA. Some of us put in an exhausting number of hours for months or even years. Stress levels were frequently high given our timeline, the meticulous nature of the work, and the numerous points at which we could have failed. We succeeded in building the CA we set out to build primarily because the mission motivated the right people and partners to step up when needed.

With Let’s Encrypt, we have a powerful platform for helping to protect websites and people around the globe, particularly those who were previously unable to participate in a secure and privacy-respecting Web due to financial, technological, and educational barriers. Building a new CA was the right choice.