Certificate Renewal Automation: A Practical ACME Guide
With publicly trusted TLS certificates limited to 100 days from 2027 and 47 days from 2029, manual renewal stops being a yearly task and becomes a weekly one. This guide covers how to automate it: finding every certificate, how ACME and its challenge types work, what to do with systems that cannot run an ACME client, and how to know automation is actually working.
Last reviewed:
Start with an inventory
You cannot automate a certificate you do not know about. Before choosing tools, list every public certificate for your domains: which names it covers, which CA issued it, when it expires, where it is installed and who is responsible for it.
Certificate Transparency logs are the best starting point, because every publicly trusted certificate is recorded in them. A search for your domain returns certificates you have forgotten, ones ordered by other teams, and ones installed on hosts nobody remembers. The Certificate Transparency guide explains how to search the logs and what they cannot show you. Then confirm what each host actually serves: the log tells you a certificate exists, not where it is deployed.
Group the result by how each certificate is installed. That grouping, not the number of certificates, decides how much work automation will be.
How ACME works
ACME (Automatic Certificate Management Environment, RFC 8555) is the standard protocol for requesting, validating and renewing certificates without a person in the loop. Publicly trusted CAs that offer ACME include Let's Encrypt, ZeroSSL, Google Trust Services and Buypass. A client talks to the CA's ACME server over HTTPS and every request is signed with the client's account key. A typical issuance goes like this:
- Account. The client registers an account key with the CA once. Some CAs require External Account Binding (EAB), a key you get from the CA's dashboard that links the ACME account to your existing customer account.
- Order. The client asks for a certificate for a list of names.
- Authorization. For each name the CA returns one or more challenges. The client completes one per name to prove control.
- Finalize. The client sends a certificate signing request (CSR) for a key it generated locally. The private key never leaves your system.
- Download and deploy. The client fetches the certificate and chain, installs them and reloads the service.
Renewal is simply a new order. Because the CA may reuse a recent validation for a limited time, and that time is shrinking under the CA/Browser Forum schedule, a renewal should be expected to complete a challenge every time.
Choosing a challenge type
The challenge is how you prove control of a name. There are three in common use, and the right one depends on what the CA can reach and what your client can change.
| Challenge | What you prove | Needs | Wildcards |
|---|---|---|---|
| HTTP-01 | You can serve a file at a URL on the name | The name reachable from the internet on port 80 | No |
| DNS-01 | You can publish a TXT record for the name | API or scripted access to the DNS zone | Yes |
| TLS-ALPN-01 | You control the TLS endpoint for the name | Port 443 reachable, and a TLS server that supports the challenge | No |
HTTP-01
The client places a token at /.well-known/acme-challenge/ on the name and the CA fetches it over plain HTTP on port 80. It is the easiest choice for a single public web server and needs no DNS access. It breaks when port 80 is closed, when the name resolves to several servers that do not all serve the token, or when the host is not reachable from the internet at all.
DNS-01
The client publishes a TXT record at _acme-challenge. followed by the name. It works for hosts that are not publicly reachable, for names spread over many servers, and it is the only challenge that can validate a wildcard certificate. The cost is DNS credentials on the machine that renews. Limit them: use an API token scoped to the zone or to the records needed, or delegate _acme-challenge with a CNAME to a separate zone that exists only for validation. Allow for DNS propagation; good clients wait until the record is visible on the authoritative servers before asking the CA to check.
TLS-ALPN-01
Defined in RFC 8737, this challenge is answered on port 443 itself: the server presents a special self-signed certificate when the CA connects with the acme-tls/1 protocol. It suits servers and proxies that terminate TLS and have no port 80 open. It needs support in the software that owns port 443, which is why it is mostly used by web servers and proxies with ACME built in.
Wildcard certificates
With ACME, a wildcard such as *.example.com can only be validated with DNS-01, so automating wildcards means automating DNS changes. Wildcards reduce the number of certificates and keep individual host names out of public logs, but one wildcard is often deployed with the same private key on many servers, so a single compromised host exposes all of them. Prefer named certificates where automation is easy, and keep wildcards for cases with a clear reason.
ACME clients
Clients fall into a few groups, and most estates use more than one:
- Standalone clients such as certbot and acme.sh run on a server, renew on a timer and call a hook to reload the service. They are the usual choice for traditional web servers and for central renewal hosts that push certificates elsewhere.
- Servers with ACME built in, such as Caddy, obtain and renew their own certificates with no separate client or cron job.
- Platform controllers such as cert-manager for Kubernetes manage certificates as resources and store them as secrets for ingress controllers and workloads.
- Vendor integrations in hosting platforms, CDNs and appliances that request certificates for you through ACME behind the scenes.
Whatever the client, check three things: it renews based on each certificate's real lifetime rather than a fixed calendar, it generates a fresh key at renewal unless you have a reason not to, and the step after renewal (reloading the server, uploading to a load balancer) is part of the automation, not a manual follow-up.
Devices that cannot run ACME
The hard part of automation is rarely the web server. It is the load balancer, the CDN configuration, the firewall or VPN portal, the storage array's management page and the hosted application that only accepts a certificate file through a web form. These usually hold manually renewed certificates and are the first to break when lifetimes shrink. Options, roughly in order of preference:
- Use the built-in option. Many platforms now offer managed certificates or an ACME client in newer firmware. Check before building anything.
- Renew centrally, deploy through an API. Run an ACME client on a renewal host, usually with DNS-01, and push the new certificate and key to the device through its management API in the deploy hook. Use a dedicated API account with only the permissions needed.
- Terminate TLS in front of it. Put a reverse proxy that automates its own certificates in front of a device that cannot, and keep the device on an internal name with a private certificate.
- Move internal-only interfaces to private PKI. A management interface that only staff reach does not need a publicly trusted certificate. A private CA lets you choose lifetimes and keeps the name out of public logs.
- Replace it. A device that cannot accept certificates by API and has no automation path will need a manual renewal roughly every 47 days from 2029. That cost belongs in the next hardware decision.
When evaluating a platform, ask whether it supports short-lived certificates and frequent reloads without downtime. Some systems drop connections or need a restart on every certificate change, which becomes a problem at weekly or monthly renewals.
ACME Renewal Information (ARI)
A client that renews at a fixed point, say two-thirds of the lifetime, works until the CA needs certificates replaced early, for example after a validation problem forces a mass revocation. ACME Renewal Information (ARI, RFC 9773) lets the CA tell clients when to renew. The client asks the CA's renewalInfo endpoint about each certificate and gets back a suggested renewal window. It picks a random time inside the window, which spreads load on the CA, and re-checks as often as the server's Retry-After header asks.
If the CA moves the window earlier, ARI-aware clients renew in time without anyone reading an incident notice. Not every CA or client supports ARI yet; where both do, turn it on and keep a lifetime-based fallback.
Test against staging and respect rate limits
Production ACME servers limit how many certificates, orders and failed validations an account or domain can produce in a period. A misconfigured client that retries in a tight loop can lock you out of issuance for a while, which is the last thing you want during an outage. The limits differ by CA and change over time, so read your CA's current documentation rather than relying on fixed numbers.
- Use the CA's staging environment where it offers one (Let's Encrypt does) while setting up a client, a new challenge type or a deploy hook. Staging certificates are not trusted by browsers, so switch to production only once the full flow works.
- Retry with increasing delays, and alert on repeated failures instead of looping.
- Combine names that always belong together into one certificate instead of issuing many near-identical ones.
- Publish CAA records (RFC 8659) that list the CAs you use. They stop other CAs from issuing for your names, and they make an unexpected CA a deliberate change instead of an accident.
Monitor what is actually served
Automation fails quietly. The renewal can succeed while the server keeps serving the old certificate because the reload hook did not run, a second server behind the load balancer was missed, or the file was written to the wrong path. Monitor from the outside: connect to each host on port 443, read the certificate it presents and alert well before expiry.
Pick alert thresholds that match the lifetime. With 100-day certificates renewing at two-thirds, a certificate with less than a few weeks left means a renewal has already been missed. Watch for chain errors and unexpected issuers too, and check that the name list in the served certificate still matches what the service needs.