After webtop update (just now) cannot login into my mail!

NethServer Version: latest
Module: webtop

Just updated my webtop, and now it fails to log me in!

Initially it pops an “Error” dialog with text “error”, then behind it is another “Error” with dialog "Mail account authentication error’ (which is not true).
(also cleaned cookies and fully refreshed)

Roundcube (that I don’t normally use) works fine.

Seems the latest webtop update has issues.

(I can’t be the only one!)

…this used to be a more active place…

So an update just crashed webtop and nobody bothers?
Anyway.

I will try removing webtop and adding it again - but doesn’t look too bright because there was a new update I just did and error is still the same.

Hi Nick, 1.5.9 is running fine by my side. Check the System Logs page, you may find more information to improve the issue description.

Help us to help you.

I see some errors…

For example:


2026-09-29T22:40:11+03:00 [1:webtop1:webapp] 2026-09-29 22:40:11 [ERROR] com.sonicle.webtop.mail.MailManager - Exception initializing mail accounts

or


2026-09-29T22:40:12+03:00 [1:webtop1:webapp] 2026-09-29 22:40:12 [ERROR] com.sonicle.webtop.mail.Service - Exception2026-09-29T22:40:12+03:00 [1:webtop1:webapp] java.lang.Exception: Mail account authentication error

or


2026-09-29T22:40:12+03:00 [1:webtop1:webapp] 2026-09-29 22:40:12 [ERROR] com.sonicle.webtop.mail.Service - Error in PortletMail

I guess Mail app is installed on node 1 as well: any error from it? dovecot, the IMAP server, is the service Webtop talks to.

You may also check the Domains and Users page: Samba/OpenLDAP should list users correctly.

Maybe I was not clear. Webtop doesn’t work. Mail itself does (users are ok etc.).
Roundcube receives and sends mail fine. My mobile also. NS8 mail server works ok.

(which is why the whole issue is not DRAMATIC right now - although I only used Webtop for years)

Webtop fails to connect to my mailbox (or any mailbox), even though I enter the correct credentials, that work for Roundcube etc.
This happened with the previous webtop update AND continues with the one I got today. (.9 and .10)

You didn’t answer my questions.

Anyway, I got more information this morning. Login issues were reported on installations with expired or self-signed certificates. The hypothesis is that since Dovecot advertises STARTTLS on the internal IMAP connection, a new Webtop library may try to enable encryption and fail.

Additional symptoms include Dovecot log lines like:

Sep 30 08:23:38 rl1 dovecot[106831]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:0A000416:SSL routines::ssl/tls alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=10.5.4.1, lip=10.5.4.1, TLS handshaking: SSL_accept() failed: error:0A000416:SSL routines::ssl/tls alert certificate unknown: SSL alert number 46, session=<GeQjBK9cpI4KBQQB>

And Webtop:

Sep 30 08:23:40 rl1 webapp[34271]: 2026-09-30 10:23:40 [ERROR] com.sonicle.webtop.mail.MailAccount - Error connecting to the mail server 10.5.4.1
Sep 30 08:23:40 rl1 webapp[34271]: jakarta.mail.MessagingException: STARTTLS failure

Sonicle developers are investigating the issue on their side.

I’ll keep you posted. In the meantime, please check the IMAP server’s certificate to see if this could be your case, for example:

openssl s_client -connect 10.5.4.1:143 -starttls imap </dev/null | grep ^Verify

If that’s the case, you may try this workaround. Add to Dovecot custom configuration this fragment:

local 10.5.4.1 {
  ssl = no
}

Replace the IP 10.5.4.1 with the VPN IP address of your node.

How to apply Dovecot custom configuration is described in Dovecot custom config. The procedure below was generated by Kapa:


Here’s how to add that fragment to the Dovecot custom configuration on NethServer 8:

  1. Enter the mail module agent environment (replace mail1 with your actual instance name):

    /usr/local/bin/runagent -m mail1
    
    
  2. Open the custom configuration file for editing:

    podman exec -ti dovecot vi /etc/dovecot/local.conf.d/myoverride.conf
    
    
  3. Add your fragment to the file:

    local 10.5.4.1 {
      ssl = no
    }
    
    
  4. Reload Dovecot to apply the changes:

    systemctl --user reload dovecot
    
    
  5. Verify the services are still running correctly:

    systemctl --user status postfix dovecot
    
    

:warning: You can also check the effective configuration with podman exec -ti dovecot doveconf -n before and after the change. Be aware that modifying Dovecot defaults can be dangerous.

Thanks I will get back to you with what I found.

so, do I need to do the trick to not use ssl?

Yes, you can apply the workaround.

However, since this is a production server, I’d recommend configuring a valid TLS certificate instead.

but where?

image

image works as you can see

image …and as I can see webtop login screen ALSO shows secure… it is after I put credential that it goes boom

Webtop and Roundcube are just the client apps. You need to request a certificate for the Mail application too.

You can trigger a new certificate request from Mail > Settings > General card, just by pushing the Save button.

Pay attention to the configured host name, it should match the one used in the MX record. If LE requirements are met, Mail will get a valid certificate for that host name.

BTW, is the mobile app an IMAP client accepting the self-signed certificate?

I think it might ignore it.

Hmmm… I see that my mx records go through a spam control domain.
(mx1.spamcontrol.gr and mx2.spamcontrol.gr, priority 10 and 20)
This was edited by my hosting provider that also offers an anti-spam service.

My actual mail domain is different. (and in the settings I have mail.myowndomain.gr)

What should I do?

Filed a bug to track the Webtop behavior regression Webtop 1.5.9 login fails with invalid mail TLS certificate · Issue #8193 · NethServer/dev · GitHub

The recommended workaround is using a valid certificate. The other workaround acting on Dovecot custom configuration should be removed when the bug fix is released.


  • In System > TLS Certificates > ACME Settings, make sure challenge type is TLS-ALPN-01
  • Make sure that host name correctly resolves to NS8 node and port 443 is handled by Traefik

Go Back to Mail > General settings and push Save with that name: you’re asking a LE a certificate for it. Cross your fingers :slight_smile:

How did you mark this as solution before verifying it works? :slight_smile:

Well it doesn’t.

  • in my setup, my host provider receives my email and I use imapsync to bring mail to my own server
  • mail.myowndomain.gr is defined as “mail server hostname” in mail
  • in settings/http routes, I don’t see mail.myowndomain.gr set anywhere, but I don’t think it ever was
  • webtop.myowndomain.gr is defined there though and was always the way I got to my webtop webmail internally or externally
  • my internal DNS resolves (using cname) webtop.mydomain.gr to myns8.local.mydomain.gr and the proper IP that indeed NS8 is accessible in my LAN
  • my internal DNS has no MX entries for my domain, so if I nslookup for mx from my LAN, it asks external DNS, which resolves to serverlogs.myhostprovider.gr (??? I wonder why, possibly same server as their mail server)
  • my external DNS (in my host provider, that I can edit), as I said resolves mx to mx1.spamcontrol.gr and mx2.)
  • ACME settings were not TLS-ALPN-01, but I changed them to that
  • 443 traffic, is port forwarded (I use NS8 traefik as my reverse proxy) to my NS8 by my router (although this is irrelevant for LAN access to my webmail)
  • I did mail/general settings/save and even rebooted my whole NS8 after that… both roundcube and webtop has certs that expire 18/Dec

webtop has exactly the same behavior

…but I think we went too far for webtop not logging in, when mail server itself still works and roundcube still works? (except if I broke mail with said changes :slight_smile: )

So… anything else to do?

The marked solution does not mean “works for me”, it indicates the available options if somebody hits the bug.

You can either wait for the bug fix release or apply the suggested workarounds.

Yes I applied those. This is what I am telling you. Didn’t work.

Except if I should temporarily disable ssl. (the non suggested solution) This is what you mean?

Didn’t work with the valid LE certificate?

Workarounds shouldn’t matter any more, since the bug fix has been released as Webtop 1.5.11.

I can verify 1.5.11 works fine. Thanks for the help.