Let’s Encrypt case study: how ACME automated HTTPS

When Let’s Encrypt entered public beta on December 3, 2015, the project said it had issued more than 26,000 certificates during the limited phase. Its stated goal was to make HTTPS the default for the web. The most visible change was a price of zero, but the defining part of the model was elsewhere: removing people from the repetitive cycle of proving control of a domain, requesting a certificate, installing it and renewing it.

Let’s Encrypt is a certificate authority operated by the nonprofit Internet Security Research Group. Its role is to issue browser-trusted TLS certificates. It is not software installed on a website, and it is not another name for Certbot. That distinction helps explain how the project became infrastructure: the authority, protocol and client programs are separate pieces.

The problem was not only the certificate price

Before automation, obtaining a domain-validation certificate often meant generating a request, copying data into a certificate authority's control panel, completing a file, DNS or email check, downloading the issued files and configuring the server. RFC 8555 describes the earlier process as a collection of ad hoc mechanisms driven by human instructions and prone to frustration.

Removing the fee opened the door for small projects, blogs and services without a dedicated certificate budget. Free issuance without reliable renewal, however, would merely replace a financial barrier with a recurring operational task. Let’s Encrypt's design addressed both parts together: free certificates and automated management.

ACME turned a manual routine into a protocol

The Automatic Certificate Management Environment, or ACME, defines how a client communicates with a certificate authority. The client first creates a cryptographic account and requests authorization for a domain. The authority presents challenges, such as placing a resource at a known HTTP address or publishing a specific DNS record. By checking the response, the authority determines that the client controls the domain.

The client can then submit a certificate signing request, receive the certificate and repeat the process for renewal. Let’s Encrypt also submits certificates to public Certificate Transparency logs. In March 2019, the IETF published ACME as RFC 8555. That mattered because it separated the method from one organization: other authorities and clients can implement the same standard.

Certbot, maintained in the Electronic Frontier Foundation ecosystem, is one such client. It can integrate certificate issuance and renewal with servers including Apache and Nginx. Hosting platforms can also embed their own clients, letting a user enable HTTPS without running Certbot directly. In practice, the automation can disappear behind a control panel or infrastructure configuration.

Scale, limits and the lesson from the case

In its 2025 annual report, ISRG says Let’s Encrypt had issued more than seven billion certificates and served hundreds of millions of websites, with more than eight million certificates issued on some days. The organization also compares 39% of page loads being encrypted when the project began with more than 95% in many regions a decade later, while explicitly acknowledging that it cannot claim all the credit. Browsers, hosting providers, CDNs and other certificate authorities also contributed to the transition.

There is an essential limit. Standard Let’s Encrypt certificates use domain validation: they demonstrate technical control over a name, not the real-world identity or honesty of its operator. HTTPS makes traffic interception and modification between user and server harder, but a fraudulent site can also provide an encrypted connection.

The case shows that open infrastructure gains reach when it removes manual decisions without hiding its trust boundaries. Let’s Encrypt removed the price, while ACME removed much of the repetitive work. Together they made automatic renewal a common practice—and created a new responsibility: operators still need monitoring, because incorrect DNS, blocked ports or outdated clients can prevent issuance. The achievement was not making certificates invisible, but turning them into a verifiable routine that machines can perform.