For example, a Microsoft Outlook client running on Windows 7 would report:

Receiving reported error (0x800CCC1A) Your server does not support the connection encryption type you have specified. Try changing the encryption method. Contact your mai server administrator or Internet service provider (ISP) for additional assistance.”

Despite the minor version number increment, Dovecot 2.4 is a major update which has significant breaking changes to the structure of the configuration files and thus the old configuration files need to be carefully converted in order to work with Dovecot 2.4.

Dovecot 2.4 should really have been called Dovecot 3.0. I have no idea why Open-Xchange considered a minor version number bump to be appropriate for this release.

The default TLS ciphers enabled for Dovecot (both 2.3 and 2.4) on cPanel are:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES256-GCM-SHA384

This is almost identical to the very useful Mozilla “Intermediate” list, except that the DHE-RSA-CHACHA20-POLY1305 cipher is missing.

Windows 7 has very poor support for modern cryptography since it went end-of-life in January 2020 and so hasn’t received any updates for 6 years now.

The supported cipher suites advertised in the SSL/TLS handshake by a Windows 7 client device are:

Most of these are now considered insecure and thus are not enabled on the server side.

The overlap between the TLS ciphers supported by the client and the TLS ciphers which are allowed on the server side is just four ciphers:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256

Unfortunately, the two ECDHE-ECDSA-* ones will only work if you are using ECDSA SSL certificates. If you are using RSA certificates then you can only use the DHE-RSA-* ones.
Still, we have TLS ciphers which are supported by both the client and the server so this should be working… why isn’t it?

Previously under Dovecot 2.3, cPanel had the following configuration in /etc/dovecot/dovecot.conf for the Diffie-Hellman parameters file necessary for the DHE-RSA-* ciphers to function:

# SSL DH parameters
# Generate new params with `openssl dhparam -out /etc/dovecot/dh.pem 4096`
# Or migrate from old ssl-parameters.dat file with the command dovecot
# gives on startup when ssl_dh is unset.
ssl_dh = </etc/dovecot/dh.pem

In Dovecot 2.4 this configuration directive changed to “ssl_server_dh_file” (see https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html#converted-settings) and it isn’t present anywhere in /etc/dovecot/ post-upgrade on cPanel servers.

As a random, aside; the old configuration “ssl_dh” option value was for the contents of the certificate, which could be read from a file with the redirect. The new “ssl_server_dh_file” option takes file path as the value, which Dovecot then reads itself. As such, when moving from 2.3 to 2.4 it’s important to ensure that you don’t copy over the less than symbol that precedes the path, otherwise Dovecot will try to read the contents of that file and treat those as the path that it should use.

In order to add the configuration for the Diffie-Hellman parameters file to the Dovecot 2.4 configuration yourself, you will need to make use of the cPanel configuration file templating system, otherwise any manual changes to the configuration files in /etc/dovecot/ will get overwritten the next time cPanel regenerates them.

First check if the /var/cpanel/templates/dovecot/main.local file already exists (for example if you already have custom Dovecot configuration or if you are using Imunify360). If not, then copy the file /var/cpanel/templates/dovecot/main.default to /var/cpanel/templates/dovecot/main.local and edit it in your favour editor to add the following configuration to the bottom of the file:

# Required for DHE-RSA-AES128-GCM-SHA256 and DHE-RSA-AES256-GCM-SHA384 ciphers needed for Windows 7 clients to work
ssl_server_dh_file = /etc/dovecot/dh.pem

Once you have modified the /var/cpanel/templates/dovecot/main.local file, you can run “/scripts/builddovecotconf” to regenerate the configuration files from your new template, followed by “/scripts/restartsrv_dovecot” to restart the Dovecot service.

IMAP and POP3 clients running on old devices such as Windows 7 should once again be able to connect as the DHE-RSA-* TLS ciphers that they rely on are functioning again.

The post cPanel Dovecot 2.4 upgrade breaking Windows 7 clients first appeared on Spheron1.

In one of these cases, cPanel actually uninstalled the Dovecot RPM as part of the automated, overnight upcp process! In the other cases, Dovecot was still running and accepting connections, but POP3/IMAP clients were getting messages that their passwords were wrong.

Reinstalling Dovecot if upcp has decided to remove it for some reason is quite simple – just use the cPanel script to check and repair their RPMs:

/scripts/check_cpanel_rpms –fix

Whilst the Dovecot RPM is now installed, chances are that Dovecot is still left in a broken state with any login attempt failing and messages like this in /var/log/maillog:

dovecot: auth: Fatal: execv(/usr/local/cpanel/bin/dovecot-wrap) failed: Permission denied

If you look at the ownership and permissions on /usr/local/cpanel/bin/dovecot-wrap, you’ll find that it’s root:root instead of root:dovecot and so you need to run the following in order to fix the ownership:

chgrp dovecot /usr/local/cpanel/bin/dovecot-wrap

At this point, you won’t be seeing any of the permission errors in the maillog, but you’ll still be seeing failed authentication attempts. Now you want to trick cPanel into thinking that the RPM has been removed so that it will try and re-install it. This should mean that the scripts from the RPM are executed without replacing any of the files:

rpm -e –nodeps –justdb dovecot
/scripts/check_cpanel_rpms –fix

If you are still having problems at this point, then try running the following to set the setuid flag for the owner on the script:

chmod u+s /usr/local/cpanel/bin/dovecot-wrap

Then you just need to re-run the above RPM trick and Dovecot should spring back into life with successful authentication attempts being logged into the maillog.

According to cPanel support, this is a “known issue” which has somehow made its way through the EDGE, CURRENT and RELEASE tiers into the STABLE tier…

The post cPanel breaking Dovecot in 11.40 first appeared on Spheron1.