ACME, the Automatic Certificate Management Environment, is a protocol that lets software request, validate, obtain, renew and revoke TLS certificates from a certificate authority without human involvement. In Internet trust, it is the mechanism that made short-lived, automatically renewed certificates practical at global scale and turned HTTPS from a paid, manual chore into a default.
ACME was developed for a large nonprofit certificate authority that launched in 2015 and standardized as RFC 8555 in 2019. It is now supported by many public and private CAs, by web servers, load balancers, Kubernetes controllers and hosting panels. The protocol runs over HTTPS with JSON messages signed by an account key, and its central idea is that a client proves control of a domain through automated challenges instead of emails or paperwork.
How the ACME protocol issues a certificate
An ACME exchange follows a fixed sequence of resources exposed by the CA’s ACME server, starting from a directory URL that lists all endpoints. Every request is a JWS-signed message, and the server provides fresh nonces to prevent replay.
- Account creation: the client generates a key pair and registers it with the CA, optionally with a contact address.
- New order: the client submits the list of domain names, called identifiers, that the certificate should cover.
- Authorizations: for each identifier, the server returns challenges the client can choose from.
- Challenge response: the client publishes the proof and tells the server to validate it.
- Finalization: once all authorizations are valid, the client sends a certificate signing request (CSR).
- Download: the client retrieves the issued certificate together with its intermediate chain.
Clients exist for nearly every platform, from standalone command-line tools to built-in support in web servers such as Caddy, and Kubernetes controllers that store certificates as secrets. Because the protocol is standardized, an operator can switch certificate authorities by changing only the directory URL and account, without redesigning the deployment.
The account key and the certificate key are separate. The account key authenticates the client to the CA, while the certificate key pair belongs to the server that will present the certificate, which allows keys to be rotated independently.
ACME challenge types
Challenges are how ACME performs domain control validation. Each challenge combines a random token from the server with the account key thumbprint, so only the account holder can produce a valid answer. The choice of challenge decides what infrastructure the client must control.
| Challenge | Proof location | Wildcard support | Typical use |
|---|---|---|---|
| HTTP-01 | File under /.well-known/acme-challenge/ on port 80 | No | Single web servers with public port 80 |
| DNS-01 | TXT record at _acme-challenge.domain | Yes | Wildcards, internal hosts, many servers |
| TLS-ALPN-01 | Special certificate on port 443 via ALPN | No | TLS terminators without port 80 |
DNS-01 is the only challenge that issues wildcard certificates, and it works for hosts that are not reachable from the Internet at all. Its cost is that the ACME client needs API credentials for the DNS provider, which should be scoped as narrowly as possible because they could otherwise modify the entire zone.
Renewal, lifetimes and automation
ACME is designed around frequent automated renewal. Public certificates issued through ACME have traditionally lasted 90 days, and clients usually renew when about one third of the lifetime remains, around day 60. Industry rules adopted by browser root programs are reducing maximum certificate lifetimes in stages over the coming years, which makes automation effectively mandatory.
| Parameter | Typical value | Effect |
|---|---|---|
| Certificate lifetime | 90 days, shorter profiles also offered | Limits damage from key compromise |
| Renewal point | About 30 days before expiry | Leaves time to recover from failures |
| Authorization reuse | Up to about 30 days, CA dependent | Avoids repeated challenges |
| ACME Renewal Information (ARI) | Server-suggested renewal window | Spreads load, enables early mass renewal |
The ARI extension lets a CA tell clients when to renew, which matters when certificates must be replaced early after a revocation event. Clients that support ARI react within hours instead of waiting for their fixed schedule.
ACME compared with other certificate workflows
Before ACME, obtaining a certificate meant generating a CSR by hand, pasting it into a web form, answering a validation email and installing the result manually. The table below compares ACME with this and other enrollment protocols.
| Approach | Automation | Validation | Typical environment |
|---|---|---|---|
| ACME | Full, including renewal | Automated DNS, HTTP or TLS challenge | Public web, cloud, Kubernetes |
| Manual CSR and web portal | None | Email or manual review | Legacy and OV or EV certificates |
| SCEP | Partial | Shared secret or challenge password | Network devices, mobile device management |
| EST | High | TLS client authentication | Enterprise and IoT devices |
ACME issues domain-validated certificates by default. Organization-validated and extended-validation certificates still require identity checks outside the protocol, although some commercial CAs bind ACME accounts to pre-validated organizations through external account binding (EAB).
Common ACME pitfalls
ACME failures are usually silent until expiry: a renewal fails, nobody notices, and the certificate lapses weeks later. Monitoring expiry dates independently of the ACME client is the single most effective safeguard.
- Blocking port 80 with a firewall or redirect rule, which breaks HTTP-01 validation.
- CAA records that do not authorize the CA the ACME client uses.
- Hitting rate limits by repeatedly requesting certificates during testing instead of using the staging environment.
- Failing to reload the server after renewal, so the old certificate stays in memory.
- Storing DNS API tokens with full zone rights on every web server.
Load-balanced setups need extra care with HTTP-01, because the validation request may reach a different node than the one that wrote the token. Centralizing issuance or using DNS-01 for clusters avoids this problem.
In simple terms
A website needs a certificate to show the padlock in the browser. Getting one used to mean forms, emails and manual installation, and then repeating it every year. People often forgot, and websites broke.
ACME is an agreed set of rules that lets a server handle this by itself. The server asks the certificate authority for a certificate. The authority asks for proof that the server really controls the domain, such as a small file or a DNS entry. The server provides it, receives the certificate and renews it automatically long before it expires.
A practical example
A small software company runs about forty internal and public services behind a reverse proxy, plus a wildcard name for customer previews. Its operations engineer configures an ACME client to use the DNS-01 challenge with a token limited to creating TXT records under _acme-challenge. One certificate covers *.preview.company.example, and separate certificates cover each public service.
The client checks certificates twice a day and renews any that have fewer than 30 days left, then reloads the proxy. An external monitor alerts if any certificate falls below 14 days. Over two years, renewals run hundreds of times without human intervention, and when the CA announces an early replacement after an incident, the ARI-aware client renews all affected certificates within a day.