Update on unsecured TLS protocols
- Thomas Speekenbrink
- Remco Visser
Important information for customers using hosted or on-premise Microsoft Exchange Server and the SuperOffice Calendar Synchronizer, called the Synchronizer.
** Please forward this article to your system administrator if you are not the IT responsible for your organization **
Symptoms
Since the update of the 21st of August 2019 the Synchronizer is unable to connect anymore to on-premise or hosted Exchange Servers running on Windows Server versions that do not support TLS 1.2 or do not have this feature enabled. Resulting that calendar synchronization is halted.
Calender synchronization mappings that worked before now fail with the following error message from Exchange.
Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The underlying connection was closed: An unexpected error occurred on a send. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
Cause
In preparation of several upcoming requirements this autumn, including the PSD2 Compliance Required by the EU in September 2019 and several security enhancements, we had to upgrade the Microsoft Azure servers to Windows Server 2019. A side effect of this upgrade is that the support for TLS 1.0 and TLS 1.1 has dropped since these protocols are not considered secure by Microsoft due to several breaches in the last couple of years: https://www.digicert.com/blog/depreciating-tls-1-0-and-1-1/
We have identified a handful of customers still using these unsecured TLS protocols targeted at an on-premise or hosted Exchange Server.
If you have these issues, it means that the on-premise or hosted Exchange server is running on an older Windows Server version without TLS 1.2. Please note; this is an insecure situation!
It seems affected customers are using a Windows Server 2008 R2. On this version, TLS 1.2 is not enabled by default.
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#support-for-tls-12
Solution
Update the servers security settings by enabling TLS 1.2
https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12