A look back at the history of ACME, the open, automated protocol behind Let's Encrypt



The Automated Certificate Management Environment (ACME) protocol was developed to improve Internet security and is intended for use with the Let's Encrypt service. Security engineer Christophe Brocas has written a blog post looking back at the history of the ACME protocol, outlining its origins, concepts, standardization, ecosystem, and evolutionary challenges.

ACME, a brief history of one of the protocols which has changed the Internet Security | Blog
https://blog.brocas.org/2025/12/01/ACME-a-brief-history-of-one-of-the-protocols-which-has-changed-the-Internet-Security/

The rise of the Internet
The internet spread globally in the 1990s, enabling users to communicate without barriers across a vast, interconnected world of computers. This coincided with the end of the Cold War, and people's activities became more free and open than ever before. While there were some backlashes, open and standardized protocols ultimately became the norm on the internet. The combination of HTTP and HTML, built on protocols such as IP, TCP, UDP, and DNS, has continued to drive the web as the internet's primary communications platform for the past 30 years.

However, with the growth of internet communication, authentication, integrity, and confidentiality have been neglected. Even as of 2015, only about 40% of websites were using HTTPS connections .



The Birth of Let's Encrypt

JC Jones , one of the designers of Let's Encrypt and former head of the Firefox encryption team, is now a Firefox SRE (SRE) when asked about the main barriers to widespread adoption of encryption. He responded, 'While the amount of information flowing on the web continues to grow, most of the data being transmitted lacks the integrity and confidentiality protection provided by TLS. The biggest barrier to using TLS everywhere was obtaining and managing server-side certificates. That's where Let's Encrypt was born.' As this statement suggests, the biggest obstacle preventing widespread adoption of HTTPS connections was the difficulty of obtaining certificates. A group of partners sharing a similar vision began the founding of Let's Encrypt in 2013. Since then, Let's Encrypt has been a certification authority issuing free TLS server certificates since 2015.



In the 10 years since Let's Encrypt was founded, some of the company's accomplishments include:

Over 700 million active certificates issued
Issues over 60% of all public TLS server certificates

And global HTTPS adoption has also increased, as Sarah Gran , VP of Advancement at Let's Encrypt, recalled, 'When we first started issuing certificates, HTTPS adoption was around 39%. Today, it's nearly 95% in the United States and over 83% globally. While we still have work to do, we're proud of the progress we've made over the past decade.'



◆Automated certificate issuance
Let's Encrypt uses the ACME protocol to automatically issue certificates. While automation, the core of Let's Encrypt, seems natural from a mid-2020s perspective, it was anything but common in the early 2010s. At first glance, automation appears to be a way to help website administrators ensure TLS protocol adoption on their sites. In fact, automation was an essential prerequisite for the survival of the Let's Encrypt project. In the words of

Aaron Gable , technical lead for Boulder , the company behind Let's Encrypt's core software, 'Automation was crucial to the success of Let's Encrypt. We knew from the beginning that manual verification would be impossible to scale on a nonprofit budget.' From the start, Let's Encrypt operated at internet scale despite being a small team of fewer than 15 people, and automation was the only realistic way to fulfill the heavy mission it was tasked with.

The open, automated protocol behind Let's Encrypt
When talking about automation in Let's Encrypt, we need to mention ACME (Automated Certificate Management Environment). The ACME protocol allows client software to prove to an ACME-compatible certificate authority that it controls the domain for which it is requesting a certificate. Sarah Gran states that 'the whole point of Let's Encrypt is to verify control of the domain, not ownership,' but the subtle difference between 'ownership' and 'proof of control' is important.

Proof of control includes the client responding to a challenge issued by an ACME-compatible certificate authority, which can be HTTP, DNS, or TLS.



HTTP: Placed in a standardized HTTP path
・DNS: Placed in the DNS zone
・TLS: Placed in the TLS response

To complete the challenge, the ACME client must properly populate each value provided by the ACME server.



The key to ACME is that the entire interaction between the client and the ACME server is performed without human intervention, allowing for automated certificate issuance, and deployment and integration into web services can also be automated using scripts that are triggered after issuance.



The Birth of ACME
ACME has been at the core of Let's Encrypt since its inception, and has been improved to cover as many use cases as possible. According to

a paper on Let's Encrypt presented at ACM CCS 2019 , the roots of ACME and Let's Encrypt date back to two teams: one developing a protocol for automatically issuing and renewing certificates, and the other creating a free, automated certificate authority. The two teams discovered each other's research and collaborated, leading to the ACME protocol and its implementation in Let's Encrypt.



◆Standardization and Open Source
ACME has been openly documented from the beginning, and the first open-source ACME client, Certbot , served as the client-side reference implementation. The standardization process through the IETF led to the establishment of RFC 8555 in March 2019. As a result of having an open and standardized protocol, numerous ACME clients have been created covering a very wide range of use cases. JC Jones recalled that this was the goal from the beginning, saying, 'This is what we foresaw, or at least hoped for.'

Regarding how the standardization process within the IETF has led to improvements in the ACME protocol, Jacob Hoffman-Andrews , one of the people involved in creating RFC 8555, points out that two important improvements were made through the standardization process: 'changing from a verification-first flow to a certificate request-first flow' and 'changing all requests, including GET requests, to require authentication.' Jacob also praised the improvements in security that were made possible by suggestions from community members.

When Let's Encrypt entered the public Certificate Authority ecosystem in 2015, many questions arose: 'How cooperative or adversarial would it be?', 'How would it affect the viability of existing Certificate Authorities?', etc. However, the fact that Let's Encrypt was based on an open protocol and was immediately subject to an IETF standardization initiative led to cooperation and adoption by innovative Certificate Authorities.

Additionally, because the IETF's standardization process is based on an open process, it has created a forum for discussion necessary for cooperation between organizations that do not necessarily share the same goals. As a result, after the standardization process was completed in 2019, ACME became the primary means for all public certification authorities to transition to the 'automated issuance of short-lived certificates.' In fact, SC081 voted at the CA/B Forum in April 2025 determined that certificate expiration dates would be gradually shortened from March 2026 to 47 days by March 2029. The automation provided by ACME will be important in adapting to the significant shortening of certificate lifetimes.

ACME was developed by the team behind Let's Encrypt, and is now one of the leading automated certificate acquisition protocols adopted by all public CAs. Outside the public CA ecosystem, the protocol is becoming increasingly popular among technical architects at companies with private CAs.

◆Future evolution of ACME
ACME's evolution continues. In 2025, the ACME Renewal Information ( ARI ) extension was published. ARI allows certificate authorities to propose renewal periods to their customers, often earlier than the customer would have chosen. This is particularly important when it's necessary to mass-revoke certificates that don't comply with the rules they were issued with. The team and some community members are heavily invested in community outreach. In the case of ARI, support is provided to ACME client developers who implement ARI, with the goal of raising awareness among potential users. However, the ideal way to efficiently set up ARI is to ask the certificate authority daily whether a certificate needs to be reissued. However, many ACME clients rely on a cron task, which requires user configuration.

Another evolution is the introduction of Multi-Perspective Issuance Corroboration (MPIC) . In recent years, the CA/B Forum has requested that public certificate authorities implement MPIC to prevent BGP attacks. However, Let's Encrypt had already implemented a similar feature and launched it in service in 2020, so there was little need to make changes to its infrastructure. Let's Encrypt has always been at the forefront of innovation and has been on the side of shaping the future of the ecosystem, so it was able to minimize the impact of these additional requirements on its infrastructure.

What kind of evolution can we expect from ACME in the future? Aaron Gable talks about two developments in response to this question.

Standardization of ACME profile selection
Introducing the 'pubkey' identifier type and a challenge that allows clients to demonstrate control of the corresponding key pair.

◆Conclusion
ACME and Let's Encrypt's implementation has increased the adoption of HTTPS, helping to improve security for billions of internet users and private networks. For a small nonprofit, this would be impossible without the automation provided by ACME.

in Web Service, Posted by log1c_sh