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

[evonet]

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
WEB_SYSTEM: nginx
PROXY_SYSTEM: 
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
}
 order: 

[evonet]

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

v-update-letsencrypt-ssl

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.

Thanks!

[evonet]

@evonet

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

v-update-letsencrypt-ssl

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.

Thanks!

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

[eris]

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…

[evonet]

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.