Contents
Overview
In part 3 of our Exchange Server TLS Guidance series, we introduce how to turn off TLS 1.0 and 1.1 in your Exchange Server deployment. Turning off TLS 1.0 and 1.1 can be a highly disruptive event if not planned and executed properly. The Exchange team believes that it is time for the ecosystem to fully embrace TLS 1.2, but urges you to proceed with caution when disabling TLS 1.0 and 1.1. This includes understanding how and being prepared to reverse the configuration steps if necessary.
Assumption
Before disabling TLS 1.0 and 1.1, it is important that you have completed the steps outlined in Part 1: Getting Ready for TLS 1.2 and Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It. Do not proceed until you have completed these steps on all Exchange servers, have read all of Part 3 (this post) and understand the implications of disabling TLS 1.0 and 1.1.
Disabling TLS 1.0 and 1.1
We have attempted to simplify adopting newer versions of TLS by aligning Exchange configuration to the operating system capabilities. In Exchange Server 2016 and later, Exchange fully inherits the capabilities of the operating system on the platform where Exchange is installed. Exchange Server 2013 behaves the same as Exchange 2016 with the exception of POP and IMAP. Exchange 2010 has a similar restriction for POP and IMAP but behaves differently than Exchange 2013 (see the About POP and IMAP section below). The steps used to disable TLS 1.0 and 1.1 outlined below will apply to the following Exchange functionality:
- Simple Mail Transport Protocol
- Outlook Client Connectivity
- Exchange Active Sync
- Outlook on the Web (and Outlook Web App / Outlook Web Access in earlier versions of Exchange)
- Exchange Admin Center and Exchange Control Panel
- Autodiscover
- Exchange Web Services (and Representational State Transfer “REST” where implemented)
- Use of PowerShell by Exchange over HTTPS
- POP and IMAP (Exchange Server 2013 and later only)
Disable TLS 1.0 and 1.1 in SChannel
All Windows Server Versions
In Part 2, we introduced how to enable TLS 1.2 in Windows SChannel using the Windows Registry. To disable TLS 1.0 and 1.1 you make use of the same Enabled and DisabledByDefault DWORD entries, but with different values. An admin must modify the TLS 1.0 and TLS 1.1 portions of the SChannel registry section and turn the protocols off instead of turning them on. To disable TLS 1.0 for both Server (inbound) and Client (outbound) connections on an Exchange Server perform the following: 1. From Notepad.exe, create a text file named TLS10-Disable.reg. 2. Copy and paste the following text into the file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
“DisabledByDefault”=dword:00000001
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
“DisabledByDefault”=dword:00000001
“Enabled”=dword:000000003. Save TLS10-Disable.reg. 4. Double click the TLS10-Disable.reg file. 5. Click Yes to update your Windows Registry with these changes. 6. Restart the machine for the changes to take effect. To disable TLS 1.1 for both Server (inbound) and Client (outbound) connections on an Exchange Server please perform the following: 1. From Notepad.exe, create a text file named TLS11-Disable.reg. 2. Copy and paste the following text into the file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
“DisabledByDefault”=dword:00000001
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
“DisabledByDefault”=dword:00000001
“Enabled”=dword:000000003. Save TLS11-Disable.reg. 4. Double click the TLS11-Disable.reg file. 5. Click Yes to update your Windows Registry with these changes. 6. Restart the machine for the changes to take effect.
About POP/IMAP
Exchange Server 2010
The Exchange product updates which allow POP/IMAP to dynamically consume the operating system SChannel configuration settings for POP/IMAP connections are not available in Exchange Server 2010. POP/IMAP are still dependent upon SChannel configuration, but are hard coded to allow TLS 1.0 or SSL 3.0 negotiation only in Exchange Server 2010. As of the posting date for this entry, if TLS 1.0 is disabled in SChannel, clients will fallback and attempt to negotiate SSL 3.0. If SSL 3.0 is disabled, client negotiation will fail. There are no current plans to change this product behavior. Microsoft’s implementation of TLS 1.0 has no known vulnerabilities but SSL 3.0 use is strongly discouraged. Customers who need to ensure that TLS 1.2 is used for SMTP / HTTPS traffic may need to add servers specifically configured to support TLS 1.0 only for POP/IMAP if needed in their environment.
Note: We assume that most customers have disabled SSL 3.0 already. If not, the process used to disable SSL 3.0 can be found at support.microsoft.com.
Exchange Server 2013
Similar to Exchange Server 2010, POP/IMAP on Exchange Server 2013 does not dynamically inherit the operating system SChannel settings. POP/IMAP protocols are hard coded to negotiate TLS 1.2 in Exchange Server 2013. This means customers can proceed with disabling TLS 1.0 and 1.1 on Exchange Server 2013. It is unlikely, but if TLS 1.3 (or later) support is added on the operating systems supported by Exchange Server 2013, customers will need to determine how to proceed with publishing endpoints which meet their requirements.
.NET considerations and other applications on an Exchange Server
The steps outlined in this series address the Exchange product code running on an Exchange server. The guidance provided represents the actions and steps to allow Exchange to successfully negotiate TLS 1.2. Other articles specific to .NET may reference additional actions, e.g. the use of SchUseStrongCrypto. Exchange only requires the use of SystemDefaultTlsVersions introduced in Part 2 of this series. We have worked with the .NET team to ensure that use of other .NET settings does not conflict with how Exchange has been developed and our approach to dynamically inherit the operating system capabilities. It is entirely possible that other applications developed on the .NET Framework which are deployed on an Exchange Server may require additional configuration. Customers should work with the ISV’s for any applications installed on an Exchange server to understand an application’s specific requirements.
Summary
This concludes our series on how to enable TLS 1.2 on Exchange Server and disable older TLS versions. With proper planning and execution, customers should be able to successfully transition to TLS 1.2. We encourage you to complete this across all of your Exchange servers as soon as reasonably possible. We introduced the topic of ciphers as a part of the discussion on TLS encryption when we started this series. It is our intention in the near future to provide additional guidance to customers on the cipher and hashing algorithms that we recommend be used to best secure Exchange Server communications. For now, enjoy the improvements that TLS 1.2 can provide and check this off your list of things to do with your Exchange servers. A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher, Arindam Thokder and others for combining numerous efforts of work into this series of postings. The Exchange Team.