What is ACME Protocol

ACME (Automatic Certificate Management Environment) is a protocol defined in RFC 8555 that standardizes how clients request, validate, and receive certificates from Certificate Authorities without human intervention. It replaces manual CSR submission, email-based domain validation, and portal-based certificate downloads with a fully programmatic JSON-over-HTTPS workflow. ACME is what makes Let’s Encrypt possible — and what makes 90-day certificate validity practical at any scale.

Why it matters

• Enables short-lived certificates — 90-day validity requires renewal every 60 days. ACME makes this automatic, eliminating the operational burden that would otherwise make short lifetimes impossible.
• Standardized across CAs — Let’s Encrypt, ZeroSSL, Buypass, Google Trust Services, and others all implement ACME. Switch CAs by changing one URL.
• Zero-touch provisioning — new servers request their own certificates at boot. Auto-scaling groups, containers, and ephemeral infrastructure get certificates without operator involvement.
• Eliminates human error — no forgotten renewals, no typos in CSRs, no expired certificates because someone was on vacation.
• Free DV certificates — ACME removed cost as a barrier to HTTPS adoption. Before 2015, even basic DV certificates cost $10-50/year.

How it works

1. Account registration — client generates a key pair, registers with the CA’s ACME directory. Account key signs all subsequent requests (JWS).
2. New order — client requests a certificate for one or more identifiers (domain names).
3. Authorization challenges — CA responds with challenge options per domain. Client selects one:
   • HTTP-01 — place a token file at http://{domain}/.well-known/acme-challenge/{token}
   • DNS-01 — create a TXT record at _acme-challenge.{domain} with a specific value
   • TLS-ALPN-01 — present a self-signed cert with ACME extension on port 443
4. Challenge fulfillment — client provisions the proof (file, DNS record, or TLS config).
5. Validation — CA verifies from multiple network vantage points. Authorization moves to “valid.”
6. Finalize — client submits CSR. CA signs and returns the certificate.
7. Renewal — client repeats the cycle before expiry (typically at 60 days for 90-day certs).

In real systems

Certbot (HTTP-01):

certbot certonly --webroot -w /var/www/html -d example.com
# Renewal via systemd timer
certbot renew --deploy-hook "systemctl reload nginx"

acme.sh (DNS-01 with Cloudflare):

export CF_Token="api-token"
acme.sh --issue -d "*.example.com" --dns dns_cf
# Only DNS-01 supports wildcard certificates

Kubernetes cert-manager:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: nginx

Where it breaks

HTTP-01 behind CDN — CA validation hits the CDN edge, not your origin. The challenge file isn’t there. Use DNS-01 for domains behind CDNs or configure the CDN to proxy /.well-known/acme-challenge/ to origin.

Rate limits — Let’s Encrypt: 50 certs per registered domain per week. A misconfigured renewal loop burns through limits, locking you out with no override. Use staging environment for testing.

DNS propagation delay — TXT record created but not yet visible to CA’s resolvers. Validation fails. Some providers need 120-300 seconds for propagation. Build in configurable sleep time.

Operational insight

ACME’s multi-perspective validation (validating from multiple geographic locations simultaneously) defends against BGP hijacking but means your challenge response must be globally reachable. Split-horizon DNS, geo-restricted endpoints, or firewall rules that block non-local traffic will cause validation failures even when the challenge works from your local network. Always ensure challenge endpoints are publicly accessible from any location.

Related topics

• What is a TLS Certificate
• Certificate Enrollment
• Certificate Automation at Scale
• What is EST
• Certificate Renewal and Revocation