ACME Protocol

Before ACME, encrypting your website was a chore you scheduled quarterly, dreaded, and occasionally forgot. You'd generate a Certificate Signing Request, submit it through a web form, wait for someone to validate it, download the certificate, figure out where it goes, restart your server, and hope you didn't break anything. Then you'd do it all again in a year—if you remembered.

After ACME, encryption is something that just happens while you sleep.

The Protocol That Solved Certificate Pain

ACME—Automatic Certificate Management Environment—is a protocol that lets software talk to Certificate Authorities. Your server runs an ACME client. The client talks to an ACME server at a CA like Let's Encrypt. Between them, they handle everything: proving you own the domain, generating the certificate, installing it, and renewing it before it expires.

No web forms. No emails. No calendar reminders. No 3am panic when you realize your certificate expired yesterday.

The protocol was developed by Let's Encrypt and standardized by the IETF, which means it's not proprietary. Any client can talk to any compliant CA. You're not locked in.

How It Actually Works

The conversation between client and server follows a predictable pattern:

First contact: Your client registers an account with the CA using a public key. This happens once. The key proves who you are for all future requests.

Certificate request: The client says "I want a certificate for example.com." The server responds with a challenge—a task the client must complete to prove it actually controls example.com.

Proof of ownership: The client completes the challenge. Maybe it places a specific file on your web server. Maybe it creates a DNS record. The CA checks that the proof exists.

Certificate issued: Once convinced, the CA issues the certificate. The client downloads it, installs it, and your site is encrypted.

The entire process takes seconds. And because it's software talking to software, it can run on a schedule—checking daily, renewing automatically when certificates approach expiration.

The Three Ways to Prove You Own a Domain

ACME gives you options for proving domain ownership:

HTTP-01: The CA gives you a token. You make that token available at http://yourdomain.com/.well-known/acme-challenge/TOKEN. The CA fetches the URL. If the token is there, you control the web server, so you probably control the domain.

This is the simplest method. It requires port 80 to be open. It doesn't work for wildcard certificates.

DNS-01: The CA gives you a token. You create a DNS TXT record containing that token. The CA queries DNS. If the record exists, you control DNS for the domain.

This is required for wildcard certificates. It's more complex because you need automated access to your DNS provider's API. But it works when HTTP isn't an option.

TLS-ALPN-01: The CA connects to your server on port 443 using a special TLS extension. Your server responds with a self-signed certificate containing the challenge token.

This exists for situations where port 80 is blocked but 443 is open. It's less common.

The Clients That Do the Work

Certbot is the official client from the Electronic Frontier Foundation. It's the default choice—well-documented, feature-rich, handles most web servers automatically.

acme.sh is a shell script. Minimal dependencies, works anywhere bash runs, supports dozens of DNS providers for DNS-01 challenges.

Caddy is a web server that handles certificates automatically. No separate client needed. Point it at your domain, it figures out the rest.

Traefik does the same for reverse proxies, especially popular in Docker and Kubernetes.

There are dozens more. The protocol is standardized, so clients proliferate.

Why 90-Day Certificates Are Actually Easier

Here's the counterintuitive truth: shorter certificate lifetimes with automation are less work than longer lifetimes with manual renewal.

With a yearly certificate, you have to remember to renew it. You have one chance to get it right. If something breaks, you're scrambling.

With ACME and 90-day certificates, your client checks daily and renews 30 days before expiration. That's 30 days of buffer. If renewal fails Monday, it tries again Tuesday. And Wednesday. You have a month to notice and fix problems. You're never scrambling at 2am because your certificate expired.

You stop thinking about certificates entirely. That's the point.

Testing Without Consequences

Let's Encrypt provides a staging environment that works exactly like production but issues certificates signed by a fake root. Browsers won't trust them, but that's fine—you're just testing.

This exists because even the people who built ACME knew you'd mess it up the first time. Misconfigure something, hit rate limits, break your site—do it on staging where it doesn't matter. Once everything works, point at production.

The staging server is at acme-staging-v02.api.letsencrypt.org. Use it.

Rate Limits Exist for Reasons

CAs implement rate limits to prevent abuse. Let's Encrypt allows 50 certificates per registered domain per week, 5 duplicate certificates per week, 300 accounts per IP per 3 hours.

These limits are generous for legitimate use. If you're hitting them, you're probably doing something wrong—testing on production instead of staging, or requesting duplicate certificates unnecessarily.

ACME Beyond Let's Encrypt

Let's Encrypt pioneered ACME, but they're not the only CA supporting it:

ZeroSSL offers free certificates via ACME, competing directly with Let's Encrypt.

Google Trust Services supports ACME for some certificate types.

Commercial CAs like SSL.com offer ACME access.

Private CAs: You can run your own ACME server using Boulder (Let's Encrypt's software) or step-ca for internal certificates.

The protocol's standardization matters here. Your Certbot installation doesn't care which CA it's talking to. Switch providers by changing a URL.

When Things Go Wrong

Most ACME failures come down to a few causes:

The CA can't reach your server: Firewall blocking port 80, DNS pointing to the wrong IP, or a CDN intercepting requests before they reach you.

DNS hasn't propagated: You created the TXT record but the CA's DNS resolver hasn't seen it yet. Wait a few minutes.

Permissions problems: The client can't write challenge files to your web root, or can't modify DNS via your provider's API.

Rate limits: You've been testing on production. Use staging.

ACME clients usually give you detailed error messages. Read them.