[IO: Retry Overhead] ACME transient retries resend the same signed nonce #128

Severity: Low
Classification: Confirmed retry construction; extra failures depend on whether the CA consumed the nonce.

Locations

/home/runner/work/BackFiller/BackFiller/src/BackFiller/Acme/Protocol/AcmeHttpTransport.cs:128–141
/home/runner/work/BackFiller/BackFiller/src/BackFiller/Acme/Protocol/AcmeHttpTransport.cs:294–318,347–357
Code

C#
string nonce = await TakeNonceAsync(cancellationToken).ConfigureAwait(false);
string jws = JsonWebSignature.Encode(key, url, nonce, keyId, payload);

try
{
return await SendWithRetryAsync(() => CreateJwsRequest(url, jws, accept: null), typeInfo, cancellationToken)
.ConfigureAwait(false);
}
The inner retry loop reconstructs only the HTTP request:

C#
using HttpRequestMessage request = requestFactory();
Description

Transient retries reuse the exact JWS, including its replay nonce. If the CA consumed that nonce before returning an error or losing the response, the subsequent submission can predictably receive badNonce.

The outer loop eventually signs again, so this is not necessarily a terminal failure. It adds avoidable requests and combines separate transient and nonce retry budgets during an outage.

Blindly signing a fresh retry is not sufficient for every operation: a lost response to a state-changing request also creates uncertainty about whether that operation completed.

Recommendation

Make retry policy aware of signed-request and operation semantics. Rebuild eligible retries with an appropriate fresh nonce, and handle uncertain state-changing outcomes separately from safe resource reads. Bound total attempts across both retry layers.

Validation

Use a scripted CA that consumes a nonce and then returns a transient failure. Verify nonce behavior, total request count, and handling of uncertain newOrder outcomes.