In ACME, which steps run between creating a new order for a DNS name and downloading the issued certificate chain?

juniormust knowfreq 62%

answer

one order, one authorization per name
prove control before anything is signed
ready comes before finalize
issuance is asynchronous, so poll
chain fetched from its own URL

basics

~20 s

An ACME order for a DNS name becomes one authorization per identifier; the client completes one challenge in each, the server validates it, then the client posts a certification request to the order's finalize URL and downloads the chain.

solid answer

~40 s

The client POSTs to newOrder with a list of identifiers and gets back an order in pending plus one authorization URL per identifier. Each authorization offers challenge types; the client provisions the answer for one of them and tells the server to validate it. When every authorization is valid the order moves to ready, and the client POSTs a certification request to the order's finalize URL. Issuance is asynchronous, so the order sits in processing until it becomes valid and carries a certificate URL. Fetching that URL returns the end-entity certificate and its issuing intermediate as application/pem-certificate-chain. Nothing in that flow installs anything — deployment is the operator's job.

The client POSTs to `newOrder` with a list of identifiers and gets back an order in `pending` plus one authorization URL per identifier. Each authorization offers challenge types; the client provisions the answer for one of them and tells the server to validate it. When every authorization is `valid` the order moves to `ready`, and the client POSTs a certification request to the order's `finalize` URL. Issuance is asynchronous, so the order sits in `processing` until it becomes `valid` and carries a `certificate` URL. Fetching that URL returns the end-entity certificate and its issuing intermediate as `application/pem-certificate-chain`. Nothing in that flow installs anything — deployment is the operator's job.

code

http · 17 lines

http

POST /acme/new-order HTTP/1.1
Host: acme.ca.example
Content-Type: application/jose+json

{"protected": "...", "payload": "...", "signature": "..."}

HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA
Location: https://acme.ca.example/acme/order/1/8

{
  "status": "pending",
  "identifiers": [{"type": "dns", "value": "popup-camden.shop.example"}],
  "authorizations": ["https://acme.ca.example/acme/authz/1/42"],
  "finalize": "https://acme.ca.example/acme/order/1/8/finalize"
}

go deeper

for a junior

Recall the sequence and the vocabulary: account, order, authorization, challenge, finalize, certificate. Being able to name the step where a run stopped is most of the value here.

for a middle

Explain why the order has both a ready state and a processing state, and why the chain arrives from its own URL. Know that one authorization exists per identifier.

for a senior

Show that you read the stalled state rather than the exit code — an authorization stuck invalid and an order stuck processing are different incidents with different owners.

for a principal

Frame issuance and deployment as two separate systems with one contract between them, and decide where that handoff is monitored so a healthy issuance job cannot mask a stale served certificate.

The objects

directory — the one URL a client is configured with. It is a JSON object whose fields are the URLs of the other resources: newNonce, newAccount, newOrder, revokeCert, keyChange, and newAuthz only where the server offers pre-authorization. The directory and newNonce are what a client can always count on; the rest are conditional on what that server supports, so a client reads the directory rather than hardcoding paths.
account — created once at newAccount. It carries contact details and agreement to the authority's terms, and every later request is signed by its key pair.
order — one request for one certificate, listing identifiers such as {"type": "dns", "value": "popup-camden.shop.example"}.
authorization — the server's record that this account may be issued certificates for one identifier. An order for three names produces three authorizations.
challenge — inside an authorization, the concrete task that proves control: publishing a file over HTTP, a DNS record, or a certificate in a dedicated TLS handshake.

The exchange, step by step

Fetch the directory and take a nonce from newNonce.
POST to newAccount to create or look up the account; the Location header of that response is the account URL used to identify the account afterwards.
POST to newOrder with the identifiers. The response is an order in pending with an authorizations array and a finalize URL.
For each authorization, choose one of the offered challenge types and provision what it asks for.
POST to that challenge's URL to say it is ready. The server validates out of band and the authorization becomes valid (or invalid, and the order dies with it).
When all authorizations are valid the order becomes ready. POST a certification request to finalize.
Poll the order until it is valid, then fetch its certificate URL. The body is the end-entity certificate followed by the intermediate needed to build a path, typed application/pem-certificate-chain.

The states you will actually see

Object	Status	What it means
order	`pending`	at least one authorization is not yet valid
order	`ready`	every authorization is valid; waiting for `finalize`
order	`processing`	the request was accepted and the authority is issuing
order	`valid`	the `certificate` URL is populated
order	`invalid`	an authorization failed or issuance was refused
authorization	`pending` / `valid` / `invalid`	control not yet proven / proven / refused
challenge	`pending` / `processing` / `valid` / `invalid`	queued / being checked / passed / failed

A client that reports "the order failed" without naming the state it stalled in has thrown away the only diagnostic the protocol gives it.

What the flow deliberately does not do

It does not generate the key pair being certified, and it does not touch it apart from the certification request submitted at finalize.
It does not install or reload anything. Issuance and deployment are separate, and the gap between them is where most "but renewal ran fine" outages live.
It proves control of a name, at the moment of validation, and nothing about the organisation behind that name.
There is no renewal verb. Renewing is placing a new order for the same identifiers.

Why the shape matters

A chain of pop-up stores that opens a site for six weeks under its own name gets a certificate this way with nobody involved: the deploy job places an order, answers a challenge, collects a chain and moves on. The same shape is what lets the whole thing fail silently — an authorization that goes invalid because a name now points somewhere else produces no expired certificate today, only a job that quietly stops succeeding. Knowing which state the flow stops in is the difference between a fix and a guess.

ACME (RFC 8555) is the protocol a client speaks to a certificate authority when no human is in the loop: it asks for a certificate covering one or more names, proves control of each of those names, and collects the result. It is worth learning as a small set of objects and the order in which they change state, because almost every operational failure is a stall at one specific state. ## The objects - **directory** — the one URL a client is configured with. It is a JSON object whose fields are the URLs of the other resources: `newNonce`, `newAccount`, `newOrder`, `revokeCert`, `keyChange`, and `newAuthz` only where the server offers pre-authorization. The directory and `newNonce` are what a client can always count on; the rest are conditional on what that server supports, so a client reads the directory rather than hardcoding paths. - **account** — created once at `newAccount`. It carries contact details and agreement to the authority's terms, and every later request is signed by its key pair. - **order** — one request for one certificate, listing **identifiers** such as `{"type": "dns", "value": "popup-camden.shop.example"}`. - **authorization** — the server's record that this account may be issued certificates for one identifier. An order for three names produces three authorizations. - **challenge** — inside an authorization, the concrete task that proves control: publishing a file over HTTP, a DNS record, or a certificate in a dedicated TLS handshake. ## The exchange, step by step 1. Fetch the **directory** and take a nonce from `newNonce`. 2. POST to `newAccount` to create or look up the account; the `Location` header of that response is the account URL used to identify the account afterwards. 3. POST to `newOrder` with the identifiers. The response is an order in `pending` with an `authorizations` array and a `finalize` URL. 4. For each authorization, choose **one** of the offered challenge types and provision what it asks for. 5. POST to that challenge's URL to say it is ready. The server validates out of band and the authorization becomes `valid` (or `invalid`, and the order dies with it). 6. When all authorizations are `valid` the order becomes `ready`. POST a certification request to `finalize`. 7. Poll the order until it is `valid`, then fetch its `certificate` URL. The body is the end-entity certificate followed by the intermediate needed to build a path, typed `application/pem-certificate-chain`. ## The states you will actually see | Object | Status | What it means | |---|---|---| | order | `pending` | at least one authorization is not yet valid | | order | `ready` | every authorization is valid; waiting for `finalize` | | order | `processing` | the request was accepted and the authority is issuing | | order | `valid` | the `certificate` URL is populated | | order | `invalid` | an authorization failed or issuance was refused | | authorization | `pending` / `valid` / `invalid` | control not yet proven / proven / refused | | challenge | `pending` / `processing` / `valid` / `invalid` | queued / being checked / passed / failed | A client that reports "the order failed" without naming the state it stalled in has thrown away the only diagnostic the protocol gives it. ## What the flow deliberately does not do - It does not generate the key pair being certified, and it does not touch it apart from the certification request submitted at `finalize`. - It does not install or reload anything. Issuance and deployment are separate, and the gap between them is where most "but renewal ran fine" outages live. - It proves **control of a name**, at the moment of validation, and nothing about the organisation behind that name. - There is no renewal verb. Renewing is placing a new order for the same identifiers. ## Why the shape matters A chain of pop-up stores that opens a site for six weeks under its own name gets a certificate this way with nobody involved: the deploy job places an order, answers a challenge, collects a chain and moves on. The same shape is what lets the whole thing fail silently — an authorization that goes `invalid` because a name now points somewhere else produces no expired certificate today, only a job that quietly stops succeeding. Knowing which state the flow stops in is the difference between a fix and a guess.

Which resources can a client always expect to find in an ACME server's directory object?
The directory itself is the configured entry point, and `newNonce` is the resource every signed request depends on, so those two are the fixed points. `newAccount`, `newOrder`, `revokeCert` and `keyChange` are advertised by servers that offer them, and `newAuthz` appears only where the server supports pre-authorization. A client reads the directory each run rather than assuming a path.
Why is the issued chain fetched from a separate URL instead of returned in the finalize response?
Because issuance is asynchronous. The finalize response returns the order in `processing`; the authority may be logging the certificate, waiting on an internal signer, or queueing. The client polls the order until it is `valid`, at which point the order carries a `certificate` URL. Fetching it as a signed POST with an empty payload keeps the request authenticated rather than leaving the chain on an open URL.
An order covering four names reaches ready. How many challenges were completed?
Four at most, one per authorization, and possibly fewer. Each identifier gets its own authorization, and each authorization needs exactly one of its offered challenges to succeed. A server may also carry an authorization that is already `valid` from a recent order for the same name, in which case no new challenge runs for it at all.

saying these in an interview costs you the question

Thinks one challenge covers every name in a multi-name order
Expects the certificate in the finalize response body
Believes finalize runs before the challenges
Assumes issuance is synchronous with no processing state
Says ACME installs and reloads the certificate for you

In ACME, which steps run between creating a new order for a DNS name and downloading the issued certificate chain?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The objects

The exchange, step by step

The states you will actually see

What the flow deliberately does not do

Why the shape matters

▾common follow-ups3 questions

▾red flags5 flags

The objects

The exchange, step by step

The states you will actually see

What the flow deliberately does not do

Why the shape matters

answer

go deeper