4.1.3

4.1.3 is a hotfix for 4.1.2. It contains only the four mail and sign-in fixes below and the cache hardening that comes with them.

Upgrade notes and behaviour changes​

• No manual step. The update to 4.1.3 repairs an affected server by itself: it rewrites the panel's cache login and hands the webmail this server's own mail certificate. Nothing has to be run by hand, before or after the update.
• A certificate problem is no longer reported as a wrong password. When the webmail cannot verify the mail server's certificate, its sign-in page says so, and POST /api/auth/login answers 502 with code: mail_tls_untrusted instead of 401 "Invalid credentials". A wrong password is still "Invalid credentials". Scripts that treated every failed webmail sign-in as a 401 should also handle the 502. (hitechcloudmail#89)
• Some account names are now refused (behaviour change). A hosting account may no longer be named after a key prefix of the shared cache: sess, rl, oidc_bcl_jti, panel_sso_nonce, totp_used, send_idem, bimi, sender-favicon, session, tokens_valid_after, email_import, lockout, mailticket, mcp, ticket, hitechcloud-webmail, hitechcloud_cache_* and op_*. An existing account with one of these names loses its cache login on update and is flagged as suspect; it is not renamed. Treat such an account as suspect and check it. (hitechcloudcli#459)

Fixed​

• Sign-in to 2083 failed on fresh installs where the Redis default user has no password. Seen on Ubuntu 22.04 with Redis 6, connected over the unix socket. Every sign-in stopped with "Your session could not be saved" (Vietnamese: "Không thể lưu phiên đăng nhập"), so nothing in 2083 could be done: no mailbox could be created and webmail single sign-on did not work. Redis 6 refuses AUTH <password> when default has no password, but the CLI's check of the panel's cache login used redis-cli, which prints that refusal and then answers PONG anyway. hitechcloudcli objectcache status therefore reported a working login, and the install kept a password the panel could not use. The check now logs in exactly as the panel does (no AUTH without a password, AUTH <password> for the default user, AUTH <user> <password> otherwise, then PING) and treats the first error as the answer. Every update rewrites the cache login with this check, so an affected server repairs itself when it updates to 4.1.3. (hitechcloudcli#448)
• Webmail sign-in and webmail single sign-on failed when the mail certificate is self-signed or issued by a local CA. This is what the installer leaves when the hostname has no public DNS. IMAP worked, but the webmail checked the mail server only against public certificate authorities, so every sign-in showed "Invalid credentials" and the hand-off from 2083 and 2087 returned to the webmail's sign-in page. webmail.log said self-signed certificate. The CLI now gives the webmail the exact certificate this server's Dovecot and Postfix present (mail_tls_cert, public certificates only, never a key), and writes it again after every certificate issue and renewal. The webmail trusts that certificate, matched by its SHA-256 fingerprint, only for this server's own mail host, for sign-in, the panel hand-off, IMAP sync and sending mail. Every other mail host keeps full verification, and verification is never switched off. A certificate that still cannot be verified is reported as a certificate problem, and the log names the command that refreshes it, hitechcloudcli webmail mail-login. (hitechcloudcli#449, hitechcloudmail#89)
• Webmail sign-in and webmail single sign-on failed on Debian 12 and AlmaLinux 9. The installer gives the panel's cache (Redis or Valkey) a password before the webmail is installed, and the webmail was then set up with a REDIS_URL that carried no login. The cache refused the webmail with NOAUTH: every webmail sign-in ended in "Login failed" and every hand-off from 2083 and 2087 returned to the webmail's sign-in page, on fresh installs and after every update. The webmail now signs in to the cache with a login of its own (see Security), and webmail update, which every update runs, rewrites a REDIS_URL that the cache refuses. An affected server repairs itself when it updates to 4.1.3. (hitechcloudcli#459)
• Opening the webmail from 2083 failed with "Create it first" for a mailbox created outside the panel. A mailbox made with the CLI (or in 2087, or by a restore) after 2083 had cached the account's mailbox list was refused for up to an hour. 2083 now keys that list by the mail server's own account list, /etc/hitechcloud/mail/postfix-accounts.cf, which every way of creating or removing a mailbox writes, so a new mailbox is known at once. An address that is not a mailbox is still refused from the cache, without a new import on every request. (HiTechCloud-Panel#1748)

Security​

• The webmail has its own least-privilege cache user, hitechcloud-webmail, and is never given the cache's administrator login. That user cannot run SCAN, KEYS or publish/subscribe commands and has no administrative rights. The update replaces an administrator login found in the webmail's webmail.env. (hitechcloudcli#459)
• Account names equal to a key prefix of the shared cache are refused, so a hosting account's own cache login can never reach the panel's or the webmail's keys. An existing account with such a name loses its cache login on update and is flagged as suspect (see Upgrade notes). (hitechcloudcli#459)

Verified​

• The fixes were tested in a CI run on 10 test virtual machines, not on customer servers: Debian 12 (three machines), AlmaLinux 9 (three) and Ubuntu 22.04 and 24.04, as fresh installs and as servers upgraded from 4.1.1 to 4.1.2, with both publicly trusted and self-signed mail certificates. The machines ran exactly the code of this release.
• On every machine the updater applied the fixes over 4.1.2 with no manual step, and all of the following passed on all ten: sign-in to 2083; creating a mailbox in 2083 and with the CLI; webmail password sign-in, webmail two-factor sign-in and webmail single sign-on from 2083; the webmail's cache user being refused everything outside its own keys, including publish/subscribe on Redis 6.0; and the reserved account names.
• Two things could not be verified in the test containers. Sending from the webmail: the containers' mail hostname resolves to a private address, which the webmail's outgoing-connection guard refuses, exactly as in 4.1.2 (see Known limitations). IMAP sign-in on AlmaLinux 9: the containers' curl has no IMAPS support, so the check failed before the update as well as after it. IMAP sign-in passed on the Debian and Ubuntu machines.

Known limitations​

• An update that is interrupted can be recorded as complete before the services have been restarted. A fix ships in 4.1.4.
• On servers where the cache is secured, signing out a mailbox's other webmail sessions after a password reset or change, and OpenID Connect back-channel logout, do not take effect in 4.1.3: open sessions last until they expire (at most the session lifetime). 4.1.4 restores both.
• A mailbox that was created in 2083 while sign-in or mailbox creation was broken on 4.1.2 may never have been fully created: its password is refused over IMAP and opening the webmail from 2083 returns to the mailbox list. The update does not repair such a mailbox. Reset its password in 2083, or delete it and create it again. Mailboxes created after the update work.
• On a server whose own hostname resolves to a private address (for example behind NAT), sending from the webmail is refused by its outgoing-connection guard, as in 4.1.2. 4.1.4 exempts the server's own mail host (hitechcloudmail#91).
• WordPress actions in 2083 (for example turning the Redis object cache on or off) fail with 500 Could not open input file: /etc/hitechcloud/wordpress/wp-cli.phar once the server has run an update or a repair. This has been so since 4.0.4, when updates began restricting access to /etc/hitechcloud; the sites themselves keep working. Workaround, as root, if /usr/local/bin/wp exists: mv /etc/hitechcloud/wordpress/wp-cli.phar /etc/hitechcloud/wordpress/wp-cli.phar.stock-disabled. Fixed in 4.1.4 (hitechcloudcli#470, HiTechCloud-Panel#1772).