Default WHM 116.0.9 Exim cipher list incompatible with default Outlook under W10
Since having recently migrated to a new server with a vanilla WHM 116.0.9 install, I've got several Windows 10 computers in different shops that can no longer send emails. They all use Outlook and all their errors are identical: "None of the authentication methods supported by this client are supported by your server."
None of them have changed anything on their side and it was working prior to migrating to this new server. Upon closer comparison with the old server configuration, I have discovered that on the old server, I had set a custom SSL/TLS Cipher Suite List under Exim Configuration Manager, like 6 or 7 years ago, perhaps even prior to that and that custom cipher value is a very long string compared to the default cPanel one.
I was wondering why a default WHM 116.0.9 install does not accept the default Outlook encryption ciphers from W10 out of the box. One would think Outlook is pretty much standard, no?
I have found this thread which refers to old Outlook clients from 2013 and Windows 7. I can assure you that this happens on much more modern Outlook clients running on Windows 10/11 too. https://support.cpanel.net/hc/en-us/articles/360052791394-Outlook-TLS-error-None-of-the-authentication-methods-supported-by-this-client-are-supported-by-your-server
-
Hey hey! If you have both "default" boxes checked in WHM >> Exim Configuration Manager, we'll need to see a ticket on this as I can't find any other reports of this behavior happening in Windows 10 or 11.
0 -
When I use the SSL/TLS Cipher Suite List provided by the aforementioned cPanel support link above, all those W10 and W11 computers with Outlook work perfectly fine. Are you implying all of those computers lack a Windows update of some kind?
0 -
I'm not implying anything - I'm just saying there haven't been any complaints with Windows 10 or 11 that I can find in our ticket system besides this thread, as those operating systems had full support for the newer protocols at the time of their release. Could you submit a ticket on this one so we can see this in action?
0 -
I would absolutely not want to disturb my customers especially after the downtime, stress and annoyance I've put them through last week while migrating from the old, semi-working server caused by the kernel update / kernelcare trial license fiasco.
What would the information that you need be? I will try and gather it for you and post it here. Also, does that imply reverting the cipher list to the WHM default? Because if so, then forget about it. I don't want my phone to explode with furious Outlook customer phone calls. I would probably lose them for good and then I would have little to no reason to continue paying for a WHM licence with no customers to finance it.
0 -
We would never make changes like that to a system without confirming with you first.
I'm not sure what information we'd need to check on this one, honestly, since I don't really have a precedent to follow. With an issue like this it's never a bad idea to check /var/log/maillog to look for the connection strings to see if there is something more specific there.
0 -
I will be digging through that log, I downloaded it to my computer for analysis, but it's huge already. If you have more specific things I could check, I know:
1) the email address of the customers that were under Outlook and for which the SMTP connection was not working before I add all the low ciphers list from the cPanel support article mentioned above.
2) the approximate date/time one of those occurrences.
0 -
The date and time is likely your best bet. If you know the IP address they are connecting from that would help too.
0 -
OK, I have the 10MB maillog from monday morning (before and after the temporary large cipher list "fix") and I have one of the shops IP address. I see the various logins, etc...
What do you suppose I should be looking for exactly for WHM to fix its default values so that it supports Outlook correctly out of the box?
0 -
I'm a bit confused here - you mention this:
"Also, does that imply reverting the cipher list to the WHM default? Because if so, then forget about it."
but then also this:
"What do you suppose I should be looking for exactly for WHM to fix its default values"
Are you not using the default values on the system? If you DO temporarily switch back to those, does that resolve the issue?
0 -
No, if you read the thread, I had to follow instructions from the cPanel support article in order to inject a bunch of ciphers to support those Outlook computers. Default WHM does not support Outlook 2016 and 2013:
I have found this thread which refers to old Outlook clients from 2013 and Windows 7. I can assure you that this happens on much more modern Outlook clients running on Windows 10/11 too. https://support.cpanel.net/hc/en-us/articles/360052791394-Outlook-TLS-error-None-of-the-authentication-methods-supported-by-this-client-are-supported-by-your-server
I'm offering you guys information so that you can fix WHM so that it supports those Outlook clients in a future version. I'm not looking to revert any of the hacks I've done in order to support those Outlook computers, because if I did, then I would lose those customers for life as it would cause even more downtime.
If you don't think supporting Outlook is worth it, then please close this thread and forget about it.
I don't use Outlook and most of my customers use Thunderbird and had zero issues with vanilla WHM 116.0.9.
0 -
My issue is just that I don't have any other reports of this not working or causing compatibility issues in Windows 10/11, and I am also not able to reproduce, so I can't see what you're seeing on my end. If you'd like to make a ticket so we can see this in real-time on an affected server we'd be happy to do some testing!
0 -
Out of interest, which version of Outlook are they running? (i.e. Outlook 2003, Outlook 2007, Outlook 2010, Outlook 2011 for Macs, Outlook 2013 for Windows, Outlook 2016 for Windows, Outlook 2016 for Macs, Outlook 2019 for Windows, Outlook 2019 for Macs, Outlook 2021 for Windows, Outlook 2021 for Macs, Outlook 365 for Windows, Outlook 365 for Macs, Outlook for IOS, Outlook for Android, Outlook Lite for Android, One Outlook, Outlook Express etc). I do agree with Microsoft that on that page they state "With so many Outlook apps and services, it can be confusing to know which version you're using"(!)
The information included in the cPanel support article shouldn't actually help - as it details how to enable TLS 1.0 and 1.1 - both of which were removed by Microsoft in September 2022.
I suspect that this issue isn't what it actually appears to be - I have a feeling either the clients have an incorrect hostname configured in their Outlook settings (i.e. "oldserver.example.com" of your old server instead of "mail.theirdomain.invalid") or the mail server hostname they do have configured hasn't updated to point to your new server correctly (does "host <whatever they have in outlook>" from their PC resolve to your new IP address?)
1 -
As written in my last message, some are on Outlook 2013 while others are on Outlook 2016. I am well aware of the TLS 1.2 enforcement and that Microsoft pushed updates a couple years ago to remove/disable previous TLS protocols from Windows 10, but I'm enclined to think that the issue is not with the TLS version but rather more about the CIPHERS. If you take a look at cPanel's own article, this is their own ciphers list that enabled those Outlook under W10 to work.
Also, the company who maintains their computers said that updates are OK (and I trust them, since under W10 you cannot postpone updates for more than a few months).
So IMO, for my cases at least, it's about the ciphers and not about TLS.
I have a feeling either the clients have an incorrect hostname configured in their Outlook settings (i.e. "oldserver.example.com" of your old server instead of "mail.theirdomain.invalid") or the mail server hostname they do have configured hasn't updated to point to your new server correctly (does "host <whatever they have in outlook>" from their PC resolve to your new IP address?)
It's not the case. The MX, hostname and IP have not changed after migration (my datacenter hosts PTR and allows to instantly switch an IP to another server)... Plus, immediately after adding the deprecated ciphers list to the new WHM, it instantly began to work everywhere.
0 -
Isn't that the known issue? That older Outlook clients have this problem unless you make the cipher change? I guess I'm not understanding where we're at with this one, as everything you just described is expected behavior.
0 -
Yeah, I think we're not understanding each other and/or cPanel just doesn't care to improve the out of the box WHM experience.
But even if you don't care, then at least update the cPanel support article to mention Windows 10 as it only mentions the issue happening under Windows 7. Clearly, the issue is happening on Windows 10 as well. Moreover, the support article talks about TLS and ciphers as if both were always tied together when getting that Outlook error message but it doesn't look like it's the case either. TLS 1.2 could be patched in Windows and Outlook would still not work without the more elaborate ciphers list set in WHM.
And if those ciphers would come by default in WHM, then all those Outlook 2013 and 2016 would be supported out of the box, which accounts for millions of businesses around the world still. cPanel makes it look like every single business uses Windows 11 with Outlook 365, while Outlook 2016 is still used by over 7% of users. NOTE: I personally HATE Outlook, I don't use it or recommend it to any of my own customers, but some customers still choose to use it (even older versions like 2013 and 2016) and I have to support them still. I'm stuck in a situation where WHM does not support those versions by default, requiring that ciphers hack described 3 months ago in that cPanel support article, despite them being used by millions of users still. I would have liked WHM to come with those ciphers list baked in by default, that's all, but clearly cPanel does not care because not enough users raised their voices and that, arguably, over time, the issue will magically "disappear" when all those Outlook 2016 users migrate to something more modern, which is bound to happen fore sure, some day in the not too distant future anyway.
0
Please sign in to leave a comment.
Comments
15 comments