ACME stands for Automatic Certificate Management Environment. It is the protocol that RFC 8555 standardized in 2019, originally designed by the team that founded Let's Encrypt at the Internet Security Research Group. Its single job is to let a piece of software prove to a certificate authority (CA) that it controls a domain name, and then receive a signed TLS certificate for that domain — all over an API, with no phone calls, no support tickets, and no manual identity vetting.
That sounds mundane. It was revolutionary. Before ACME, the friction of obtaining certificates was the single biggest reason most of the web ran on unencrypted HTTP. Let's Encrypt, built entirely around ACME, is now the largest certificate authority in the world by issuance volume, and the fraction of web page loads served over HTTPS in Firefox's telemetry climbed from roughly a quarter in 2015 to over four-fifths within a few years. Automation, not persuasion, did that.
What a certificate actually proves
A TLS certificate is a signed statement: "the holder of this public key controls this domain name." When your browser connects to a site, the server presents its certificate, the browser checks that a trusted CA signed it, and that the server can prove possession of the matching private key. That chain is what stops an attacker on your network from impersonating your bank — the topic we cover in depth in TLS 1.3 vs 1.2.
The hard part has never been the cryptography. It is the validation: how does a CA, which has never met you, decide that you really control example.com before it signs a certificate for it? Get that wrong and the entire trust model collapses. ACME's clever contribution is automating this validation step safely.
The challenge: proving you own the domain
ACME validation is built on "challenges." The CA issues a random token and says, in effect: "If you really control this domain, you'll be able to place this token where only the domain operator could." There are two main challenge types.
| Challenge | How you prove control | Best for |
|---|---|---|
| HTTP-01 | Serve the token as a file at /.well-known/acme-challenge/<token> over port 80 |
A single web server with a public IP |
| DNS-01 | Publish the token (hashed) as a _acme-challenge TXT record in DNS |
Wildcards, internal servers, multi-host setups |
| TLS-ALPN-01 | Present a special certificate during a TLS handshake on port 443 | Environments where only 443 is reachable |
The CA then independently fetches that file or DNS record from multiple network vantage points and confirms the token matches. Only DNS-01 can issue wildcard certificates (*.example.com), because serving one file can't prove control over every possible subdomain, but control of the zone's DNS can.
Let's Encrypt validates challenges from several geographically distributed network perspectives at once. This "multi-perspective validation" makes BGP hijacking attacks far harder: an attacker would need to hijack the route to your domain from all validation vantage points simultaneously, not just one, to fraudulently pass a challenge.
The full handshake, step by step
Under the hood, ACME is a JSON-over-HTTPS protocol where every request from the client is signed with the account's private key (using JWS, JSON Web Signature). A typical issuance looks like this:
- Account creation. The client generates a key pair and registers an account with the CA, agreeing to terms of service.
- Order. The client submits an order listing the domain names it wants on the certificate.
- Authorization & challenges. The CA returns a challenge for each domain. The client provisions the required file or DNS record.
- Validation. The client tells the CA it's ready; the CA checks the challenges from multiple perspectives.
- Finalization. The client sends a Certificate Signing Request (CSR) containing the certificate's public key. Crucially, this key is separate from the account key.
- Download. The CA signs and returns the certificate chain, which the server installs.
Tools like Certbot, acme.sh, Caddy, and the ACME clients built into modern reverse proxies handle all six steps and schedule renewals automatically. Because Let's Encrypt certificates are valid for only 90 days, automation isn't a convenience — it's mandatory. Short lifetimes are a deliberate security choice: they limit the damage window if a key is compromised and reduce reliance on the historically broken certificate revocation system.
What ACME does not do
ACME automates domain validation certificates, and nothing more. It's worth being precise about the boundaries, because the automation can create a false sense of completeness.
A certificate proves you control a domain at issuance time. It does not vouch for the honesty of the site, the safety of its code, or the identity of the human or company behind it.
- No organizational identity. ACME issues DV certificates. It confirms domain control, not that "Acme Corp Inc." is a real, vetted legal entity. A phishing site at
paypa1-login.comcan get a perfectly valid certificate. - It doesn't replace monitoring. Because anyone who controls a domain can get a cert for it, you should watch Certificate Transparency logs to detect certificates issued for your domains that you didn't request.
- It doesn't enforce who may issue. That's the job of CAA records, which let you declare in DNS which CAs are allowed to issue for your domain. ACME CAs check CAA before issuing.
Why this matters for privacy infrastructure
Ubiquitous, free, automated TLS is one of the quiet wins of the past decade. When encryption is hard and expensive, only the sites that can afford it get it, and unencrypted traffic — including the metadata about who is reading what — leaks to every network in the path. ACME made the default secure. Encrypted transport is now the floor, not a premium feature.
That floor is exactly what infrastructure-grade privacy should look like: the secure path is the automatic path, requiring no expertise and no recurring decision from the operator. At Haven, we apply the same principle to messaging — encryption that's on by default and invisible in use, rather than an option a user has to find and enable. The mechanics differ, but the philosophy is identical: security that depends on people remembering to turn it on is security that fails for most people.
ACME is a good reminder that the most consequential security improvements often aren't new cryptography. They're the removal of friction that kept good cryptography from being used.