Should auto-recover from bad nonces

[jsha]

I recently got this error trying to issue a cert:

The client sent an unacceptable anti-replay nonce :: JWS has invalid anti-replay nonce

This happens from time to time - the server loses track of outstanding nonces. Since the reply always includes a fresh nonce, the client should auto-retry the request.

[joohoi]

I got this error several times today as well, all the errors were from the production server, staging was working fine. Might be something to do with loads, however as noted, it's trivial to implement retry on client side.

[rezaalavi]

I am getting the same error and retry doesn't solve the problem.
Unfortunately few retries also makes it that the domain hits the certificate limit and now we have to wait 7 days.

We offer this to all our client and now we are worried we are going to have serious issues comes the renewal date.

[rezaalavi]

Ok here is out this finally worked for me, We have to repeat the new certificate step and use the nonce that is sent back with "jws invalid nonce" to get the certificate issued.
Otherwise if we go through the whole process again it always fails.

There must be a new bug on the server side making resulting in this but overall because of the workaround it is not a show stopper.

[kuba]

BTW, @rezaalavi your comment suggests your developing alternative client. This repo (and this bug) is for the official client implementation.

[chriscroome]

FWIW I just got this error, updated the letsencrypt code and then stopped getting it.

[wichtounet]

I was also encountering this error and after update of the Gentoo package and it worked!

[elblaf]

I've been hit by that invalid anti-replay nonce problem for my use case (DNS challenge, where I had to wait up to half an hour before the challenge value is published by my DNS provider).

The first time, it was with the staging environment, but it did not reproduced afterwards. I was then hit numerous time with the production environment, so I followed Jacob's suggestion and make the client retries POSTs on badNonce errors.

Attached is the patch (against certbot-0.9.3, the version I use) I've extracted from my deployment of certbot:

cerbot-acme-clientpy.patch.txt

I'm not a pythonist, so it may not be nice python code: maybe one can clean this attempt and make a pull request from it?

edit: typo in jsha's first name, sorry.

[bmw]

Just out of my curiosity, what stops boulder from keeping track of nonces making this a problem that has to be solved by the different ACME clients?

[jsha]

Many nonces go unused, which means we have to expire them after a while. More importantly, we currently keep track of nonces per-frontend and therefore per-DC. When we switch traffic between DCs, any inflight sessions will get badNonce errors.

[bmw]

Because there is no limit how long it can take to perform a challenge when using the manual plugin, I'm bumping the priority of this issue. Due to how long it can take for DNS changes to propagate, this problem makes using Certbot with the DNS challenge impossible in some cases (see #4099).

[elblaf]

Attached is an updated version of my previous patch (against 49d46ef, and with a more idiomatic way to propagate the raised exception when max number of attempts is reached):

cerbot-acme-clientpy-v2.patch.txt
cerbot-acme-clientpy-v2-proper-urn.patch.txt

As a workaround, should be appliable against published v0.10.0 and v0.10.1.

Edit: the URN prefix for acme errors has changed ("urn:ietf:params:acme:error:" instead of "urn:acme:error:"); updated patch.