Applications experience "forcibly closed" TLS connection errors when connecting SQL Servers in Windows

Applies to: Windows Server 2019Windows Server 2016


When an application tries to open a connection to a SQL Server,  one of the following error messages is displayed:

If you enabled SChannel logging on the Server, you will receive Event ID 36888 (A Fatal Alert was generated) when the issue occurs.


  • Depending on the provider or driver that you are using, the error message may slightly vary.
  • This issue also occurs when an application running on Windows Server 2012 R2 tries to connect to SQL Server running on Windows Server 2019.
  • Other client-server applications may encounter a similar issue.


Windows 10, version 1511 and later versions of Windows, including Window Server 2016 or Windows 10, version 1607 that has updates released on Feb 25th or later updates installed, contains a leading zero update. Meanwhile, all Windows versions that released before that do not contain the leading zero updates.

The TLS client and server need to calculate keys exactly the same way otherwise they get different results. TLS connections randomly fail if leading zeros are computed differently by the TLS client and TLS Servers.

When a Diffie-Hellman key exchange group has leading zeros, unpatched computers may incorrectly compute the mac by not accounting for the padded zeros. This issue is typically seen when interacting with non-Windows based crypto implementations and can cause intermittent negotiation failures.

The error messages are returned when the secure TLS handshake is negotiated between the client and the server by using TLS_DHE cipher suite. The use of one of the affected cipher suites can be identified in the “Server Hello” packet. See the network snippet in the "More Information" section for more information.


To fix this issue, make sure that both the client and server involved in a connection are running Windows that have the leading zero fixes for TLS_DHE installed. It is recommended to install the updates since they enhance the conformance to TLS_DHE specifications.

The following list the operating system version according to the updates that are installed.

Windows versions that contain the leading zero fixes for TLS_DHE

  • Windows Server 2016, version 1607
    • KB 4537806: February 25, 2020—KB4537806 (OS Build 14393.3542)
    • KB 4540670: March 10, 2020—KB4540670 (OS Build 14393.3564)
    • Updates that supersede KB4537806 and KB4540670 for the respective OS versions
  • Windows Server 2019 RTM and later versions.
  • Windows 10, version 1511 and later versions of Windows 10 (see release history)

Windows versions that do not contain the leading zero fixes for TLS_DHE

  • Windows Server 2016, version 1607 servers that do not have the patches KB 4537806 and KB 4540670 applied.
  • Windows 10, version 1507
  • Windows 8.1
  • Windows 7
  • Windows Server 2012 R2 and earlier versions of Windows Server


If you cannot update Windows, as a workaround, you can disable the TLS_DHE ciphers by using one of the two methods.

Using Group Policy

TLS_DHE_* ciphers can be disabled by using Group Policy. Refer to Prioritizing Schannel Cipher Suites to configure the "SSL Cipher Suite Order" group policy.

Policy URL: Computer Configuration -> Administrative Templates -> Network -> SSL Configuration Settings
Policy Setting: SSL Cipher Suite Order setting.​

Using a Powershell script

foreach ($CipherSuite in $(Get-TlsCipherSuite).Name){    if ( $CipherSuite.substring(0,7) -eq "TLS_DHE" )    {       "Disabling cipher suite: " + $CipherSuite       Disable-TlsCipherSuite -Name $CipherSuite    }    else    {        "Existing enabled cipher suite will remain enabled: " + $CipherSuite    }}

More information

You can confirm that you are encountering this issue during the connection establishment. When the issue occurs, you can see the following sequence in the network trace on the server.

Examining the Server Hello packet to see the cipher suite being used:


Fore more information, see the following articles: