The ACME protocol isn’t just about automating certificate issuance; it’s a fundamental shift in how trust is managed on the internet, reducing the human error inherent in manual processes.
Let’s see ACME in action. Imagine a web server that needs a TLS certificate. We’ll use certbot, a popular ACME client, to get one for example.com.
First, certbot needs to prove it controls example.com. It asks the ACME server for a "challenge." The most common is the HTTP-01 challenge, which requires certbot to place a specific file at a predictable location on the web server: http://example.com/.well-known/acme-challenge/TOKEN. The ACME server then fetches this file to verify ownership.
# Example of certbot initiating a challenge (simplified representation)
# certbot --nginx -d example.com
Once the ACME server successfully fetches http://example.com/.well-known/acme-challenge/TOKEN and confirms its content matches the expected value, it issues a certificate. certbot then automatically configures the web server (like Nginx or Apache) to use this new certificate.
# Example Nginx configuration snippet after certbot runs
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ... other SSL settings
}
The core problem ACME solves is the operational overhead and error rate of manually obtaining, installing, and renewing TLS certificates. Before ACME, this was a tedious, often forgotten, process that led to widespread use of expired or insecure certificates. ACME automates this entire lifecycle. It works by defining a standardized API between a certificate authority (CA) and an ACME client (like certbot or lego). The client on your server communicates with the CA’s ACME endpoint to request certificates, prove domain control, and receive the signed certificates.
The ACME protocol defines several "challenges" to prove domain ownership, ensuring that only someone controlling the domain can obtain a certificate for it. The HTTP-01 challenge, as shown, is common, but the DNS-01 challenge is also powerful. For DNS-01, the ACME client is instructed to create a specific TXT record in the domain’s DNS zone. The ACME server then queries DNS for this record. This is useful for domains without publicly accessible web servers or when you want to automate certificate issuance for wildcard domains (*.example.com).
# Example of a DNS-01 challenge token (hypothetical)
# ACME Server provides: _acme-challenge.example.com TXT "AbCdEf1234567890"
# Client must create this record in DNS.
The protocol also handles certificate renewal. ACME clients are designed to periodically check if certificates are nearing expiration and automatically initiate the renewal process, often using the same challenges as the initial issuance. This ensures continuous trust without manual intervention.
The most surprising mechanical detail is how ACME handles the "account key" for a client. When you first run an ACME client, it generates a public/private key pair. This key pair is registered with the ACME CA. All subsequent requests from that client are signed with the private key associated with that registered account. This cryptographic binding allows the CA to identify and trust the client over time, without needing to re-verify identity for every single certificate request, as long as the client can still prove control over the requested domain(s).
The next step is understanding Certificate Transparency logs and how ACME interacts with them for public auditing of issued certificates.