Will 'Error: Let's Encrypt new auth status 400' self resolve when switching from LE-staging to LE-normal?

I’m getting a daily cron error notification:

Cron <admin@myserversub> sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl
Error: Let's Encrypt new auth status 400 (myserversub.myserverhostname.tld)

From looking /var/log/hestia/LE-admin-myserversub.myserverhostname.tld.log (below), it seems like this might be caused by the original cert being issues upon hestia install as LE-normal and then when I switch to hestia LE_STAGING mode for development purposes, it creates this error because it’s calling the LE staging url instead of the LE-normal url.

I assume this will self resolve when I rebuild the servers for production without LE-staging enabled. True?

Date Time: 2024-01-03 03:13:01
user: admin
domain: myserversub.myserverhostname.tld

- aliases: 
- proto: http-01
- wildcard: 

==[Step 1]==
- status: 200
- nonce: mMpbWOlLWP4f8iuq5Ar7Wm1soDXMflLc_srzfY-nOrV3FwMlFGQ
- answer: HTTP/2 200 
server: nginx
date: Wed, 03 Jan 2024 10:13:02 GMT
content-type: application/json
content-length: 826
cache-control: public, max-age=0, no-cache
replay-nonce: mMpbWOlLWP4f8iuq5Ar7Wm1soDXMflLc_srzfY-nOrV3FwMlFGQ
x-frame-options: DENY
strict-transport-security: max-age=604800

==[API call]==
exit status: 0

==[Step 2]==
- status: 400
- nonce: mMpbWOlLd2zmgn8fx1D09xzBHngBqbq2FtLlzEPpxZQUburXhAY
- authz: 
- finalize: 
- payload: {"identifiers":[{"type":"dns","value":"myserversub.myserverhostname.tld"}]}
- answer: HTTP/2 400 
server: nginx
date: Wed, 03 Jan 2024 10:13:02 GMT
content-type: application/problem+json
content-length: 193
cache-control: public, max-age=0, no-cache
link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: mMpbWOlLd2zmgn8fx1D09xzBHngBqbq2FtLlzEPpxZQUburXhAY

  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "KeyID header contained an invalid account URL: \"https://acme-v02.api.letsencrypt.org/acme/acct/1492308876\"",
  "status": 400

I realized I could manually test this by removing LE_STAGING=‘yes’ in hestia.conf and then running:


I didn’t get the error. I’m 99% sure my self-resolving hypothesis above is correct, but I would appreciate it if @eris or someone steeped in this level of minutia might back this up.


For those that might find this useful in the future, 100% confirmed. This error only occurs when LE_STAGING=‘yes’ in hestia.conf

LE_STAGING should not been used and if you use it disable Lets encrypt for that user and delete /usr/local/hestia/data/users/{user}/ssl

The account creating can’t mix the with staging and “live” version

I only use staging on our testing server to bypass the certificate limit and in the past debug issues with ssl due to changes in LE side…

Yes. I use LE STAGING on my development server to bypass certificate limits, because I am creating/destroying test applications many times, which exceeds limits.

I was getting this error and wanted to make sure it wouldn’t impact production servers. I definitely solved the problem. And wanted to post the solution to see in case it was beneficial to anyone.

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