Can't update Let's Encrypt certs with "Enable automatic HTTPS redirection"

And when trying to disable it on my admin domain, I get this:

Error: Invalid object format: DOMAIN=‘my.hestiadomain.org’ IP=‘86.x.x.x’ FASTCGI_DURATION=‘’ FASTCGI_CACHE=‘’ CUSTOM_PHPROOT=‘’ CUSTOM_DOCROOT=‘’ ALIAS=‘’ TPL=‘default’ SSL=‘yes’ SSL_HSTS=‘yes’ SSL_FORCE=‘yes’ SSL_HOME=‘same’ LETSENCRYPT_FAIL_COUNT=‘’ LETSENCRYPT=‘yes’ FTP_USER=‘’ FTP_PATH=‘’ FTP_MD5=‘’ BACKEND=‘default’ PROXY=‘default’ PROXY_EXT=‘’ STATS=‘’ STATS_USER=‘’ AUTH_HASH=‘’ AUTH_USER=‘’ REDIRECT_CODE=‘’ REDIRECT=‘’ STATS_CRYPT=‘’ U_DISK=‘1’ U_BANDWIDTH=‘2’ SUSPENDED=‘no’ TIME=‘11:51:08’ DATE=‘2023-01-28’ 2:#DOMAIN=‘xx.org’ IP=‘xx’ IP6=‘xx’ CUSTOM_DOCROOT=‘’ ALIAS=‘’ TPL=‘default’ SSL=‘yes’ SSL_HSTS=‘yes’ SSL_FORCE=‘yes’ SSL_HOME=‘same’ LETSENCRYPT=‘yes’ FTP_USER=‘’ FTP_MD5=‘’ BACKEND=‘default’ PROXY=‘default’ PROXY_EXT=‘’ STATS=‘’ STATS_USER=‘’ STATS_CRYPT=‘’ U_DISK=‘1’ U_BANDWIDTH=‘2’ SUSPENDED=‘no’ TIME=‘11:51:08’ DATE=‘2023-01-28’

Pretty bad, ALL certs are now invalid, and I can’t update them. Is there not a way to use cloudflare DNS api for LetsEncrypt, instead of that weird port 80 verification crap?

In addition, I did not get a warning about hestia not having updating certs properly, it’s not even logged as cron errors, while when I run it manually, I get TimeOut error 400, or Error 15 in hestia log.

Why is:
DOMAIN=‘my.hestiadomain.org’ IP=‘86.x.x.x’ FASTCGI_DURATION=‘’ FASTCGI_CACHE=‘’ CUSTOM_PHPROOT=‘’ CUSTOM_DOCROOT=‘’ ALIAS=‘’ TPL=‘default’ SSL=‘yes’ SSL_HSTS=‘yes’ SSL_FORCE=‘yes’ SSL_HOME=‘same’ LETSENCRYPT_FAIL_COUNT=‘’ LETSENCRYPT=‘yes’ FTP_USER=‘’ FTP_PATH=‘’ FTP_MD5=‘’ BACKEND=‘default’ PROXY=‘default’ PROXY_EXT=‘’ STATS=‘’ STATS_USER=‘’ AUTH_HASH=‘’ AUTH_USER=‘’ REDIRECT_CODE=‘’ REDIRECT=‘’ STATS_CRYPT=‘’ U_DISK=‘1’ U_BANDWIDTH=‘2’ SUSPENDED=‘no’ TIME=‘11:51:08’ DATE=‘2023-01-28’ 2:#DOMAIN=‘xx.org’ IP=‘xx’ IP6=‘xx’ CUSTOM_DOCROOT=‘’ ALIAS=‘’ TPL=‘default’ SSL=‘yes’ SSL_HSTS=‘yes’ SSL_FORCE=‘yes’ SSL_HOME=‘same’ LETSENCRYPT=‘yes’ FTP_USER=‘’ FTP_MD5=‘’ BACKEND=‘default’ PROXY=‘default’ PROXY_EXT=‘’ STATS=‘’ STATS_USER=‘’ STATS_CRYPT=‘’ U_DISK=‘1’ U_BANDWIDTH=‘2’ SUSPENDED=‘no’ TIME=‘11:51:08’ DATE=‘2023-01-28’

On one line and not separated in? And looking at it:
2:#

Might be the issue…

That would explain why
Error: Invalid object format is happening…

No you can’t use DNS authentication with Cloudflare dns as it would mean we need to implement Cloudflare API system with it. If you would like to fund this feature feel free to send an email to [email protected]

This is the error exactly as it appears on screen, except for domainname and ips which I garbled.
When I try the shell, and run

# v-add-letsencrypt-domain admin my.hestiahost.org

Error: Invalid object format: DOMAIN='my.hestia.org' IP='86.xxx' FASTCGI_DURATION='' FASTCGI_CACHE='' CUSTOM_PHPROOT='' CUSTOM_DOCROOT='' ALIAS='' TPL='default' SSL='yes' SSL_HSTS='yes' SSL_FORCE='yes' SSL_HOME='same' LETSENCRYPT_FAIL_COUNT='' LETSENCRYPT='yes' FTP_USER='' FTP_PATH='' FTP_MD5='' BACKEND='default' PROXY='default' PROXY_EXT='' STATS='' STATS_USER='' AUTH_HASH='' AUTH_USER='' REDIRECT_CODE='' REDIRECT='' STATS_CRYPT='' U_DISK='1' U_BANDWIDTH='2' SUSPENDED='no' TIME='11:51:08' DATE='2023-01-28' 2:#DOMAIN='my.hestiahost.org' IP='86.xx' IP6='xxx' CUSTOM_DOCROOT='' ALIAS='' TPL='default' SSL='yes' SSL_HSTS='yes' SSL_FORCE='yes' SSL_HOME='same' LETSENCRYPT='yes' FTP_USER='' FTP_MD5='' BACKEND='default' PROXY='default' PROXY_EXT='' STATS='' STATS_USER='' STATS_CRYPT='' U_DISK='1' U_BANDWIDTH='2' SUSPENDED='no' TIME='11:51:08' DATE='2023-01-28'
Error: Invalid object format: DOMAIN='my.hestuiaost.org' IP='86.xx' FASTCGI_DURATION='' FASTCGI_CACHE='' CUSTOM_PHPROOT='' CUSTOM_DOCROOT='' ALIAS='' TPL='default' SSL='yes' SSL_HSTS='yes' SSL_FORCE='yes' SSL_HOME='same' LETSENCRYPT_FAIL_COUNT='' LETSENCRYPT='yes' FTP_USER='' FTP_PATH='' FTP_MD5='' BACKEND='default' PROXY='default' PROXY_EXT='' STATS='' STATS_USER='' AUTH_HASH='' AUTH_USER='' REDIRECT_CODE='' REDIRECT='' STATS_CRYPT='' U_DISK='1' U_BANDWIDTH='2' SUSPENDED='no' TIME='11:51:08' DATE='2023-01-28' 2:#DOMAIN='my.hestiuahost.org' IP='86.xxx' IP6='xxx0000:0001' CUSTOM_DOCROOT='' ALIAS='' TPL='default' SSL='yes' SSL_HSTS='yes' SSL_FORCE='yes' SSL_HOME='same' LETSENCRYPT='yes' FTP_USER='' FTP_MD5='' BACKEND='default' PROXY='default' PROXY_EXT='' STATS='' STATS_USER='' STATS_CRYPT='' U_DISK='1' U_BANDWIDTH='2' SUSPENDED='no' TIME='11:51:08' DATE='2023-01-28'

Then check /usr/local/hestia/data/user/{user}/web.conf

It looks something got messed up…

I don’t understand what you write or what you mean by what you wrote, what 2:# ??

I have never edited anything manually under /usr/local/hestia except for templates…

Please check the contents first. I have no idea how it happened…

Oh wait, that must have been the ip6 script someone made? I removed that line with the # in front, now at least the admin domain works. Let’s see if I can update LE certs…

No, the issue remains;

I have to first Disable the automatic HTTPS redirection at the web domain, then I can update the cert for the mail. domain version. And then have to re-enable the automatic redirection.

you can create custom template and add the https redirection under site’s location directive to solve this issue.

I would have to do that for about 16 different templates, by several users…
I can do all sorts of workarounds, but the thing is: There were no error mentions about it beforehand. That’s the main issue here. I’d rather solve certificate issues before all users have invalid certs…

Is there a shell command to Disable the automatic HTTPS redirection PLUS Disable the HSTS at the web domain for ALL domains and ALL users in one go, perhaps? And one that then enables it again later?

By default it already disables “Domain” redirects

HTTPS and HSTS should not affect Lets encrypt and it should be able to handle it.

By default a email send on ssl creation failure via the cronjob mail system:

Cron Daemon [email protected] vr 21 apr 06:54 (8 dagen geleden)
aan me
Error: Let’s Encrypt validation status 400 (xxxx). Details: 403:“The key authorization file from the server did not match this challenge "kjCnLme_7UT0YP0OUfmgWHPiLsRV5AAqHl0ovkC_gHc.vIhLfLldppXUta0HrnrzuWyJ5PKBY68FlIXrk18n-AM" != "kjCnLme_7UT0YP0OUfmgWHPiLsRV5AAqHl0ovkC_gHc.JCHn8naDbLLOXT_o-_CE8LySQhBEAsD3mz84FLPnvNE"”

How ever it doesn’t notify the user…

How ever due to the “config” issue you had I don’t know if this got triggered or it is locally disabled.

Will look into adding a system to do it via Notification system after 5 failed attempts to the admin user.
After 15 failed attempts it will start to send emails for example…

I used to be doing the 80 to 443 redirect using just one file for nginx serverwide, containing;

server {
    listen 80 default;
    listen [::]:80 default;
    include header;
    return 308 https://$host$request_uri;
}

I think that may be easier/better than putting redirects inside server/domain conf files.
Either way, I don’t know why yet, but in order to get the (web)mail domain certs, I have to disable HSTS and the https redirect, because if I don’t it says:

# v-update-letsencrypt-ssl
Error: Let's Encrypt validation status 400 (mail.some.site). Details: 400:"86.x.x.x: Fetching https://webmail.some.site/.well-known/acme-challenge/tDmFy9J4UUNcuCEXM36VZnRRZQ_QS5Sr2PnG9WOB2uA: Timeout during connect (likely firewall problem)"

firewall it is not it, and no geo-ip blocking or anything. The hestia error.log says:

2023-04-29 10:45:55 v-add-letsencrypt-domain  'userx' 'some.site' '' 'yes' [Error 15]
2023-04-29 10:45:55 v-update-letsencrypt-ssl some.site Error: Let's Encrypt validation status 400 (mail.some.site). Details: 400:"86.x.x.x: Fetching https://webmail.some.site/.well-known/acme-challenge/AZWAzVVkF1vEdE2WdQ0hjp95fR4aEgZSM5UHFlBld1Q: Timeout during connect (likely firewall problem)" [Error 2]

and this next LE log shows me something useful. Because IPv6 is disabled for my server (see earlier forum posts…), since hestia does not support it (yet). By the way, I really think you should mention this in ALL CAPS before people install hestia, it’s crucial for networking (and cert reliability, obviously). The “addressUsed” entries are for an ipv6 address, for random names!

==[Debug information Step 5]==
{
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "86.x.x.x: Fetching https://webmail.some.site/.well-known/acme-challenge/xQ0z22FdSi0ZoVp4ZJlvkpaBhtMXUGEd4ip9I2-xETQ: Timeout during connect (likely firewall problem)",
    "status": 400
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/223336416667/Xwuu1w",
  "token": "xQ0z22FdSi0ZoVp4ZJlvkpaBhtMXUGEd4ip9I2-xETQ",
  "validationRecord": [
    {
      "url": "http://mail.some.site/.well-known/acme-challenge/xQ0z22FdSi0ZoVp4ZJlvkpaBhtMXUGEd4ip9I2-xETQ",
      "hostname": "mail.some.site",
      "port": "80",
      "addressesResolved": [
        "86.x.x.x",
        "2a02:xxxx:xxxx:xxxx::1"
      ],
      "addressUsed": "2a02:xxxx:xxxx:xxxx::1"
    },
    {
      "url": "http://mail.some.site/.well-known/acme-challenge/xQ0z22FdSi0ZoVp4ZJlvkpaBhtMXUGEd4ip9I2-xETQ",
      "hostname": "mail.some.site",
      "port": "80",
      "addressesResolved": [
        "86.x.x.x",
        "2a02:xxxx:xxxx:xxxx::1"
      ],
      "addressUsed": "86.x.x.x"
    },
    {
      "url": "https://webmail.some.site/.well-known/acme-challenge/xQ0z22FdSi0ZoVp4ZJlvkpaBhtMXUGEd4ip9I2-xETQ",
      "hostname": "webmail.some.site",
      "port": "443",
      "addressesResolved": [
        "86.x.x.x",
        "2a02:xxxx:xxxx:xxxx::1"
      ],
      "addressUsed": "2a02:xxxx:xxxx:xxxx::1"
    }
  ],
  "validated": "2023-04-29T03:04:36Z"
}


==[Abort Step 5]==
=> Wrong status

So, my conclusion is: I need to force RE-generate ALL keys/certs without ipv6 present. Any ideas how to quickly accomplish that on commandline?