ACME, the Automatic Certificate Management Environment, is the protocol in RFC 8555 that lets a client prove it controls a domain and receive a signed TLS certificate from a certificate authority, with no human in the loop. It exists so that certificates can be issued and renewed by software.
What problem did it solve?
The RFC's abstract states it plainly: domain validation had been done through "a collection of ad hoc mechanisms". People emailed, clicked links and pasted files. ACME replaces that with one protocol that a CA and an applicant both speak. It was published in March 2019 as an IETF Standards Track document.
How does the flow work?
The RFC describes a short sequence.
- Account. The client creates an account at the CA, identified by a key pair. Requests are signed with that key.
- Order. The client asks for a certificate for one or more names.
- Authorization. For each name, the CA offers challenges. The client must complete one to show control of the name.
- Finalize. Once all names are validated, the client posts a certificate signing request to the order's finalize URL.
- Download. The CA issues the certificate and the client fetches it.
Every request carries a fresh nonce, which the server hands out through a newNonce resource. Nonces stop an old signed request being replayed.
What are the challenge types?
The RFC defines two: http-01 and dns-01. With HTTP, the client serves a specific token at a well-known path on the domain, and the CA fetches it. With DNS, the client publishes a value in a TXT record. HTTP is simple and fits a public web server. DNS works for names with no web server, and many CAs require it for wildcard names, so check your CA's policy. It needs an API for your DNS provider.
A third type, TLS-ALPN, came later in a separate RFC and is not covered here.
What can go wrong?
Constructed example: a team automates renewals with a DNS challenge, and gives the renewal job an API token that can edit every record in the zone. A leak of that token now lets an attacker change mail and web records, not just prove control of a name. Scope the token to the challenge records only, or delegate the challenge name to a separate zone.
Other failure modes are duller and more common. A renewal job silently fails, nobody notices, and the certificate expires on a Saturday. A firewall rule blocks the CA's validation request. An account key sits on a laptop.
Why do short certificate lifetimes matter?
Automation changes what is practical. When issuing a certificate takes a person and an afternoon, long lifetimes make sense. When software can renew in seconds, short lifetimes become workable, and they limit the time a stolen key stays useful. The protocol itself does not set lifetimes. The CA does, so check what yours issues and design for renewals well inside that window. Teams that move to automation often find forgotten certificates on old systems, which is a useful side effect of building the inventory.
How to check or apply this
- Inventory every certificate and its expiry date, including internal and forgotten ones.
- Choose the challenge type per name: HTTP for public web servers, DNS for hosts with no inbound access and where your CA requires it.
- Give DNS automation the narrowest token your provider supports.
- Store the ACME account key like any signing key: restricted access, backed up, rotated on a plan.
- Alert on certificates with fewer than 14 days left, so a failed renewal has time to be fixed. Choose your own threshold.
- Test the full renewal path in staging, not only the first issuance.
Quick check
Does ACME work only with one CA?
No. It is an open IETF standard. Any CA that implements RFC 8555 can be used by any compliant client.
Can ACME issue wildcard certificates?
The RFC defines how wildcard names appear in an order and its authorization. Which challenge a CA accepts for them is its own policy, and many require DNS, so check your CA's documentation.
Sources
Last reviewed: 18 October 2026.
