Let's Encrypt cron error after recent HestiaCP updates

Community Support Cron Jobs
1

For the last couple of weeks (since 2 weeks ago mor or less, I think since a update) I’m receiving this cron error every day:

Cron <hestiaweb@srv3> sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl

Error: Let's Encrypt validation status 400 (srv3.mydomain.com). Details: 403: "The key authorization file from the server did not match this challenge."

In the last 15 days HestiaCP has received several updates, from 1.9.7 to 1.10.2, so I don’t know exactly after which update this started.

The strange thing is that Let’s Encrypt expects this thumbprint:

mUhFBEsnrErlID_Wqa7cj0AY4d4nCcRCoaKIFBBy_xw

which belongs to the admin user (owner of srv3.mydomain.com), but it receives:

SgjkHIfT3ZHtS4cHDyDVJvVFUKMLFQbsRFYLBHMmS-E

which belongs to another Hestia user on the server (foroa).

The certificate expires on September 2 and currently has LETSENCRYPT_FAIL_COUNT='16'.

Has anyone seen this after the recent updates or knows how I should fix it?

Thanks.

2

If you share the actual domain name we could check it.

Also, what’s the output of this command? Replace the domain with the actual domain.

cat /home/*/conf/web/srv3.mydomain.com/nginx.conf_letsencrypt
3

Thanks. I prefer not to share the real domain publicly if possible.

The output is:

location ~ "^/\.well-known/acme-challenge/(.*)$" {

default_type text/plain;

return 200 "$1.mUhFBEsnrErlID_Wqa7cj0AY4d4nCcRCoaKIFBBy_xw";

}

This thumbprint is the correct one for the admin user and is also exactly the one Let’s Encrypt says it expected.

However, Let’s Encrypt says it actually received:

SgjkHIfT3ZHtS4cHDyDVJvVFUKMLFQbsRFYLBHMmS-E

which is the thumbprint of another Hestia user on the same server (foroa).

If the real domain is absolutely necessary for troubleshooting, let me know what exactly you need to check and I’ll see if I can provide the relevant information another way.

Thank you very much!

4

What version are you in? Cause I have the same issue on 1.9.6

5

This site might help.

6

I was able to fix this by restarting nginx.

ps -eo pid,lstart,cmd | grep "nginx: worker"

If the worker start times differ by hours or days, the old ones are still serving cached config with another user’s thumbprint.

The fix:

systemctl restart nginx

Restart, not reload. Then re-issue.

7

Solved.

The problem was related to IPv6.

srv3.mydomain.com had both A and AAAA DNS records, but its Nginx vhost was only listening on IPv4.

Because another domain on the server was listening on IPv6, Let’s Encrypt validation over IPv6 was reaching that vhost instead. This explains why it was receiving the thumbprint of the other Hestia user.

I confirmed it with curl:

  • IPv4 → correct thumbprint (admin)
  • IPv6 → wrong thumbprint (the other Hestia user)

I changed the Proxy Template for srv3.mydomain.com to my IPv6-enabled template, so the vhost now also listens on the server IPv6 address.

After that, IPv6 returned the correct thumbprint and:

v-update-letsencrypt-ssl

completed without errors. The certificate has now been successfully renewed.

Thanks everyone for the help!