Do you remember the days of frantic certificate renewals, the dread of impending expirations, and the inevitable "connection not secure" warnings? For many, the manual process of managing TLS certificates has been a constant source of stress, consuming valuable time and introducing significant risks to availability. This challenge has reached a crisis point with the CA/Browser Forum's April 2025 decision to slash maximum public TLS certificate validity from 398 days to just 47 days, making manual renewal utterly impractical and unscalable.
In this HAProxyConf presentation, engineers Marko and William tackle this critical challenge head-on, providing a comprehensive deep-dive into the Automatic Certificate Management Environment (ACME) protocol and HAProxy's approach to certificate automation. They trace the evolution from panic-driven manual processes through the current landscape of third-party ACME clients like CertBot, lego, and acme.sh, before unveiling the game-changing native ACME implementation arriving in HAProxy 3.2.
This isn't just about convenience—it's about eliminating the business-critical availability risks that come with expired certificates. The speakers provide a detailed technical walkthrough of HAProxy's new native ACME capabilities, including HTTP-01 challenge support, seamless integration with the Data Plane API 3.2, and the innovative ring buffer system that enables certificate updates without disk access during runtime. They also preview the exciting future roadmap, including DNS-01 challenge support and full integration with HAProxy Fusion for enterprise-scale certificate lifecycle management across clusters.
Slide Deck
Here you can view the slides used in this presentation if you’d like a quick overview of what was shown during the talk.
Marko
I'm Marko, and this is William. We work as engineers in HAProxy Technologies, mostly in Golang, and primarily with HAProxy Fusion and HAProxy Data Plane API.
In this presentation, we discuss the Automatic Certificate Management Environment (ACME) protocol and how we’ve integrated it with HAProxy. To set the stage, let's first talk about ACME and why it’s important today.
What problem is ACME actually solving?
I'm sure some of you here have dealt with certificate renewals in the past, and you had to set reminders, spreadsheets, and a bunch of notes. The core problem with that is that it was a completely manual process, and that manual process is complex, error-prone, and chews up a lot of valuable time.
Another serious impact of the manual process is that panic became a common symptom. You often had urgent last-minute scrambles fueled by the dread of expired certificates. The ultimate business impact was the constant risk to availability. A simple mistake in your manual process or a delay could lead to a “connection not secure” warning, which would actually erode your user's trust.
The solution to these problems is the Automatic Certificate Management Environment (ACME) protocol.
Let's Encrypt was launched in 2016 as a free automated certificate authority by the ISRG. Let’s Encrypt introduced ACME, a protocol standardized in RFC 8555 in 2019. The ACME protocol automates the entire certificate lifecycle, from issuing certificates to validation to renewals and revoking them if they are compromised.
The main driver for ACME and automation is the undeniable trend of rapidly shrinking certificate lifespans.
When Let's Encrypt launched in 2016, it basically established the 90-day lifespan as the de facto standard for frequent certificate renewals.
Since then, the situation has actually gotten worse as lifespans have continued to become shorter. In the CA/Browser Forum ballot that happened in April 2025, the decision was made to change the maximum public TLS certificate validity from 398 days to only 47 days. The goal of this is to have better security through faster rotation of certificates.
When we take all of this into account, manually renewing certificates every 47 days or even every 90 days becomes impractical and non-scalable. Certificate automation has become unavoidable, and ACME provides the environment or protocol for this automation.
Let’s see how HAProxy and ACME are currently being leveraged to automate certificates.
In the current state of affairs, most of you are using standalone third-party clients and some external scripting.
Here are some popular options.
CertBot, which is Python based. It's an official ACME implementation.
lego, which is quite minimal. It has excellent support for solving DNS challenges as it supports a vast number of DNS providers.
acme.sh, which is shell-based.
The typical workflow with all of these clients is that you run those clients via cron or some other scheduler or manually to fetch your certificates. Then you have some external scripting for answering HTTP challenges or for preparing the certs, inserting them into HAProxy, loading them via the runtime, or just reloading HAProxy.
It's a functional system, but as we'll see, it has its drawbacks, and that's what we are working currently to address in HAProxy 3.2.
Here's a short example of how you can run ACME and HAProxy using lego.
Here you use lego to solve a DNS challenge, in this case Route 53. Then fetch the certificates you need. Use these two commands to insert the certificates into the stats socket of HAProxy.
lego supports around 153 DNS providers so probably most of your DNS providers are supported with this.
William
In addition to these solutions, we needed something light and portable for appliances, something small with no dependencies. acme.sh fits these needs.
Key points about acme.sh:
acme.sh is lightweight.
It has minimal dependencies. It’s basically a big POSIX script using the OpenSSL binary.
It's a full ACME implementation, meaning you can do the HTTP challenge, the ALPN challenge, and the DNS challenge, and it supports HAProxy natively.
Originally, it was limited because you still had to reload HAProxy, but we contributed a dynamic update capability that uses the HAProxy Runtime API to pass cert updates to HAProxy.
Here’s a small example with acme.sh.
You need two important elements: the stats socket, so ACME can use it, and the http-request rule, which answers the HTTP challenge.
You use it by issuing two commands.
There is an issue command, which asks for the challenge and which generates the certificate.
Then you have the deploy command, which calls the deploy script, puts the certificate in the right place, and pushes the certificate within HAProxy.
Then you put acme.sh in a crontab or something else so that it runs every few weeks.
Key points about the acme.sh solution:
You don’t need to reload HAProxy.
It doesn’t have to be run as root, meaning you can just use an HAProxy user with an access to the stats sockets.
It's simple to use.
It's not well integrated in distributions, meaning you don't find packages easily. There is a Docker image, but it's not for everyone. So it's not easy to maintain.
There isn't a stable branch. It's not a long-term support product.
There are limitations in the ways you can configure it. You will need to use a directory and only a directory. You couldn't use, for example, a CRT keyword or ssl-f-use keyword, a CRT list, or anything else.
With HAProxy 3.2, we’ve added a lot of enhancements to our ACME support.
It's an experimental feature for now, but we will backport everything in a future 3.2 release if there are improvements.
Any CRT keyword can be configured. You can use a CRT list, a CRT store, ssl-f-use, and so on.
You don't need to reload.
You don't need an external configuration.
HTTP-01 challenge is supported now. ALPN-01 and DNS-01 in a future release.
Example configuration:
It’s very similar to the acme.sh configuration. Just the acme section has been added, and the http-request rule is the same. Just use the acme keyword with the domains you want on the same line as your certificate.
We also added some commands to the HAProxy Runtime API CLI so you can check the status of the certificate, the expiration date, and the scheduled date, and you can force the renewal of the certificate.
With the native implementation, you can define the ACME solution completely within the HAProxy configuration. The ACME cert updates are limited to memory, however, because HAProxy does not access the disk during runtime. This limitation is addressed in HAProxy Data Plane API 3.2.
Marko
HAProxy Data Plane API 3.2 introduces a variety of important enhancements.
HAProxy Data Plane API 3.2 adds support for ACME keywords as well as the ssl-f-use CRT stores accessible via the REST API. Also, commands for fetching statuses of ACME certificates and forcing renewals are available in the HAProxy Data Plane API.
Release 3.2 also adds support for a ring buffer that allows cert updates to be handed off from HAProxy to the HAProxy Data Plane API so that the updates can be saved to disk. This capability comes from introducing the HAProxy Data Plane API ring buffer, dpapi, which implements inter-process communication between HAProxy and the HAProxy Data Plane API. The ring buffer starts when you start HAProxy. You can connect to the ring buffer on the master socket or the stats socket and listen for events.
HAProxy accesses the disk only when starting or reloading, so when you change a cert with ACME and the HAProxy Runtime API, the new cert is not written to disk. With the new dpapi ring buffer, however, HAProxy can pass the cert to the HAProxy Data Plane API, which can then store the cert on disk.
The HAProxy Data Plane API listens to the ring buffer for messages about ACME changes. When it gets a notification that HAProxy got a new certificate from the ACME provider, it uses the HAProxy Runtime API commands show ssl cert and dump ssl cert to pick up the certificate then store it on disk. This is the current workflow for the HTTP-01 challenge.
Support for the DNS-01 challenge will be added in a future 3.2 release. We’ll use Go's extensive DNS client libraries to solve DNS challenges in the HAProxy Data Plane API.
Here’s how to implement the ACME provider's full HTTP-01 challenge method using HAProxy and the HAProxy Data Plane API.
Challenge method for HTTP-01:
HAProxy issues a certificate request to the provider.
Provider issues a challenge, which HAProxy solves.
HAProxy issues a CSR and downloads the certificate into memory.
HAProxy sends a notification to the ring buffer that the cert is downloaded.
HAProxy Data Plane API receives notification via the ring buffer and stores the cert on disk.
Once we add support for DNS, the process will be the same except for one difference: the HAProxy Data Plane API will solve the challenge instead of HAProxy. The HAProxy Data Plane API then sends the result to HAProxy, and the process continues as shown for HTTP above.
This process works for single instances of HAProxy. If you have a cluster managed by HAProxy Fusion, you need a different solution.
We’re currently working to integrate the ACME solution with the HAProxy Fusion API so you can configure ACME cert management at scale.
HAProxy Fusion Control Plane is already a full-scale enterprise certificate lifecycle manager. It provides an endpoint where you can upload certificates, renew them, and revoke them, and they are instantly sent to all the HAProxy Enterprise nodes in the cluster. HAProxy reloads are no longer necessary because everything happens dynamically.
When the ACME integration is complete, HAProxy Fusion will handle all communication with the ACME providers, handle the challenges, fetch the certificates, and distribute them across your clusters.
So stay tuned for more updates as we develop those capabilities.
