ACME is the protocol that lets a client prove it controls a domain and fetch a certificate with no human steps. To automate renewal safely, pick the right challenge type, renew at a fraction of lifetime, alert on failure, and keep a fallback for when the automation itself breaks.
What ACME does
RFC 8555 defines ACME as a protocol for a certification authority and an applicant to automate verification and issuance. The client generates a key pair and signs its requests with the private key. The CA asks the client to do something only the domain controller could do, then issues the certificate for the client to install. Revocation is supported too.
Choose the challenge type
ACME supports several challenge types, and the choice shapes your design.
- HTTP based challenge. The client serves a token on port 80 of the host. Simple for public web servers. It cannot validate wildcard names.
- DNS based challenge. The client publishes a TXT record. Needed for wildcard certificates, per Let's Encrypt. Also works for hosts that are not reachable from the internet. It requires DNS API access, which is itself a credential to protect.
- TLS ALPN based challenge. Validates on port 443 without touching port 80. Useful where only 443 is open.
I did not retrieve the section of RFC 8555 that defines each challenge in detail, so confirm specifics with your client's documentation.
Timing
Let's Encrypt's FAQ says 90 day certificates should be renewed every 60 days, and that routine renewals should run at random times to avoid traffic spikes. Its newer guidance recommends ACME Renewal Information where supported, and renewal at about two thirds of lifetime otherwise. With lifetimes shrinking, never hardcode a day count that assumes 90 days.
Checklist
- Use a maintained ACME client, not a script nobody owns.
- Run renewal on a timer at a fraction of lifetime with random jitter.
- Use a scoped DNS credential for DNS challenges that can only edit the validation record, not the whole zone.
- Store the ACME account key and certificate keys with tight permissions.
- Reload the service after renewal, and verify the new certificate is actually being served.
- Alert if a certificate's remaining life falls under a threshold, for example one third of lifetime.
- Alert on renewal failures, not just on expiry.
- Test in the CA's staging environment before changing production setup.
- Add CAA records limiting which CAs and accounts may issue. See CAA records explained.
- Write a runbook for emergency manual issuance.
Failure cases to plan for
- The renewal succeeded but the web server never reloaded.
- A firewall change blocked port 80 or the DNS API.
- A CDN or load balancer holds its own certificate and ignores yours.
- The DNS credential expired or was rotated.
- Rate limits during a mass reissue after an incident.
Quick check
Is a cron job running a renewal command enough?
Only with monitoring. A silent failure looks the same as success until the certificate expires.
Can I get a wildcard certificate with the HTTP challenge?
No. Let's Encrypt states wildcard issuance requires the DNS challenge.
Sources
- RFC 8555, Automatic Certificate Management Environment
- Let's Encrypt FAQ
- Let's Encrypt, From 90 to 45
Last reviewed: 19 October 2026.