What is ACME Protocol

ACME (Automatic Certificate Management Environment) is a protocol defined in RFC 8555 that automates interactions between certificate authorities and servers requesting certificates. It replaces the manual process of generating a CSR, submitting it to a CA, proving domain ownership via email, and downloading the issued certificate. ACME handles all of this programmatically — account registration, domain validation challenges, certificate issuance, and renewal — over HTTPS with JSON payloads signed using JWS.

Why it matters

• 90-day validity requires automation — Let’s Encrypt issues certificates valid for only 90 days. Manual renewal at that cadence across hundreds of domains is impossible. ACME makes short-lived certificates practical.
• Eliminates human error — no more expired certificates because someone forgot to renew. ACME clients run on timers and renew automatically 30 days before expiry.
• Standardized across CAs — any ACME-compliant CA (Let’s Encrypt, ZeroSSL, Buypass, Google Trust Services) works with any ACME client. No vendor lock-in.
• Enables zero-touch provisioning — new servers can request their own certificates at boot time without operator intervention. Critical for auto-scaling infrastructure.
• Free DV certificates at scale — ACME removed cost as a barrier. Before Let’s Encrypt launched in 2015, even basic DV certificates cost $10-50/year each.

How it works

1. Account creation — the ACME client generates a key pair and registers with the CA’s ACME directory endpoint. The account key signs all subsequent requests.
2. Order submission — the client sends a new-order request specifying the domain names (identifiers) it wants on the certificate.
3. Challenge selection — the CA responds with authorization objects, each containing challenge options (HTTP-01, DNS-01, or TLS-ALPN-01). The client picks one per domain.
4. Challenge fulfillment — the client provisions the proof: places a file at /.well-known/acme-challenge/{token} (HTTP-01), creates a DNS TXT record at _acme-challenge.{domain} (DNS-01), or configures a self-signed cert with the ACME extension on port 443 (TLS-ALPN-01).
5. Validation — the CA’s validation servers verify the challenge from multiple network vantage points. If the proof is correct, the authorization status moves to “valid.”
6. CSR submission and issuance — the client submits a CSR via the finalize URL. The CA signs it and makes the certificate available at the order’s certificate URL.
7. Renewal — the client repeats steps 2-6 before expiry. Most clients trigger renewal at 60 days remaining (for 90-day certs), giving 30 days of retry buffer.

In real systems

Certbot (standalone):

certbot certonly --standalone -d example.com -d www.example.com
# Uses HTTP-01 challenge on port 80
# Stores certs in /etc/letsencrypt/live/example.com/
# Auto-renewal via systemd timer: certbot renew --deploy-hook "systemctl reload nginx"

acme.sh with DNS-01 (Cloudflare):

export CF_Token="your-api-token"
acme.sh --issue -d "*.example.com" --dns dns_cf
# Creates _acme-challenge TXT record via Cloudflare API
# Only way to get wildcard certificates via ACME

Kubernetes cert-manager:

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

cert-manager watches Certificate resources, creates ACME orders, provisions challenge pods or ingress rules, and stores issued certificates as Kubernetes Secrets.

Caddy — has ACME built into the server itself. Point Caddy at a domain and it automatically obtains and renews certificates with zero configuration. It uses TLS-ALPN-01 by default (no port 80 needed).

Where it breaks

HTTP-01 behind a CDN or reverse proxy — the CA’s validation servers hit your domain on port 80, but the request lands at the CDN edge, not your origin server. The challenge file isn’t there. This fails silently — certbot reports “unauthorized” with no clear explanation. Fix: use DNS-01 for domains behind CDNs, or configure the CDN to proxy /.well-known/acme-challenge/ to your origin.

DNS-01 propagation delay — after creating the TXT record, the CA queries authoritative DNS. If your DNS provider hasn’t propagated the record yet (TTL issues, slow API), validation fails. acme.sh defaults to a 120-second sleep, but some providers (especially those with multi-region sync) need longer. Repeated failures burn through your retry window.

Rate limits — Let’s Encrypt enforces 50 certificates per registered domain per week, 5 duplicate certificates per week, and 300 new orders per account per 3 hours. Hit these during a mass deployment or misconfigured renewal loop and you’re locked out. There’s no way to lift the limit — you wait. Use the staging environment (acme-staging-v02.api.letsencrypt.org) for testing.

Operational insight

ACME’s multi-perspective validation (introduced by Let’s Encrypt in 2020) means the CA validates challenges from multiple geographic locations simultaneously. This defends against BGP hijacking attacks where an attacker reroutes traffic from a single vantage point to pass validation fraudulently. But it also means your challenge response must be globally reachable — not just from your local network. If you’re testing ACME in a staging environment with split-horizon DNS or geo-restricted access, validation will fail from remote vantage points even though it works locally. Always ensure challenge endpoints are publicly accessible from any location before triggering validation.

Related topics

• What is a TLS Certificate
• What is a TLS Handshake
• Certificate Renewal and Revocation
• What is a Certificate Authority