Let’s Encrypt case study: how automation helped make HTTPS the default

For many years, enabling HTTPS on a website meant buying a certificate, manually proving control of the domain, installing files on a server, and repeating the process before expiration. Each step was manageable on its own, but together they created a disproportionate barrier for blogs, community projects, and small businesses. The Let’s Encrypt case shows how changing the architecture of a process can matter more than merely lowering the price of a technology.

The nonprofit certificate authority put its first publicly trusted certificate into operation on September 14, 2015. Instead of selling certificates as a product, it combined three decisions: free issuance, automated validation, and integration through an open protocol. The effect was not to invent encryption, but to turn an exceptional administrative task into a routine infrastructure function.

The problem was operational as well as financial

A TLS certificate allows a browser to authenticate the domain it reached and establish an encrypted channel. That reduces the risk of third parties reading or changing traffic in transit. Before broad automation, however, operators had to navigate different certificate-authority procedures, interactive instructions, installation work, and renewal reminders. RFC 8555, which standardized the Automatic Certificate Management Environment protocol, records that the workflow could take one to three hours in informal usability tests cited by its authors.

Let’s Encrypt addressed price and operations at the same time. An ACME client proves control of a domain through a verifiable challenge, such as publishing an HTTP resource at a specific address or creating a DNS record. After validation, the client requests the certificate, installs the required material, and can repeat the process for renewal. The private key remains under the server operator’s control.

Automation changes the economics of the service. Issuing one more certificate no longer requires an equivalent sequence of human labor. Hosting companies can enable HTTPS by default for thousands or millions of customers; servers such as Caddy and proxies such as Traefik implement ACME directly. In 2024, the EFF noted that this integration reduces problems that arise when an external tool such as Certbot must interpret and modify another server’s configuration.

Scale became a consequence of integration

Milestones published by Let’s Encrypt illustrate the shift. The organization issued its millionth certificate in March 2016, reached one million issuances per day in September 2018, and passed one billion total issuances in 2020. At the end of September 2025, it exceeded ten million certificates in a single day for the first time. Certificates expire and are replaced, so cumulative issuance, active certificates, and protected sites are not equivalent measures.

The more meaningful figure sits outside the certificate count. According to Firefox statistics reproduced by Let’s Encrypt, the global share of encrypted web connections rose from below 30% to roughly 80% over about five years and remained near that level; in the United States it approached 95%. Those figures support a substantial contribution, but they do not establish sole causation. Browsers began labeling HTTP as insecure and limiting features to secure contexts, while hosting companies, content-delivery networks, and server projects simplified HTTPS deployment.

What the case teaches

The first lesson is that free certificates without automation would have had limited reach. Removing the price mattered, but eliminating repetitive decisions allowed HTTPS to become a platform policy. The second is that an open standard can extend the effect of one organization: ACME became an IETF standard in 2019 and can be implemented by different authorities, clients, servers, and providers.

The third lesson is operational. Short-lived certificates stop being calendar problems when renewal is continuously tested. Let’s Encrypt documentation lists a 90-day default and a six-day option, with renewal recommended before expiration. This reduces the exposure window of old credentials, but it also turns failed automation, rate limits, and dependence on the certificate authority into risks that require monitoring.

There is also an important conceptual limit. Let’s Encrypt issues domain-validation certificates. They demonstrate that the requester technically controls the domain at that moment; they do not certify a company’s legal identity, the accuracy of an article, or the honesty of a store. A fraudulent site can also use HTTPS. The lock protects the connection; it does not endorse the content.

The project’s most durable legacy, then, is not only the volume of certificates. It is the demonstration that security infrastructure can reach scale when cost, standardization, and operational experience are treated as the same problem. HTTPS became less visible precisely because it became a basic part of the web.