How ACME Protocol Works: A Complete Guide to Automated Certificate Enrollment

byAlex R. •
🔐

ACME Protocol

Automated Certificate Management Environment — How the Internet automates SSL/TLS certificate issuance and renewal

RFC 8555 Let's Encrypt Zero-Touch PKI TLS Automation

What is the ACME Protocol?

The Automated Certificate Management Environment (ACME) protocol, standardized in RFC 8555 (March 2019), is an open standard that allows web servers and clients to automatically obtain, renew, and revoke TLS/SSL certificates from a Certificate Authority (CA) — with zero human intervention.

Before ACME, obtaining a certificate required manually: generating a Certificate Signing Request (CSR), submitting it to a CA, completing an identity validation process, downloading the certificate, and installing it — all on a renewal schedule typically every 1–2 years. ACME automates every step of this process, reducing certificate lifetimes to 90 days (as used by Let's Encrypt) to improve security posture.

Today ACME is the backbone of Let's Encrypt — the free CA that has issued over 3 billion certificates — and is supported by major commercial CAs including DigiCert, Sectigo, and Certbot clients worldwide.

Manual vs. ACME: The Paradigm Shift

Manual Certificate Management vs. ACME Automation ❌ Manual Process 1 Generate CSR manually 2 Submit to CA portal/email 3 Complete domain validation 4 Wait hours/days for issuance 5 Download & install cert manually ⏱ Hours to Days · 1-2 Year Validity · Error-Prone ✅ ACME Automated Process 1 Client generates keypair automatically 2 Account registered via HTTPS API 3 Automated domain challenge solved 4 Cert issued in seconds 5 Auto-install & schedule renewal ⚡ Seconds · 90-Day Validity · Fully Automated

Core ACME Concepts

Before diving into the workflow, it's essential to understand the key actors and data structures in the ACME ecosystem:

ACME Ecosystem: Key Components 🖥️ ACME Client (e.g., Certbot, acme.sh) • Generates key pairs • Handles challenges • Signs requests (JWS) • Installs certificates • Schedules auto-renewal • Manages revocation 🏛️ ACME Server (CA) (e.g., Let's Encrypt) • Issues nonces • Manages accounts • Validates challenges • Issues certificates • Handles revocation • Exposes REST API 🌐 Domain/DNS (Subscriber's infrastructure) • Serves HTTP-01 files • Hosts DNS TXT records • Responds to TLS-ALPN • Serves certificates • End-user HTTPS service HTTPS/JSON Responses Validates Challenge

The ACME Certificate Enrollment Workflow

The ACME protocol operates through a well-defined, 5-phase workflow. Every message between the client and server is a JSON Web Signature (JWS) — a cryptographically signed JSON object — sent over HTTPS. Here's a step-by-step breakdown:

ACME Full Certificate Enrollment Flow ACME Client ACME Server (CA) Domain / DNS PHASE 1: Fetch Nonce & Directory GET /directory 200 OK: {endpoints, nonce} PHASE 2: Account Registration POST /newAccount {JWK, contact, ToS} 201 Created: account URL + kid PHASE 3: Order Creation & Authorization POST /newOrder {identifiers: [domain]} 201: order URL, authz URLs, finalize URL POST {authz URL} — fetch challenges 200: [{type:http-01, token}, {type:dns-01}] PHASE 4: Domain Validation (Challenge) Deploy: /.well-known/acme-challenge/<token> POST {challenge URL} — ready signal GET /.well-known/acme-challenge/<token> token.thumbprint (keyAuthorization) authz status: valid ✓ PHASE 5: Finalize Order & Retrieve Certificate POST /finalize {csr: <DER-encoded CSR>} 200: order processing → valid POST {certificate URL} 200: PEM certificate chain 🎉 Install certificate on web server Security Mechanisms Anti-Replay Nonces: Each request must include a fresh one-time-use nonce from the server to prevent replay attacks JWS Signatures: All client messages are JSON Web Signatures — signed with the account private key to prove identity Domain Proof: The CA verifies domain control by checking a challenge response only the domain owner can provide Short Validity: 90-day certificates force frequent renewal, limiting exposure from compromised keys

ACME Challenge Types: Proving Domain Ownership

The most critical step in ACME is domain validation. The CA must be convinced that the entity requesting a certificate actually controls the domain. ACME defines three challenge types:

ACME Domain Validation Challenge Types HTTP-01 Most Common · Port 80 📋 How it works: CA issues a token. Client places a file at: /.well-known/acme-challenge/TOKEN File content: TOKEN.THUMBPRINT CA fetches over HTTP to verify. ✓ Simple to implement ✓ No DNS access needed ✗ Requires port 80 open ✗ No wildcard certs ✗ Not for internal servers DNS-01 Wildcards Supported · DNS API 📋 How it works: CA issues a token. Client creates a DNS TXT record at: _acme-challenge.DOMAIN.COM Value: BASE64URL(SHA256(TOKEN.TP)) CA queries DNS to verify record. ✓ Wildcard certificates (*.domain) ✓ Works for internal servers ✓ No web server needed ✗ Needs DNS API access ✗ Propagation delay (TTL) TLS-ALPN-01 Advanced · Port 443 Only 📋 How it works: Client creates a self-signed cert with special ALPN extension: acmeValidation-v1 (OID) containing token hash CA connects via TLS port 443. Validates the special certificate. ✓ Port 443, no port 80 needed ✓ No file system access needed ✗ Complex implementation ✗ No wildcard certs ✗ Rare CA support

Security: JSON Web Signatures & Nonces

Every ACME request is not a plain JSON HTTP call — it's a JSON Web Signature (JWS), as specified in RFC 7515. This cryptographic envelope ensures that:

  • Identity: The message genuinely comes from the account holder (signed with the account private key)
  • Integrity: The payload hasn't been tampered with in transit
  • Replay-Prevention: Each request includes a nonce (one-time token) obtained from the server
ACME Request: JWS (JSON Web Signature) Structure Protected Header { "alg": "RS256", "nonce": "oFvnlFP1...", "url": "https://ca/order", "kid": "https://ca/acct/1" } BASE64URL encoded alg: signature algorithm nonce: prevents replay attacks kid: account identifier Payload { "identifiers": [ { "type": "dns", "value": "example.com" }] } BASE64URL encoded The actual request body (empty string for key rollover) Signature Sign( BASE64URL(header) + "." + BASE64URL(payload) with account private key ) BASE64URL encoded result ✅ Proves account ownership ✅ Tamper-proof payload ✅ Bound to specific URL+nonce . .

Certificate Lifecycle & Auto-Renewal

One of ACME's most powerful features is automated renewal. Because 90-day certificates expire frequently, clients like Certbot schedule renewal at the 2/3 mark (≈60 days), giving a 30-day safety window. Here's the full lifecycle:

90-Day Certificate Lifecycle Timeline Day 0 Day 60 Day 75 Day 90 ✅ Valid — Serving HTTPS Traffic 🔄 Renew Now ⚠️ Expiring Certbot renews here Days 0–60: Full validity, cert actively served Days 60–75: Certbot triggers ACME renewal Days 75–90: Expiring (fallback window) On renewal, the entire ACME enrollment flow is re-executed automatically by the ACME client

Popular ACME Clients

A number of mature, production-grade ACME clients are available across different platforms and languages:

Client Language Best For Challenges Supported
Certbot Python Apache/Nginx on Linux HTTP-01, DNS-01
acme.sh Shell Script Minimal environments, Docker HTTP-01, DNS-01, TLS-ALPN-01
win-acme .NET / C# Windows / IIS HTTP-01, DNS-01, TLS-ALPN-01
Caddy Go Built-in ACME web server HTTP-01, TLS-ALPN-01, DNS-01
Traefik Go Kubernetes / Docker HTTP-01, DNS-01, TLS-ALPN-01
cert-manager Go Kubernetes native HTTP-01, DNS-01
Boulder Go CA Server (Let's Encrypt) Server-side implementation

Security Considerations & Best Practices

✅ Best Practices

  • Store the account private key securely (never commit to version control)
  • Use DNS-01 for wildcard certificates
  • Monitor certificate expiry with alerting
  • Enable HSTS after HTTPS deployment
  • Prefer short-lived (90-day) certs over long-lived ones
  • Use OCSP stapling to reduce revocation checks

⚠️ Common Pitfalls

  • Hitting Let's Encrypt rate limits (50 certs/domain/week)
  • Not testing with the staging environment first
  • Firewall blocking port 80 for HTTP-01 challenges
  • DNS propagation delays causing DNS-01 failures
  • CAA records blocking your chosen CA
  • Not automating renewal (letting certs expire)

Certificate Revocation via ACME

ACME also handles certificate revocation through the /revokeCert endpoint. An account holder (or the certificate's key holder) can revoke a certificate immediately — critical when a private key is compromised. The request includes the DER-encoded certificate and an optional revocation reason code (e.g., keyCompromise = 1).

Conclusion

The ACME protocol has fundamentally transformed how the web manages TLS certificates. By automating account creation, domain validation, certificate issuance, installation, and renewal into a secure cryptographic protocol, ACME has removed the biggest barrier to universal HTTPS adoption — human complexity.

Whether you're running a single Nginx blog with Certbot, a microservices cluster with cert-manager, or building your own CA infrastructure with Boulder, ACME is the standard protocol enabling the modern encrypted internet.

Tags:

ACME RFC 8555 TLS/SSL Let's Encrypt PKI Certificate Automation Web Security Certbot DevOps

Post a Comment

Previous Post Next Post
Share to other apps
Copy Post Link