JWS has invalid anti-replay nonce (using LetsEncryptSimple aka WinSimple)

[RedFeet]

My domain is:
zuidkolk.nl

I ran this command:
letsencrypt.exe --san

It produced this output:
Authorizing Identifier dezuidkolk.nl Using Challenge Type http-01
Unexpected error
ACME Server Returned:
{
“type”: “urn:acme:error:badNonce”,
“detail”: “JWS has invalid anti-replay nonce oFrxrsYCvfaVWtPbt0IK_RRtJcShF0F1K6QoCL2EqKk”,
“status”: 400
}

My web server is (include version):
IIS 10.0.14393.0

The operating system my web server runs on is (include version):
Windows Server 2016

My hosting provider, if applicable, is:
TransIP.net BladeServer

I can login to a root shell on my machine (yes or no, or I don’t know):
Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No

[cpu]

@RedFeet

{

“type”: “urn:acme:error:badNonce”,

“detail”: “JWS has invalid anti-replay nonce oFrxrsYCvfaVWtPbt0IK_RRtJcShF0F1K6QoCL2EqKk”,

“status”: 400

}

@WouterTinus - Does LEWS retry requests on bad nonce errors? Do you know of any conditions that might cause bad nonce errors that aren't retried?

Thanks!

[RedFeet]

Thanks @cpu, for replying.

I don’t know exactly what you mean, but I retried manually. (I mean, I ran the exact same command line command again.)
And this time the (san) certificate got renewed without any problems…

Thank you for triggering me to retry it

Have a nice day,
Tune

[cpu]

@RedFeet

I don’t know exactly what you mean, but I retried manually. (I mean, I ran the exact same command line command again.)

And this time the (san) certificate got renewed without any problems…

Thank you for triggering me to retry it

Hi @RedFeet,

Happy to help

I'm glad that you were able to solve the problem by retrying manually. I flagged @WouterTinus because he's the developer of the Let's Encrypt Win Simple program. Ideally that program would automatically retry when it sees this error so that you wouldn't have to

[WouterTinus]

In my experience this happens when there is too much time between the
initialization of an AcmeClient object and its eventual use to call the
Let’s Encrypt API. For example when the user spends several minutes idle in
the menu. In the upcoming release (currently in beta) the AcmeClient has a
much shorter lifetime and is only created after all the user input has been
gathered, so it shouldn’t be a problem anymore.

[cpu]

@WouterTinus

In my experience this happens when there is too much time between the initialization of an AcmeClient object and its eventual use to call the Let’s Encrypt API.

You're correct, that's definitely one reason that a bad nonce error can happen. I'm happy to hear LEWS will try to reduce the lifetime between when a nonce is retrieved vs used. That should help with this case as you suggest.

Have you considered allowing retries for badNonce errors anyway? It's possible that they could occur for reasons other than aging out. The ACME specification says the following:

An error response with the "badNonce" error type MUST include a Replay-Nonce header with a fresh nonce. On receiving such a response, a client SHOULD retry the request using the new nonce.

Thanks for chiming in @WouterTinus! I appreciate it!

[WouterTinus]

@cpu I think that’s a great idea, though I feel that such a change would be best at home in the ACMESharp library which LEWS and some other .NET-based tools are built on, so that they all benefit. That’s not to say I wouldn’t to a PR to Eugene Bekker though.

[cpu]

@WouterTinus

@cpu I think that’s a great idea, though I feel that such a change would be best at home in the ACMESharp library which LEWS and some other .NET-based tools are built on, so that they all benefit.

Aha! Apologies, I forgot that LEWS builds on another ACME library. I agree with you that this is a change better suited for the ACME layer

@WouterTinus

That’s not to say I wouldn’t to a PR to Eugene Bekker though.

That would be great! Even opening an issue suggesting it as an idea would be a good start. Thanks Wouter!