# JWS has invalid anti-replay nonce **URL:** \ **Category:** Help\ **Created:** [May 8, 2019, 2:36pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100 "2019-05-08T14:36:34Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![ade](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ade/32/31717_2.png) [@ade](https://community.letsencrypt.org/u/ade)\ **Post date:** [May 8, 2019, 2:36pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/1 "2019-05-08T14:36:34Z")
We use Google DNS API to create DNS records and Let's Encrypt with AcmeSharp client to automate certificate generation. We did not change this part in our application but from 1 of May we are getting a lot of errors "JWS has invalid anti-replay nonce" on function call SubmitChallengeAnswer. We had delay time between DNS record creation and sending certificate request of 80 seconds. After changing this delay to 30 seconds, errors rate decreased from 60% to 7% but still it's big enough. Setting lower delay values leads to another error: > > Lets Encrypt authorization status 'invalid'. Authorization not completed. type : urn:acme:error:dns; detail : DNS problem: NXDOMAIN looking up TXT for \_[acme-challenge.topas.3cx.eu](http://acme-challenge.topas.3cx.eu/); status : 400 Before 1 of May we had less then 1% failed certificate requests. Retry on SubmitChallengeAnswer did not help much. My domain is: [activation.3cx.com](http://activation.3cx.com) I ran this command: ACMESharp.AcmeClient.SubmitChallengeAnswer(AuthorizationState authzState, String type, Boolean useRootUrl) It produced this output: Error status code: BadRequest, Error detail: { "Type": "urn:acme:error:badNonce", "Title": null, "Status": 400, "Detail": "JWS has invalid anti-replay nonce 4AYTyD85MM0vHP8QfVAVmQjgh0XpVm7KdZ16vPKY\_eQ", "Instance": null, "OrignalContent": "{\n "type": "urn:acme:error:badNonce",\n "detail": "JWS has invalid anti-replay nonce 4AYTyD85MM0vHP8QfVAVmQjgh0XpVm7KdZ16vPKY\_eQ",\n "status": 400\n}" My web server is (include version): IIS (Version 8.5.9600.16384) The operating system my web server runs on is (include version): Windows Server 2012 R2 (Version 6.2. Build 9200) My hosting provider, if applicable, is: OVH I can login to a root shell on my machine (yes or no, or I don't know): no I'm using a control panel to manage my site (no, or provide the name and version of the control panel): yes (MS IIS snap-in) The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): ACMESharp (version 0.8.1.0) ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [May 8, 2019, 10:29pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/2 "2019-05-08T22:29:21Z")
It seems that the incidence of badNonce errors has gone up recently, but it's not unexpected and not a fatal error. It should ideally be handled transparently by the ACMESharp library, by retrying any such request a limited number of times, with fresh nonces. If ACMESharp doesn't do this for you, it's up to your implementing code to handle that scenario. RFC8555 [writes](https://tools.ietf.org/html/rfc8555#section-6.5): > When a server rejects a request because its nonce value was > unacceptable (or not present), it MUST provide HTTP status code 400 > (Bad Request), and indicate the ACME error type > "urn:ietf:params:acme:error:badNonce". An error response with the > "badNonce" error type MUST include a Replay-Nonce header field with a > fresh nonce that the server will accept in a retry of the original > query (and possibly in other requests, according to the server's > nonce scoping policy). **On receiving such a response, a client SHOULD > retry the request using the new nonce.** > [@ade](#): > > Retry on SubmitChallengeAnswer did not help much. Really? Submitting the same request with the `Replay-Nonce` from the error response led to another badNonce error? ---
**Author:** ![ade](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ade/32/31717_2.png) [@ade](https://community.letsencrypt.org/u/ade)\ **Post date:** [May 9, 2019, 1:48pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/3 "2019-05-09T13:48:12Z")
Thank you, that helped. ---
**Author:** ![ade](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ade/32/31717_2.png) [@ade](https://community.letsencrypt.org/u/ade)\ **Post date:** [May 10, 2019, 6:59am UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/4 "2019-05-10T06:59:51Z")
Now we are getting from time to time “Lets Encrypt authorization status ‘invalid’. Authorization not completed. type : urn:acme:error:dns; detail : DNS problem: NXDOMAIN looking up TXT for \_acme-challenge.oslhk.3cx.hk; status : 400” Wait time between DNS creation and certificate generation is now 80 seconds. How to deal with this error? ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [May 10, 2019, 7:08am UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/5 "2019-05-10T07:08:29Z")
Are you waiting a flat 80 seconds, or is it 80 seconds after [the change status](https://cloud.google.com/dns/docs/reference/v1/changes#resource) goes from `pending` to `done`? If you look at [the way Certbot’s Google plugin does it](https://github.com/certbot/certbot/blob/d391fb8876dd97d5f446bcd1667ecdce0c4b187c/certbot-dns-google/certbot_dns_google/dns_google.py#L159-L162), it appears to wait 60 seconds (`default_propagation_seconds`) _after_ the change leaves the `pending` state. ---
**Author:** ![ade](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ade/32/31717_2.png) [@ade](https://community.letsencrypt.org/u/ade)\ **Post date:** [May 10, 2019, 8:05am UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/6 "2019-05-10T08:05:41Z")
As far as I can see we are not waiting DNS Change “done” status, we are resolving DNS entry from our side and then waiting 80 seconds. Ok, noted this. We also have some errors “type : urn:acme:error:dns; detail : DNS problem: query timed out looking up TXT for \_acme-challenge.rewind.3cx.co.uk; status : 400” and "Error status code: InternalServerError, Error detail: { “Type”: “urn:acme:error:serverInternal”, “Title”: null, “Status”: 500, “Detail”: “Problem getting authorization”, “Instance”: null, “OrignalContent”: “{\n “type”: “urn:acme:error:serverInternal”,\n “detail”: “Problem getting authorization”,\n “status”: 500\n}” Are they all of the same nature and could be healed waiting “done” status? ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [May 10, 2019, 9:09am UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/7 "2019-05-10T09:09:31Z")
Waiting for the `done` status (and then sleeping for e.g. 60s) is definitely worthwhile, because there might be things like clustering and anycast at play which can make a DNS resolution test (from your ACME client's perspective) unreliable. But: > [@ade](#): > > type : urn:acme:error:dns; detail : DNS problem: query timed out looking up TXT for \_acme-challenge.rewind.3cx.co.uk; status : 400 and > [@ade](#): > > “{\n “type”: “urn:acme:error:serverInternal”,\n “detail”: “Problem getting authorization”,\n “status”: 500\n}” are quite worrying. I wouldn't expect Google's Cloud DNS service to randomly time out. Seems more likely to be an issue on Let's Encrypt's side. At least, if it is happening on a regular basis. The `serverInternal` appears to be an database issue on Let's Encrypt's side, that you can do nothing about. If you have some order URLs related to these errors, you might want to tag some of the Let's Encrypt staff to look into them. There have been a couple of other threads recently with similar errors, without any explanation as of yet. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [May 10, 2019, 5:21pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/8 "2019-05-10T17:21:57Z")
We’ll take a look at the load issues / serverInternal errors. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [June 9, 2019, 5:28pm UTC](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce/93100/9 "2019-06-09T17:28:55Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.