ACME protocol
RFC 8555: the standard protocol for automating certificate issuance and renewal. The reason Let's Encrypt and other free CAs work without humans in the loop.
ACME (Automated Certificate Management Environment) is the protocol defined in RFC 8555 that lets a client automatically request, validate, and renew certificates from a Certificate Authority. Let's Encrypt was the first major CA to support it; today most modern CAs do.
What the protocol covers
- Account creation. Your client generates a key pair and registers an account with the CA.
- Order creation. You submit a request for a cert for one or more domains.
- Challenge. The CA responds with one or more challenges proving you control each domain.
- Challenge response. You publish proof (HTTP file, DNS TXT record, TLS-ALPN).
- Verification. The CA checks the proof.
- Finalization. You send a Certificate Signing Request; the CA returns the signed cert.
All of this is JSON over HTTPS. No human ever signs a form.
Challenge types
- HTTP-01. Put a file at
http://example.com/.well-known/acme-challenge/<token>. CA fetches and verifies. Doesn't work for wildcard certs. - DNS-01. Publish a TXT record at
_acme-challenge.example.com. CA looks it up. The only challenge type that supports wildcard certs. - TLS-ALPN-01. Serve a special cert on the same port via the TLS ALPN extension. Useful when you can't take the server down to swap configs.
Which client to use
For most SaaS deployments:
- Caddy. Built-in ACME, no config needed. Best for simple cases.
- acme.sh. Lightweight, runs anywhere, supports every challenge type.
- certbot. Official EFF client, well-tested, more verbose.
- Go's autocert / lego. For embedded use in Go services.
For a multi-tenant custom-domain pipeline, you usually don't write the client yourself; you delegate to a custom-domain API that handles it.