JWS has an invalid anti-replay nonce: ..
dElogics opened this issue · comments
After creating an order (that has the challenges), if there's a gap of 5m or more between this step and a call to order.authorizations (in an attempt to ask the ACME server to verify the challenge), the following exception occurs --
Exception type JWS has an invalid anti-replay nonce: "0102IxVfNN7wbq6vkaiTxerxwL9yNPDz8gxsTo1sJBcqqUk" Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client/faraday_middleware.rb:54:in raise_on_error!'
Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client/faraday_middleware.rb:38:in on_complete' Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client/faraday_middleware.rb:23:in block in call'
Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/faraday-1.0.1/lib/faraday/response.rb:65:in on_complete' Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client/faraday_middleware.rb:23:in call'
Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/faraday-1.0.1/lib/faraday/rack_builder.rb:153:in build_response' Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/faraday-1.0.1/lib/faraday/connection.rb:492:in run_request'
Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/faraday-1.0.1/lib/faraday/connection.rb:279:in post' Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client.rb:265:in post_as_get'
Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client.rb:114:in order' Jun 11 13:22:41|/var/lib/gems/2.5.0/gems/acme-client-2.0.6/lib/acme/client/resources/order.rb:12:in reload'`
From what I found, it seems the JWS signatures have be regenerated.
Some time is needed after implementing the challenge for the challenge to propagate for DNS challenges. This explains the wait.
Might be a LE blip
This problem has gotten worst lately.
This doesn't seem like blip -- it's 100% reproducible. Wait for 5m between new_order and authorizations, and this comes up 100%.
Now it's reduced to 3m actually. DNS challenges take a lot of time to propagate/implement (possibly hours). 3m is not manageable in all situations.
I'm not sure if there is anything we can do from the client side for expiring nonce if you know your nonce is going to be expired you could clear them and fetch a new one before doing the request
Could the client detect that the nonce has (or is likely to have) expired, and automatically retry? At the very least, documenting how to "clear [the nonce] and fetch a new one before doing the request" would be very helpful.
Could the client detect that the nonce has (or is likely to have) expired, and automatically retry?
I think this is what would make the most sense too. I'll look into it.
At the very least, documenting how to "clear [the nonce] and fetch a new one before doing the request" would be very helpful.
I could add a method but I would have preferred to completely abstract this from the end user so they don't have to care about the underlying protocol.
There is still no clear mention of Nonce expiration in the spec. Given that this will be provider specific, I think its best to let the end user handle badNonce error themselves.
I would be open to add a client option to allow the end user to set expiration on them if that helpful to anyone.