ACME stands for Automated Certificate Management Environment. It is the protocol that allows web servers to obtain, renew, and revoke TLS certificates automatically, without human intervention. Defined in RFC 8555, ACME was developed by Let’s Encrypt and the IETF to replace the manual, error-prone process of requesting, installing, and renewing certificates that had been standard practice since TLS was invented.
ACME is why Let’s Encrypt can issue hundreds of millions of certificates at no cost. It is also why certificates are now heading toward 47-day validity: when renewal is automated, shorter lifetimes are operationally painless and cryptographically beneficial.
The Problem ACME Solves
Before ACME, obtaining a TLS certificate involved a multi-step manual process: generate a key pair and CSR, submit the CSR to a CA’s web form, complete a validation process (upload a file, change a DNS record, or respond to a callback), download the issued certificate, install it on the server, update the server configuration, and remember to repeat the entire process before the certificate expired in a year or two.
The ‘remember to renew’ step was the real problem. Expired certificates were (and still are) one of the most common causes of outages in infrastructure that should be reliably available. When a TLS certificate expires, every browser shows a frightening error page, connections are refused, APIs break. An automated protocol that handles renewal before expiry eliminates this failure mode entirely.
The move toward 47-day certificate validity (CA/Browser Forum Ballot SC-081, taking effect progressively through 2029) is only possible because ACME exists. A 47-day certificate that must be manually renewed would require an organization to perform the renewal process roughly eight times per year per domain. With ACME, the client renews automatically when the certificate has around 30 days remaining, making the actual validity period invisible to operators.
How ACME Works: The Protocol Flow
An ACME interaction follows a specific sequence between the ACME client (software on your server) and the ACME server (operated by the CA). The key step is domain validation: the CA needs proof that you control the domain before it will issue a certificate for it.
Step 1: Account creation
The ACME client generates a key pair and registers an account with the ACME server. The account key pair identifies all future requests from this client to this CA. This happens once; subsequent certificate requests use the same account.
Step 2: Order creation
The client submits an order specifying which domain names it wants in the certificate. The ACME server responds with the list of domains and the authorizations needed for each : one per domain name.
Step 3: Domain authorization via challenge
For each domain in the order, the ACME server presents a challenge: a task that proves control of the domain. The client completes the challenge, notifies the CA, and the CA validates it. There are three challenge types:
| Challenge | How it works | Best for |
| HTTP-01 | ACME server specifies a token. Client places a file at http://domain/.well-known/acme-challenge/[token] with a specific value. CA fetches the URL to verify. | Simple web servers with port 80 accessible from the internet. Cannot be used for wildcard certificates. |
| DNS-01 | ACME server specifies a value. Client creates a DNS TXT record at _acme-challenge.domain with that value. CA queries DNS to verify. | Wildcard certificates (*.domain.com) where HTTP-01 cannot work. Also works when port 80 is blocked. Requires DNS API access for automation. |
| TLS-ALPN-01 | Client serves a special TLS certificate on port 443 using a specific ALPN extension. CA connects and verifies the certificate. | Servers that have port 443 but not 80 available. Less commonly used than the other two. |
Step 4: Certificate issuance
Once all domain authorizations are validated, the client submits a CSR (Certificate Signing Request) to the ACME server. The CA issues the certificate, typically within seconds. The client downloads and installs it automatically.
Step 5: Automatic renewal
ACME clients monitor certificate expiry and initiate a new order when the certificate is approaching its end of life (typically when 30 days of validity remain). The renewal repeats steps 2 through 4 automatically, requiring no human action. The old certificate keeps serving traffic until the new one is installed, so there is no downtime during renewal.
Let’s Encrypt: ACME at Scale
Let’s Encrypt is a free, automated, open CA operated by the Internet Security Research Group (ISRG). It was the organization that designed the ACME protocol, implemented the reference server, and pushed for its standardization as RFC 8555 in 2019. Let’s Encrypt has issued over three billion certificates and serves roughly half of all HTTPS websites by some estimates.
Let’s Encrypt issues only domain-validated (DV) certificates. It does not issue OV, EV, or code signing certificates. The automated validation model works for proving domain control; proving organizational identity requires human review, which ACME doesn’t provide.
Other CAs have adopted ACME. ZeroSSL, Buypass, and several enterprise CAs offer ACME endpoints. The protocol is CA-neutral; any CA can implement an ACME server, and ACME clients can be configured to use any ACME-compatible CA.
ACME Clients: Tools That Implement the Protocol
| Client | Platform | Notable feature |
| Certbot | Linux (EFF) | The reference implementation; supports Apache and Nginx plugins for automatic configuration |
| acme.sh | Linux/macOS shell script | Extensive DNS provider integrations; no dependencies beyond bash and curl |
| Caddy | Built into Caddy web server | HTTPS is on by default; Caddy obtains and renews certificates automatically with no configuration |
| win-acme | Windows | GUI and CLI for IIS and other Windows-based servers |
| Traefik | Docker/container environments | Automatic certificate management for containerized services using Let’s Encrypt |
| Certify The Web | Windows (GUI) | Windows IIS certificate management with a user-friendly interface |
Certbot quick reference
| # Install and obtain a certificate for an Nginx site:
$ certbot –nginx -d example.com -d www.example.com
# Obtain a certificate without modifying server config (standalone mode): $ certbot certonly –standalone -d example.com
# Renew all certificates nearing expiry: $ certbot renew
# Test renewal without making changes: $ certbot renew –dry-run
# Certbot installs a timer/cron for automatic renewal on most systems. # Verify it is active: $ systemctl status certbot.timer |
ACME and Code Signing: Why They Don’t Overlap
ACME is designed specifically for domain-validated TLS certificates. It proves you control a domain name by placing files or DNS records under that domain. This is useful for HTTPS but not for code signing, which requires verified organizational identity rather than domain control.
A code signing certificate says: this software was produced by Acme Corporation, a verified legal entity. That requires a human validation process (checking business registration databases, making phone calls to verified numbers, confirming an officer’s authorization) that cannot be automated by controlling a DNS record. The CA/B Forum’s Code Signing Certificate Requirements (CSBRs) mandate these validation steps explicitly. ACME cannot satisfy them.
The practical consequence is that Let’s Encrypt certificates, while excellent for HTTPS, cannot be used for code signing. Signtool requires the Code Signing EKU in the certificate; Let’s Encrypt only issues certificates with the serverAuthentication EKU. Even if you tried to use a Let’s Encrypt certificate for signing, the tooling would reject it.
Code signing certificates are obtained through the traditional manual validation process: submit an order, provide documentation, complete phone validation, and receive the certificate on a hardware token or cloud HSM. Automated renewal is available in a limited sense through CA portals and cloud HSM services, but nothing equivalent to ACME exists for code signing because the identity validation steps require human review.
Short Certificate Validity and Why Automation Makes It Practical
The CA/Browser Forum’s Ballot SC-081 established a schedule reducing TLS certificate maximum validity from 398 days (in 2020) to 200 days (March 2026), then to 100 days (2027), and finally to 47 days (2029). Each reduction is only practical because ACME makes renewal automatic.
The security case for shorter lifetimes: a compromised private key is useful to an attacker only as long as the certificate is valid. A 47-day certificate limits that window to 47 days. Revocation infrastructure has well-known gaps in enforcement; shorter certificates reduce reliance on revocation by making certificates stale quickly regardless.
For operators using ACME clients, the validity reduction is invisible. The client renews at 30 days remaining under a 90-day certificate (Let’s Encrypt’s current default), and would renew at a proportionally similar point for shorter lifetimes. The renewal frequency increases; the operational burden does not.
Frequently Asked Questions
Is ACME only for Let’s Encrypt?
No. ACME is a published standard (RFC 8555) that any CA can implement. Let’s Encrypt is the best-known ACME CA, but ZeroSSL, Buypass Go SSL, SSL.com (for DV certificates), and some enterprise CAs offer ACME endpoints. ACME clients like certbot and acme.sh can be configured to use any ACME-compatible CA by specifying the CA’s ACME directory URL.
Can ACME issue wildcard certificates?
Yes, through the DNS-01 challenge only. HTTP-01 cannot prove control of a wildcard domain because there is no single server to serve a challenge file for all possible subdomains. DNS-01 places a TXT record at _acme-challenge.domain.com, which covers all subdomains. Automating DNS-01 requires programmatic access to your DNS provider’s API; most major DNS providers have integrations in acme.sh and certbot’s DNS plugin ecosystem.
What happens if an ACME renewal fails?
ACME clients typically retry failures and alert the operator by email. Let’s Encrypt sends expiry warning emails at 20 days and 7 days before expiry regardless of the ACME client’s status, providing a backstop. If renewal continues to fail (often due to DNS configuration changes, firewall rules blocking port 80, or credential changes for DNS-01), the certificate expires and connections fail. Monitoring certificate expiry independently of the ACME client provides an additional safety net. Most monitoring platforms support certificate expiry alerts.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.