acmez

Fixes #63 fails with when the server is not ready to finalize at that moment, e.g. with asynchronous finalization (Let's Encrypt Staging). RFC 8555 §7.4 makes the order status the source of truth for the next action: means POST-as-GET the order, means submit a finalization request. now follows that: it refreshes the order after and re-submits the CSR while the order is . The first request is always a finalize request, even when the caller's cached status is stale. bounds only the polling that follows it. Note the behavior change: is no longer fatal. Against a server that keeps answering , the client re-submits the CSR every poll until elapses, relying on server-side idempotency. Tested with , including the Pebble integration tests ( covers the stale cached-status path).

When finalizing an order against a server that uses asynchronous finalization (e.g. Let's Encrypt Staging), can fail with: RFC 8555 §7.4: A request to finalize an order will result in error if the order is not in the "ready" state. In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "orderNotReady". The client should then send a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take (see below). For the order object returned by a successful finalize: "ready": The server agrees that the requirements have been fulfilled, and is awaiting finalization. Submit a finalization request. Current behavior in : 1. When finalize returns , the error is ignored but the order is never refreshed with a POST-as-GET, as §7.4 requires. Because returns early for without decoding the body into the , the local order remains the stale object. 2. treats as terminal and returns an error, so finalization aborts instead of re-submitting the finalize request. I'd be happy to open a PR for this.

Summary treats a failed alternate chain download as fatal, and on failure returns — discarding the primary chain it already downloaded successfully. Per RFC 8555 §7.4.2 alternates are optional, so an advertised-but-unavailable alternate should not fail the whole issuance. This is currently reachable against Let's Encrypt production: during the ongoing YE/YR intermediate rollout, LE intermittently advertises a whose URL then answers . Impact The order is finalized and the certificate is issued — validation has already succeeded and the primary chain has already been fetched — but the client throws it away and reports failure. The caller then retries from scratch, burning a fresh order and a Let's Encrypt issuance quota slot each time, for a certificate that was already sitting in memory. Observed via Caddy 2.11.4 (acmez v3.1.6) obtaining a wildcard over DNS-01: Because it is intermittent, a subsequent retry usually succeeds — which makes this show up as random, unexplained issuance/renewal failures rather than a hard break. lego users are hitting the same LE behaviour (DirectAdmin forum thread). Root cause , in (v3.1.6): Two problems: 1. A failed alternate aborts the call, even though the spec says the server "MAY" provide alternates and "Clients can fetch these alternates and use their own heuristics to decide which is optimal." 2. It returns rather than , so the primary chain — already validated and downloaded — is lost. Note the primary-chain error path just above deliberately returns . Suggested fix Skip an alternate that cannot be retrieved and keep going. appends before it can fail on a nested fetch, so the partial entry needs rolling back: This preserves existing behaviour whenever alternates are healthy, and degrades to "use the chains we could actually get" when they are not. Callers that require a specific chain already express that through their own preference logic over the returned slice, and are free to reject the result if their preferred chain is absent. I am running this patch against LE production and it behaves as expected. Happy to send it as a PR, with a test covering the 404-on-advertised-alternate case, if the approach looks right. Versions acmez v3.1.6 Go 1.27.1, linux/amd64 CA: Let's Encrypt production ()