Upgrading TLS to 1.3 Makes a Difference
Transport Layer Security version 1 (TLS 1.0) was published in 1999 by the Internet Engineering Task Force (IETF) as the successor to Secure Sockets Layer Security (SSL). TLS 1.0 was succeeded by TLS 1.1 in 2006, and the now widespread TLS 1.2 was introduced in 2008. Exchange 2019 only uses TLS 1.2 and older versions of TLS are disabled.
However, TLS 1.3 was introduced in 2018, and Windows Server 2022 introduced support for TLS 1.3 forward. Exchange 2019 CU15 will support TLS 1.3, but unfortunately only partly, as announced in their 2025 H1 Cumulative Update for Exchange Server blog post
In this article, I explain the changes and advantages of TLS 1.3 and compare it with TLS 1.2.
Transport Layer Security
TLS is a cryptographic protocol used to authenticate connections between clients and servers and to encrypt data exchanged via these connections.
When a client wants to set up a connection with a server, the first step is to send a ‘client hello’ message to the server. This short message contains information about the TLS version, the cipher suites available on the client, and a random string of bytes, known as the ‘client random’.
The server responds with a ‘server hello’ message. This message contains information on the TLS version and the cipher suite that the server has chosen. It also contains a random string of bytes, known as the ‘server random’.
The third step is for the client to verify the server’s certificate with the Certificate Authority that issued the certificate to see if it is valid. If the certificate check is successful, the client sends a Client Key Exchange message. This message also includes a pre-master secret encrypted with the server’s public key.
The pre-master secret and both Client Random and Server Random are used to generate a symmetric session key. This key encrypts all further communication between the client and the server.
When all steps are finished, the client can send an HTTP request to the server, which responds with an HTTP Response message, followed by all other HTTP traffic.
This is shown schematically in Figure 1.
TLS 1.3 follows the same principle but combines several steps, resulting in less communication between the client and the server.
When the client sends the ‘Client Hello’ message to the server, it automatically includes the TLS version (1.3), the supported cipher suites, the key exchange methods, and the ‘client random’ string.
The server constructs the master secret using the ‘client random’, its own ‘server random’, and cipher suites. The server then responds with a message containing the protocol (TLS 1.3), the selected cipher suites, the selected key exchange method, and the server’s certificate.
The client verifies the certificate and starts immediately with an encrypted connection, which includes the ‘Client Finished’ message and the initial HTTP request.
The TLS 1.3 handshake only uses one round-trip between the client and the server, whereas TLS 1.2 uses two round-trips to set up an encrypted connection. This is shown schematically in Figure 2.
Cipher Suites
A cipher suite is a set of cryptographic algorithms that specify how encryption, authentication, and data integrity are achieved in the TLS protocol. Cipher suites are used for secure data transmission between a client and a server, on all networks.
A cipher suite consists of four components:
- Key Exchange Algorithm —The key exchange algorithm allows a client and a server to exchange encryption keys safely. Well-known key exchange algorithms are RSA (named after its creators, Rivest, Shamir, and Adleman) and Diffie-Hellman.
- Key Encryption Algorithm — The exchanged key is used in an encryption algorithm like AES (Advanced Encryption Standard) or 3DES (Triple Data Encryption Standard) to exchange encrypted data between a client and a server.
- Message Authentication Code — The message authentication code (MAC) ensures data integrity between the client and the server. A well-known MAC algorithm is SHA-256, SHA-384, or SHA-512 (Secure Hash Algorithm). The higher the number, the more secure an algorithm is.
- Pseudorandom Function (PRF) — The PRF is used for key generation and for generating the server random and client random used when setting up a TLS connection between a client and a server.
By default, Exchange 2019 uses a limited set of cipher suites, eight in total, and all are strong cipher suites. As a comparison, Exchange 2016 uses a set of thirty-eight cipher suites, and many of these cipher suites are considered ‘weak’ and should no longer be used.
To request the cipher suites in PowerShell, use the Get-TlsCipherSuite command as shown in this example:
(Get-TlsCipherSuite).Name TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS 1.3 cipher suites differ from TLS 1.2 cipher suites. As such, they are not compatible. TLS 1.2 cipher suites cannot be used by TLS 1.3 and TLS 1.3 cipher suites cannot be used by TLS 1.2. So, when Exchange 2019 CU15 is installed, two additional Cipher Suites are installed specifically for TLS 1.3:
TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256
TLS 1.3 in Exchange 2019 CU15
When Exchange 2019 CU15 is installed, TLS 1.3 is automatically configured. TLS 1.3 is installed alongside TLS 1.2, and clients and servers will automatically try to use TLS 1.3 to communicate. If setting up a TLS 1.3 connection fails, the client and server will automatically try to set up a TLS 1.2 connection. Please note that a client in this respect can also be another Exchange server. When more servers with CU15 are rolled out you will see a gradual increase in TLS 1.3 traffic.
Unfortunately, Exchange 2019 CU15 only supports TLS 1.3 for HTTPS connections and not yet for SMTP. When sending messages between Exchange 2019 CU15 servers and other TLS 1.3 capable servers, TLS 1.2 is automatically being used. Microsoft plans to add support for TLS 1.3 in SMTP in a future update for Exchange 2019 CU15.
When you have an Exchange 2019 CU15 server that doesn’t have TLS 1.3 configured, it is possible to configure TLS 1.3 for the server manually. To do this, the .NET Framework Schannel inheritance must be configured. This is only needed for .NET 4.x but Microsoft recommends that you configure this for the .NET Framework 3.5 as well for consistency reasons.
To configure the .NET Framework 4.x Schannel inheritance set the following registry keys:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
To configure the .NET Framework 3.5 Schannel inheritance set the following registry keys using PowerShell:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
To configure TLS 1.3 on Exchange 2019 CU15, use the following PowerShell commands to set the correct registry keys:
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" -Name "TLS 1.3" -ErrorAction SilentlyContinue New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3" -Name "Client" -ErrorAction SilentlyContinue New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3" -Name "Server" -ErrorAction SilentlyContinue Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client" -Name "DisabledByDefault" -Value 0 -Type DWord Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client" -Name "Enabled" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server" -Name "DisabledByDefault" -Value 0 -Type DWord Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server" -Name "Enabled" -Value 1 -Type DWord
The last step to configure TLS 1.3 on Exchange 2019 CU15 is to enable the TLS 1.3 cipher suites. Use the following PowerShell commands to enable the cipher suites:
Enable-TlsCipherSuite -Name TLS_AES_256_GCM_SHA384 -Position 0 Enable-TlsCipherSuite -Name TLS_AES_128_GCM_SHA256 -Position 1
Unless you have very specific reasons to disable TLS 1.3, I recommend keeping the default settings and automatically configuring TLS 1.3.
Use the Microsoft Exchange Healthchecker script on an Exchange 2019 CU15 server and check the HTML report. Figure 4 shows the settings for TLS 1.2 and TLS 1.3, where both versions are enabled. Likewise, TLS 1.0 and TLS 1.1 should be disabled in the same report, but this is not shown here (Figure 4).
The HTML output also shows the cipher suites configured on the Exchange server as shown in Figure 5.
How do you know a client uses TLS 1.3? Create a connection to an Exchange 2019 CU15 server in your browser and open the developer tools. Select the Security tab, and it will show the certificate, the TLS version, and the algorithms being used. This is shown in Figure 6.
Summary
Transport Layer Security or TLS is used to setup secure connections between clients and servers. The latest version is TLS 1.3 and was introduced in 2018 as the successor of TLS 1.2.
Windows Server 2022 and Windows Server 2025 both support TLS 1.3. As of Exchange 2019 CU15, Exchange Server supports TLS 1.3 too.
TLS 1.3 is more efficient and more secure than TLS 1.2 and it is configured by default in Exchange 2019 CU15.
TLS 1.3 is a very welcome addition to Exchange 2019, but unfortunately at this moment only HTTPS supports TLS 1.3. SMTP Support for TLS 1.3 is expected to come in a future update for Exchange 2019 CU15.
