What's all that account settings? How much does it matter?

First things first, my name is tim and i'm a linux amateur approaching 50 years of age. My web server is hosting 5 domains with letsencrypt certificates. Most of it is running for several years (5-ish, i guess) and renewed certs with certbot successfully.

Recently the renewal stopped working. Digging into the certbot configuration and logs, it turns out that letsenrypt denies existence of my account and thus won't renew.

I possibly slaughtered parts of the configuration, but restored the account bits from backups. However it didn't help much; either the certbot daemon wouldn't start or certs expired or both.

Is there any documentation about accounts and their counterparts in the letsencrypt.org topology?


1 Like

Usually, certbot will handle account stuff rather gracefully. For example, in a test environment just now, I removed the account from the /accounts/ directory and tried to renew a certificate: certbot just registered a new account and updated the configuration of the renewing certificate with the new account data. That said, sometimes that's not what you want, possibly due to rate limit overrides coupled to the existing account or perhaps the ECDSA beta or something.

I think to help you properly, we'd need to see what the exact issue is you're running into and have some more information. I'm also going to move your thread to the #help section of this Community, as I believe that's more appropriate. In the #help section, you would have been provided with the questionnaire which I'm going to copy/paste below. Please answer all the questions to the best of your knowledge and if you don't know the answer, please use that as the answer instead of leaving it blank.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):


Hello! Thanks for replying!
Short version:
The state i'm in right now is this: I've successfully requested and installed fresh certs for all domains using a new account. The certbot daemon seems to be running fine, no more errors logged. For now there's no obvious problem any more.
However i tried to figure out what stopped the certs from renewing. A point of failure concerning DNS was that my old _acme-challenge entries were CNAME records whereas they need to be TXT records now (which i fixed). I'm not sure if this might have caused the JWS errors. (Probably the account issues were caused by my attempts to restore account data from backups.).
My domain is (among others) wackerton.de (last attempt was successful since i started from scratch)

Long report along with (possibly unrelated) log output:
I ran this command: certbot certonly --manual -d wackerton.de -d *.wackerton.de

It produced this output:
Account at /etc/letsencrypt/accounts/acme-staging.api.letsencrypt.org/directory/a403828395... does not exist

Meanwhile i figured out that test-certs are issued from acme-staging.api.letsencrypt.org where apparently no accounts are stored, so the "account not found" error is sorted out.
Main issue was The request message was malformed :: JWS verification error, see log output below.

My web server: Apache 2.4.48

OS: Debian Linux "bullseye" (published a few days ago)

No hosting provider, no web interface in terms of plesk or whatever - only root shell

Certbot version: 1.12.0

excerpt from /var/log/letsencrypt/letsencrypt.log:

2021-08-30 07:59:56,855:INFO:certbot._internal.auth_handler:Waiting for verification...
2021-08-30 07:59:56,856:DEBUG:acme.client:JWS payload:
2021-08-30 07:59:56,865:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/chall-v3/26359248670/_IL3ew:
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTgwMzU0NzQwIiwgIm5vbmNlIjogIjAxMDFQUUpCdnd0S25uem8xZGxTT3VrVzF5VVkyTFdmQ2I0d3RWQ0RtWlc1MGx3IiwgInVybCI6ICJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9jaGFsbC12My8yNjM1OTI0ODY3MC9fSUwzZXcifQ",
  "signature": "RlVp7zVPfp2B-FJaYzqxuzngFzHRjPbKEwFoynePeW6vQ4SnqdwOP4xMzeY0MXMhpNzi-XQVuyJhsZg77K-0uam8GyHeFbkJGFTASKyIU6UKNQMoJtJvetYIeoEdEXxV8tQnHQ9ica4aSmIRknWLOyQ4IBdNLdj2c6EZIST8beJLlCUkh6zupFmK7bHQU3FJzjZQFalRKrixPJ_0PM7fcZyoCfjLPujQP2cwHtMPf9Crjn0S8mR5f2rQ05R64V4D3cHV7a_qzK0jCu5SfDltjQefDD3KSJMJ1Br6ai-7QFjy9Zhel0_kRdyEYVdNTJ1evfra38LwWhDcJoRAo7kTOg",
  "payload": "e30"
2021-08-30 07:59:57,031:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/chall-v3/26359248670/_IL3ew HTTP/1.1" 400 173
2021-08-30 07:59:57,032:DEBUG:acme.client:Received response:
HTTP 400
Server: nginx
Date: Mon, 30 Aug 2021 05:59:56 GMT
Content-Type: application/problem+json
Content-Length: 173
Connection: keep-alive
Boulder-Requester: 180354740
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 01027c07pAxuPxXBNW7n19AIYIhCI4sDqBYvqimR2KkCnRQ

  "type": "urn:ietf:params:acme:error:badNonce",
  "detail": "JWS has an invalid anti-replay nonce: \"0101PQJBvwtKnnzo1dlSOukW1yUY2LWfCb4wtVCDmZW50lw\"",
  "status": 400
2021-08-30 07:59:57,032:DEBUG:acme.client:Retrying request after error:
urn:ietf:params:acme:error:badNonce :: The client sent an unacceptable anti-replay nonce :: JWS has an invalid anti-replay nonce: "0101PQJBvwtKnnzo1dlSOukW1yUY2LWfCb4wtVCDmZW50lw"
2021-08-30 07:59:57,032:DEBUG:acme.client:Requesting fresh nonce
2021-08-30 07:59:57,032:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce.
2021-08-30 07:59:57,164:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "HEAD /acme/new-nonce HTTP/1.1" 200 0
2021-08-30 07:59:57,165:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Mon, 30 Aug 2021 05:59:57 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0101bClPLnvSEJmDylr7H7ysxT769W8c0z5vNof1eZhNB98
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

Thanks for reading this far,

1 Like

It should be possible to use CNAME records for the DNS challenge: that's the premise acme-dns is based upon. However, not every DNS plugin can handle CNAME records properly, so it might have been your issue.. Or might not have been.

The URL acme-staging.api.letsencrypt.org was the old ACMEv1 API. Nowadays acme-staging-v02.api.letsencrypt.org is used for the modern, up to date ACMEv2 API.

Also note that certbot isn't a daemon in the mainstream used computing term sense of the word: it does not run as a background process.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.