ACME

What ACME is

ACME is a standardised HTTP+JSON protocol for automated certificate issuance. A client (the thing needing a certificate) talks to an ACME server (the thing issuing certificates), proves control of the identifiers it wants to be certified for (domain names, usually), and receives a signed certificate — all without a human in the loop.

The core specification is RFC 8555 (ACMEv2, March 2019). It replaces the earlier draft ACMEv1 and adds support for wildcard certificates, the finalize + order state machine, and the account-per-client model.

What ACME does

1. Register an account. The client generates an account key pair, sends the public half to the ACME server with a POST to /newAccount, and optionally agrees to the CA's terms of service.
2. Create an order. The client sends a POST to /newOrder with the list of identifiers it wants on the certificate (domain names, IP addresses in some flavours).
3. Respond to challenges. The server returns one or more authorization objects, each containing a set of challenges the client can complete to prove control of the identifier. Common challenge types: http-01, dns-01, tls-alpn-01.
4. Finalize the order. Once challenges validate, the client POSTs a Certificate Signing Request (CSR) to the order's finalize URL.
5. Download the certificate. The server returns a URL; the client fetches the certificate.

Renewal is: repeat steps 2-5 against a new order. Many clients reuse the account key across renewals.

Why ACME matters

Before ACME, TLS certificate issuance for a public CA was manual: fill in a web form, prove domain control via a copy-paste code, get the cert via email, install by hand. The process broke at scale and was the single largest reason organisations shipped expired certs. ACME inverts the model — the CA exposes an API, the client's cert-management software owns the full lifecycle.

Operationally this is why the CA/Browser Forum has been able to push certificate lifetimes down from 398 days (2020) to 200 (2026), 100 (2027), and 47 (2029). Shorter lifetimes demand automation; ACME makes automation possible. The two work together.

Challenges — the validation methods

Every ACME issuance proves domain control via one of four challenge types. Each has operational trade-offs.

http-01

The CA tells the client to serve a known token at http://<domain>/.well-known/acme-challenge/<token>. The CA fetches that URL (sometimes from multiple network perspectives under MPIC) and validates the token matches.

• Requires: the client can serve HTTP on port 80.
• Can issue: single-domain certificates. Cannot issue wildcards.

dns-01

The CA tells the client to publish a TXT record at _acme-challenge.<domain> with a specific value. The CA resolves the record and validates.

• Requires: DNS API access (Route 53, Cloudflare, Google DNS, Azure DNS, etc.).
• Can issue: wildcards. The only challenge type that can.

tls-alpn-01

The CA initiates a TLS handshake using the acme-tls/1 ALPN protocol, and the client responds with a self-signed certificate carrying the token in a specific extension.

• Requires: the client can terminate TLS on port 443 with ALPN support.
• Can issue: single-domain certificates. Useful when ports 80 and DNS automation are both unavailable.

device-attest-01

An ACME extension (not RFC 8555 itself; Apple's draft) where the client proves possession of a hardware-attested key. Used for Apple's SCEP-replacement flows in Jamf and Workspace ONE.

ACME Renewal Information (ARI)

RFC 9773 adds an endpoint that lets the CA signal when the client should renew. Instead of the client renewing on a fixed schedule (say, T-30 days before expiry), the client polls /renewalInfo/<cert-id> and renews when the CA indicates. This matters when the CA needs to bulk-rotate due to a misissuance event, revocation campaign, or policy change — the whole fleet renews on signal, without manual coordination.

ARI is live at Let's Encrypt. Client support is in cert-manager 1.15+, Caddy 2.9+, and lego 4.17+.

Who speaks ACME

Public CAs: Let's Encrypt, ZeroSSL, Sectigo (SCM ACME), DigiCert (ACME via CertCentral), Google Trust Services, Buypass.

Private PKI: HashiCorp Vault PKI (ACME path), Smallstep step-ca, Caddy's built-in CA, Microsoft NDES does not (ADCS has no native ACME), TigerTrust PKI-as-a-Service (ACME v2 + ARI).

Clients: certbot, acme.sh, lego, cert-manager (Kubernetes), Traefik and Caddy built-in, nginx-acme, mod_md (Apache), HAProxy, and dozens of library bindings.

Operational considerations

• Rate limits. Let's Encrypt and most public CAs rate-limit per account and per registered domain. Production estates need to plan around these — bulk-issuing 10,000 certs in an hour hits limits.
• Account key custody. If you lose the account key, you lose the ability to manage certificates issued under that account. Back up the key the same way you back up TLS private keys.
• Firewall rules for MPIC. Multi-Perspective Issuance Corroboration means CAs validate from multiple source IPs. Firewalls that whitelist specific CA IPs break under MPIC — the CA has to reach /.well-known/acme-challenge/ from several network vantage points.
• Logging. ACME clients should log every order, every challenge response, every renewal. The audit trail matters when a certificate is misissued or a renewal fails silently.

Related reading

• RFC 8555 — Automated Certificate Management Environment
• RFC 9773 — ACME Renewal Information
• Let's Encrypt's ACMEv2 documentation