We created new account for every certification, but we can just save account's info and use it without creating new
return ACME.accounts.create(options).then((account) => {
return ACME.certificates.create(options).then((fullchainPem) => {
There is a theoretical issue with stale nonces which I haven’t personally had cause failure in production, but I will be pushing the change just in case it’s related.
It’s part of a batch of work to update to the new draft 15 specification and to add ECDSA support, so it may still be a week before it’s fully tested and ready to release.
However, it sounds like you have a solution for your problem and it may not be related anyway.
There is a theoretical issue with stale nonces which I haven’t personally had cause failure in production, but I will be pushing the change just in case it’s related.
It’s part of a batch of work to update to the new draft 15 specification and to add ECDSA support, so it may still be a week before it’s fully tested and ready to release.
However, it sounds like you have a solution for your problem and it may not be related anyway.
Actually, we have another error with JWS after disabling account creation
[acme-v2.js] authorizations were not fetched for
'http://.com,http://www..com':
{"type":"urn:ietf:params:acme:error:badNonce","detail":"JWS has an invalid anti-
replay nonce: "599TSqH-ILiu1Og_IcDwn3D3rIbta1N8D_-z8ZehfTw"","status":400}
Actually, we have another error with JWS after disabling account creation
[acme-v2.js] authorizations were not fetched for
'http://***.com,http://www.***.com':
{"type":"urn:ietf:params:acme:error:badNonce","detail":"JWS has an invalid anti-
replay nonce: \"599TSqH-ILiu1Og_IcDwn3D3rIbta1N8D_-z8ZehfTw\"","status":400}
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 with a fresh
nonce. On receiving such a response, a client SHOULD retry the
request using the new nonce.
Maybe add retry (by spec) ?
https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.4
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 with a fresh
nonce. On receiving such a response, a client SHOULD retry the
request using the new nonce.
I just completed a body of work in which I discovered what I believe to be the root cause.
I'll see if I can add a retry feature to that and then I need to find a way to keep backwards compatibility before I deploy the fixes.
If you have the time and are willing to help, hit me up on Keybase. I'm @coolaj86 there and we're in the rootprojects group.
Indeed.
I just completed a body of work in which I discovered what I believe to be the root cause.
I'll see if I can add a retry feature to that and then I need to find a way to keep backwards compatibility before I deploy the fixes.
If you have the time and are willing to help, hit me up on Keybase. I'm @coolaj86 there and we're in the `rootprojects` group.
Hi. We often have this error. Is there any way to solve/debug it ?
P.S.: Usually there are no problem if you just run certification again.
P.P.S: seems like 1st error from here https://git.coolaj86.com/coolaj86/acme-v2.js/issues/17
account error: {"termsOfServiceAgreed":true,"onlyReturnExisting":false,"contact":["mailto:...@..."]}
{ statusCode: 400,
body:
{ type: 'urn:ietf:params:acme:error:badNonce',
detail:
'JWS has an invalid anti-replay nonce: "0xFdX3cS0nUwRWOV3nl5eCV8dBwZMjR7cU6S-x5Mpl8"',
status: 400 },
headers:
{ server: 'nginx',
'content-type': 'application/problem+json',
'content-length': '169',
link:
'https://acme-v02.api.letsencrypt.org/directory;rel="index"',
'replay-nonce': 'i25W9Abj8mOe9NdvK5EyR0XHov0eubWkIcT_6nA4_ts',
expires: 'Fri, 03 May 2019 14:51:08 GMT',
'cache-control': 'max-age=0, no-cache, no-store',
pragma: 'no-cache',
date: 'Fri, 03 May 2019 14:51:08 GMT',
connection: 'close' },
request:
{ uri:
Url {
protocol: 'https:',
slashes: true,
auth: null,
host: 'acme-v02.api.letsencrypt.org',
port: null,
hostname: 'acme-v02.api.letsencrypt.org',
hash: null,
search: null,
query: null,
pathname: '/acme/new-acct',
path: '/acme/new-acct',
href: 'https://acme-v02.api.letsencrypt.org/acme/new-acct' },
method: 'POST',
headers:
{ 'Content-Type': 'application/jose+json',
'Content-Length': 1212 } } }
Invilid jws为 Invalid jwsHm, seems like we have found the reason for our case. Just wait a little for test
We created new account for every certification, but we can just save account's info and use it without creating new
There is a theoretical issue with stale nonces which I haven’t personally had cause failure in production, but I will be pushing the change just in case it’s related.
It’s part of a batch of work to update to the new draft 15 specification and to add ECDSA support, so it may still be a week before it’s fully tested and ready to release.
However, it sounds like you have a solution for your problem and it may not be related anyway.
Actually, we have another error with JWS after disabling account creation
[acme-v2.js] authorizations were not fetched for
'http://.com,http://www..com':
{"type":"urn:ietf:params:acme:error:badNonce","detail":"JWS has an invalid anti-
replay nonce: "599TSqH-ILiu1Og_IcDwn3D3rIbta1N8D_-z8ZehfTw"","status":400}
Maybe add retry (by spec) ?
https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.4
Indeed.
I just completed a body of work in which I discovered what I believe to be the root cause.
I'll see if I can add a retry feature to that and then I need to find a way to keep backwards compatibility before I deploy the fixes.
If you have the time and are willing to help, hit me up on Keybase. I'm @coolaj86 there and we're in the
rootprojectsgroup.Fixed in v3