The Automated Certificate Management Environment (ACME) protocol helps automate management of public key infrastructure, specifically around validated domain ownership and trust. The Internet Security Research Group (ISRG) developed ACME in 2016 as part of RFC 8555. ACME v2 is the current version and sole standard introduced in 2018.
The protocol's key goal is to limit manual certificate issuance and management, and make life easier for teams that manage hundreds or even thousands of individual certificates across their web properties. This happens by setting up an HTTPS server (or adding DNS records depending on the challenge type selected) to serve and automate related requests from the ACME agent. This agent can run natively or via third-party authority.
The ACME protocol simplifies full-lifecycle management and backend communications between certificate authorities (CAs) and servers, devices, and more. Teams generally praise it for being easy to configure, relatively simple to use, and having no licensing fees — thus driving widespread adoption.
How does the ACME protocol work?
Ongoing communication between both an ACME client and ACME server enables efficient certificate management, whether you're issuing or revoking out-of-date certificates. The ACME client runs on devices that require some level of PKI certificate protection. Meanwhile, the ACME server is typically hosted at a certificate authority such as Let's Encrypt and GlobalSign. Here's how the process works:
The client connects to the ACME server automatically and awaits authorization.
Once the ACME client is authorized with the certificate authority for the first time, the ACME agent will generate a private-public key pairing and confirm with the CA that it owns or controls the domains in question.
The CA will send one or more challenges to the ACME agent — typically asking the agent to share a given DNS record for the associated domain (example.com) or locate a known HTTP resource at a specific URI. After running multiple network checks to verify challenge completion, the client and server can communicate.
After this connection is successfully made, the ACME client can send requests to the certificate authority. This may include certificate issuance and revocation, made possible by signing each request with the recent key pairing.
The newer TLS-ALPN-01 challenge alternatively compares SNI fields against validated domains, and is another potential step in the negotiation process. While secure and works with IP addresses to verify ACME agents, it's a little more niche.
You can also use the ACME protocol to grab organization-validated (OV) and extended-validation (EV) certificates from the server, but this requires additional components alongside the ACME agent.
Does HAProxy support the ACME protocol?
Yes! HAProxy and HAProxy Enterprise support smarter certificate management and automation through Let's Encrypt and the ACME protocol. While older software versions relied on an acme.sh integration, HAProxy 3.2 (and later HAProxy Enterprise) introduced experimental ACME protocol support to help automate the loading of TLS files from certificate authorities. This is just part of our overall PKI support in HAProxy.
To learn more about ACME support in HAProxy, check out our HAProxy 3.2 announcement or our HAProxy and Let's Encrypt blog post.