Cron <[email protected]> sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl

For a few days ago, I am receiving this mail:

Cron [email protected] sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl

mint.domain.tld Error: Let’s Encrypt new auth status
pruebas.domain.tld Error: Let’s Encrypt validation status 400
chat.domain.tld Error: Let’s Encrypt validation status 400
domain.tld Error: Let’s Encrypt validation status 400
camino.domain.tld Error: Let’s Encrypt validation status 400

I have tried in terminal from “admin” account:
sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl

And from “root” account:

With the same result.

In Hestia/Logs I can see daily:>

02 Dec 2019 05:00:50 deleted dns record 35 on domain.tld
02 Dec 2019 05:00:44 added CAA dns record @ for domain.tld

Actually there isn’t a CAA record in my zone.

The only subdomain that does not appear in the mail is the Hestia hostname.

Do these domains exist as WEB domains? For a successful Let’s Encrypt validation, the domains need to exist under the WEB section of a user (admin, or other) and also have the relevant DNS records.

In simple words, if you open your web browser and type in each domain at the address bar, you should be able to see the corresponding web page which is hosted on the HESTIA server.

Moreover, have you updated to Hestia 1.0.6? I see there were some fixes about Let’s Encrypt.

All of them are in Hestia / Web domains, are accessible from the internet and still have a valid LE certificate. My current Hestia version is 1.0.6.

It may be that the problem is in " Enable automatic HTTP-to-HTTPS redirection"? I have unchecked one of them to try it.

And it is!!! The option “Enable automatic HTTP-to-HTTPS redirection” was the cause of the problem “Error: Let’s Encrypt validation status 400”. Only the unmarked subdomain has renewed its certificate successfully. It seems that Let’s Encrypt needs to access via HTTP and not HTTPS to validate the domain even if the previous certificate is valid.

And what about creating and deleting daily a CAA DNS record in logs? Is that normal? Should I create one? With what content?>

11 Dec 2019 05:01:05 deleted dns record 39 on domain.tld
11 Dec 2019 05:00:59 added CAA dns record @ for domain.tld


1 Like

Thanks @Wibol for your finding, we will look into this.

What webstack are you using nginx, apache or apache behind nginx reverse proxy?

I did a default installation with apache behind nginx reverse proxy.


Today the CAA record has appeared on its own:

@ CAA 0 issue “