That workaround is confirmed for older Outlook under XP? 2003 2007? I have tried to reproduce the issue with an worst-case setup (Outlook 2003 under XP). And SMTP under cPanel 68 with Exim 4.89 isn't working with the workaround. Perhaps it is better that way ;-) Looks to me like Exim has some fixes in 4.89 which may prevent the successful transfer even when cipher and protocols are available. Will at least help to motivate everyone to move on to TLS 1.2 and 1.3.
Quite funny, in my test setup the email is sitting in the outbox quite while. From time to time Exim accepts one email but most of the time the email stays in the outbox. Allowing or disallowing weak cipher made no difference to this behavior. Think that is a bug with a certain patch level in Outlook 2003. Time to put the workarounds back in the toolbox. Thanks for your endless forum posting and answering. Not sure if I would be able to be that polite and patient all the time ;-)
If you are using Windows 7 you can apply this update to avoid downgrading the allowed ssl versions on the server side: https://support.microsoft.com/en-us...-and-tls-1-2-as-a-default-secure-protocols-in
Came across this thread in a search for my same issues of not being able to connect to my web host email using Outlook (2013 and 365) with Windows 7, along with most Android mail apps. Thunderbird worked fine though, as did Outlook 2013 on Windows 8.
I tried the fix cPanelNick suggested below (including adding the registry EasyFix) but it didn't work for some reason.
My web host ended up having to adjust the SSL settings for the mail server, but it lowered the overall security level they said. I'm now able to connect with Outlook and the Android mobile apps that didn't work before either.
Wanted to see if anyone has found another solution, or maybe knows why the below solution didn't work for me? I don't like the idea of lowered security levels.
I tried the fix cPanelNick suggested below (including adding the registry EasyFix) but it didn't work for some reason.
My web host ended up having to adjust the SSL settings for the mail server, but it lowered the overall security level they said. I'm now able to connect with Outlook and the Android mobile apps that didn't work before either.
Wanted to see if anyone has found another solution, or maybe knows why the below solution didn't work for me? I don't like the idea of lowered security levels.
We were having this problem with Outlook 2013 and Window 7. The fix proposed in post 14 of this thread was suggested to us in a ticket we opened for the problem. With trial and error I was able to find a more specific answer to our problem which I'd like to share.
With it working I could see in the exim_mainlog "...X=TLSv1:ECDHE-RSA-AES256-SHA.." which confirms the protocol and cipher being used by Outlook 2013.
- From the default list of Options for OpenSSL of +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1 I removed +no_tlsv1
- To the default list of SSL/TLS Cipher Suite List I added ECDHE-RSA-AES256-SHA
With it working I could see in the exim_mainlog "...X=TLSv1:ECDHE-RSA-AES256-SHA.." which confirms the protocol and cipher being used by Outlook 2013.
Once I switched to a newer server, I started having problems with sending email on a windows 7 machine with outlook. My research lead me to:
- WHM/Exim default no longer supported older ciphers
Searching for that issue lead me to:
- Windows has a patch and registry change to enable TLS 1.2
I did that, and it fixed getting emails, yet outlook was still not sending mail.
I then went into account settings under connections where you set the in/out ports, the outgoing port was 465 and the encryption setting was TLS. I changed that to SSL and it now sends emails.
I couldn't reply with this to existing threads because "over 1 year old"... stupid. So posting new.
- WHM/Exim default no longer supported older ciphers
Searching for that issue lead me to:
- Windows has a patch and registry change to enable TLS 1.2
I did that, and it fixed getting emails, yet outlook was still not sending mail.
I then went into account settings under connections where you set the in/out ports, the outgoing port was 465 and the encryption setting was TLS. I changed that to SSL and it now sends emails.
I couldn't reply with this to existing threads because "over 1 year old"... stupid. So posting new.
I am having a hard time understanding this. Obviously telling my clients they need to upgrade their less than 5 year old software and evenein some case hardware to use their domain based email hosted with cpanel is CRAZY - I mean especially when they still can load in any gmail, outlook.com, yahoo, apple, Veriizon, ect ect email into the sames mail clients without any issue. I mean, they obviously arent using TLS1 are they? What gives? What advice can you give me? I know I can simply enable TLS1 and change the cipher list inithe mailserver config but does that not severely reduce security? Not to mention PCI Compliance? My real question here though is why is this only a problem with cpanel mail?
-Jason
-Jason
What other "major mail providers" are you referring to?
If you are referring to providers like Gmail, Outlook, Yahoo ... those are all webmail service providers.
With webmail, your browser functions as the client. A check of gmail's website shows that it still supports TLSv1 and TLSv1.1 - so that connection isn't necessarily as secure as you think it is.
If you are referring to providers like Gmail, Outlook, Yahoo ... those are all webmail service providers.
With webmail, your browser functions as the client. A check of gmail's website shows that it still supports TLSv1 and TLSv1.1 - so that connection isn't necessarily as secure as you think it is.
Yes, but you can use smtp/imap with them using these programs (outlook, apple mail etc.) when you cant use cpanel email because they dont support TLS1.2
(tl;dr - Gmail is not the same thing as shared web hosting providers)
Then they're not really following secure security policies then.
However... Gmail probably has less to be concerned about in regards to PCI compliance.
That's really where all of this comes from.
Technically speaking (I may be wrong here in regards to what is proper PCI rules... someone feel free to correct me if I'm wrong) PCI compliance requires the removal of TLSv1 and TLSv1.1 and probably TLSv1.2 soon if it's not already.
In the shared hosting landscape it's all or nothing. If clientsite1.com needs to be PCI compliant... then service requirement rules have to be put in place for the entire server, so even if clientsite2.com doesn't need to be PCI compliant... it has to suffer the consequences of clientsite1.com needing to be PCI compliant.
This is basically where all of the TLS deprecation is coming from.
Now, if you're not concerned about being PCI compliant, then having TLSv1. and TLSv1.1 enabled is less of a concern for you. That doesn't mean your safe... just that it's probably less of a concern for you.
But technically speaking, TLSv1.2 is the only secure TLS version at this time (aside from TLSv1.3 - which... I'm not sure how adopted it is yet). TLSv1.2 is not without it's own shortcomings... but it's the best available right now.
cPanel (and I'm sure other systems) are pushing secure versions of TLS because... well, they want you to be secure. Unfortunately, old software isn't necessarily going to support newer versions of TLS - that's just the nature of how things work.
Gmail - I suspect - with not having to worry so much about PCI compliance can aim their service to appease the masses. And right now, there is still a portion of users that are using outdated operating systems and browsers that don't support TLSv1.2. There is less of a reason for Gmail to force TLSv1.2 and drop TLSv1 and TLSv1.1 at this time. That doesn't make them more secure... it just makes them available for a larger target audience.
Then they're not really following secure security policies then.
However... Gmail probably has less to be concerned about in regards to PCI compliance.
That's really where all of this comes from.
Technically speaking (I may be wrong here in regards to what is proper PCI rules... someone feel free to correct me if I'm wrong) PCI compliance requires the removal of TLSv1 and TLSv1.1 and probably TLSv1.2 soon if it's not already.
In the shared hosting landscape it's all or nothing. If clientsite1.com needs to be PCI compliant... then service requirement rules have to be put in place for the entire server, so even if clientsite2.com doesn't need to be PCI compliant... it has to suffer the consequences of clientsite1.com needing to be PCI compliant.
This is basically where all of the TLS deprecation is coming from.
Now, if you're not concerned about being PCI compliant, then having TLSv1. and TLSv1.1 enabled is less of a concern for you. That doesn't mean your safe... just that it's probably less of a concern for you.
But technically speaking, TLSv1.2 is the only secure TLS version at this time (aside from TLSv1.3 - which... I'm not sure how adopted it is yet). TLSv1.2 is not without it's own shortcomings... but it's the best available right now.
cPanel (and I'm sure other systems) are pushing secure versions of TLS because... well, they want you to be secure. Unfortunately, old software isn't necessarily going to support newer versions of TLS - that's just the nature of how things work.
Gmail - I suspect - with not having to worry so much about PCI compliance can aim their service to appease the masses. And right now, there is still a portion of users that are using outdated operating systems and browsers that don't support TLSv1.2. There is less of a reason for Gmail to force TLSv1.2 and drop TLSv1 and TLSv1.1 at this time. That doesn't make them more secure... it just makes them available for a larger target audience.
Hello Everyone,
I put together the following overview of this topic for anyone seeing this thread for the first time:
Reported Issue
Attempting to send or receive emails using email applications or operating systems which lack support for Transport Layer Security (TLS) Version 1.2 can result in error messages such as the one below:
error (0x800CCC1A) : 'Your server does not support the connection encryption type you have specified. Try changing the encryption method. Contact your mail server administrator or Internet service provider (ISP) for additional assistance.'
Do you know of any additional error messages that should appear above? Reply to this thread to let us know! Thanks!
Technical Summary
Exim and Dovecot utilize OpenSSL as a means of providing secure connections between email applications and your server. Here's a quote from our documentation describing OpenSSL's two primary settings:
Recommended Solution
Modifying the default cipher and protocol settings for Exim and Dovecot in order to permit less secure connections between legacy email applications and your cPanel & WHM server is not recommended. While such actions are effective at quickly restoring the ability for legacy email applications to send and receive email, it comes at the expense of operating a less secure server.
The recommended approach is to communicate this security knowledge to the person using the legacy email application and/or legacy operating system. Encourage updates to, and adoption of, email applications and operating systems that support modern cipher and protocol requirements.
Or, in the case of users experiencing this issue on Windows 7, it's possible to enable TLS 1.2 using the instructions in the document linked below:
How To Configure Microsoft Windows 7 to use TLS Version 1.2
Additional Reading
For more technical details about Cipher/Protocol settings and overall SSL logic with cPanel & WHM, see the below documents:
How To Adjust Cipher Protocols
Guide To SSL
SSL Installation and Precedence Logic
What about TLS version 1.3?
You can track the status of TLS 1.3 support on the following feature request: Support For TLS 1.3
Additional Feedback/Questions
Feel free to reply to this thread with any additional questions or feedback related to this topic.
Thank you.
I put together the following overview of this topic for anyone seeing this thread for the first time:
Reported Issue
Attempting to send or receive emails using email applications or operating systems which lack support for Transport Layer Security (TLS) Version 1.2 can result in error messages such as the one below:
error (0x800CCC1A) : 'Your server does not support the connection encryption type you have specified. Try changing the encryption method. Contact your mail server administrator or Internet service provider (ISP) for additional assistance.'
Do you know of any additional error messages that should appear above? Reply to this thread to let us know! Thanks!
Technical Summary
Exim and Dovecot utilize OpenSSL as a means of providing secure connections between email applications and your server. Here's a quote from our documentation describing OpenSSL's two primary settings:
TLS version 1.2 is enabled as the default protocol for cPanel & WHM services (e.g. Exim, Dovecot). Thus, if an email application or operating system does not support the use of TLS version 1.2, then attempts to send or receive email will fail with errors like the one included above.
Recommended Solution
Modifying the default cipher and protocol settings for Exim and Dovecot in order to permit less secure connections between legacy email applications and your cPanel & WHM server is not recommended. While such actions are effective at quickly restoring the ability for legacy email applications to send and receive email, it comes at the expense of operating a less secure server.
The recommended approach is to communicate this security knowledge to the person using the legacy email application and/or legacy operating system. Encourage updates to, and adoption of, email applications and operating systems that support modern cipher and protocol requirements.
Or, in the case of users experiencing this issue on Windows 7, it's possible to enable TLS 1.2 using the instructions in the document linked below:
How To Configure Microsoft Windows 7 to use TLS Version 1.2
Additional Reading
For more technical details about Cipher/Protocol settings and overall SSL logic with cPanel & WHM, see the below documents:
How To Adjust Cipher Protocols
Guide To SSL
SSL Installation and Precedence Logic
What about TLS version 1.3?
You can track the status of TLS 1.3 support on the following feature request: Support For TLS 1.3
Additional Feedback/Questions
Feel free to reply to this thread with any additional questions or feedback related to this topic.
Thank you.
Last edited: