Certificates & Site Ops · Field note
ACME in plain English: account keys, challenges, orders, and renewal state
A plain-language ACME guide that explains what your Let’s Encrypt tooling is actually doing during issuance and renewal.
Before you start
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
ACME often feels like magic because tools hide the protocol steps. That is convenient until issuance or renewal fails and the logs start talking about authorizations, orders, and account keys as if everyone already thinks that way.
The useful goal is not to memorize the whole RFC. It is to know which moving part you are looking at when something breaks.
In brief
What it is: ACME is the protocol used by a CA and a client to automate domain validation, certificate issuance, renewal, and related certificate-management actions.
Why it matters: Understanding the protocol shape makes challenge failures and renewal incidents much easier to interpret.
Watch for: Many admins treat ACME errors as generic “Let’s Encrypt problems” when the real issue is one specific failed challenge or stale authorization step.
The smallest useful model of ACME
The client has an account key. It asks for an order. The CA returns authorizations and challenges tied to the requested identifiers. The client completes a challenge to prove control, finalizes the order, and receives a certificate. That is the loop at a level most operators can keep in their head.
Renewal is not a new mystery; it is the same shape repeated over time with its own state and timing.
Why challenge failures are actually helpful
Challenge failures tell you where control proof broke. HTTP-01 usually points to routing, content, or reachability. DNS-01 usually points to record placement, propagation, or automation delays. Once you stop calling it “a certificate issue” and start calling it “a challenge issue,” the next action gets smaller.
- Account key: identifies the ACME client account.
- Order: request for certificate issuance.
- Authorization and challenge: proof you control the identifier.
- Finalize: last step before issuance.
Renewal state matters more than one successful issuance
A site that issued correctly once can still fail later if automation changes, DNS access breaks, or HTTP validation paths drift. Renewal is a workflow, not a checkbox. That is why a command generator or guide is most valuable when it surfaces the assumptions the automation needs to keep working.
See it in a small example
Notice: When a renewal fails, identify which step stopped advancing. That is usually more actionable than reading the entire log chronologically.
account -> order -> authorization/challenge -> finalize -> certificate
What to verify
- Write down which challenge type your renewal depends on.
- Treat challenge errors as specific control-proof failures, not generic CA failures.
- Review renewal assumptions after infrastructure or DNS changes, not only when certificates expire.
Common questions
Does ACME always use HTTP-01?
No. HTTP-01 and DNS-01 are common, but the protocol supports challenge-based validation flows more broadly.
If issuance worked once, am I done?
No. Renewal depends on the same proof-of-control assumptions continuing to hold.