Database Management

Task Factory Error Stack Around "Underlying connection was closed" Where Forcing TLS 1.2 Needs to Take Effect for TLS Mismatch in Encrypted Network Traffic

When trying to connect to an API or any other outside connection such as Salesforce, SharePoint, Dynamics CRM, etc you may encounter this error: "The underlying connection was closed: An unexpected error occurred on a send"

First published date

5/25/2021 3:17 PM

Last published date

8/25/2023 7:17 PM

Overview

This is a common issue regarding connections to an API or any other outside connection such as Salesforce, SharePoint, Dynamics CRM, etc. you may encounter this error:  "The underlying connection was closed: An unexpected error occurred on a send" is indicating an issue within the encrypted network traffic.

 

Product section

Task Factory (TF)

Cause

This is typically due to a TLS version mismatch from the requesting party (SSIS) and the receiving party (what you are trying to connect to.) We often see this with Rest, some APIs will use TLS1.2 and the .Net version the user is using in Visual Studio is 4.5 or lower and not using TLS1.2 by default.  

More reading on this subject can be found here: 

Enabling Strong Cryptography for All .Net Applications

 

Resolution

Here is a good reference of .Net to TLS version: 

  1. .NET 4.6 and above. You don’t need to do any additional work to support TLS 1.2, it’s supported by default. 

  1. .NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You need to opt-in to use it. The following code will make TLS 1.2 default, make sure to execute it before making a connection to secured resource:  

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

 

  1. .NET 4.0. TLS 1.2 is not supported, but if you have .NET 4.5 (or above) installed on the system then you still can opt in for TLS 1.2 even if your application framework doesn’t support it. The only problem is that SecurityProtocolType in .NET 4.0 doesn’t have an entry for TLS1.2, so we’d have to use a numerical representation of this enum value:  

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

 

  1. .NET 3.5 or below. TLS 1.2 is not supported (*) and there is no workaround. Upgrade your application to more recent version of the framework. 

 

Often times we actually see that even if a customer is on .Net 4.6 or higher then you may still see this error. This means you will have to force the use of TLS1.2 by default. You can do that by running this PowerShell script: 

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.


# set strong cryptography on 64 bit .Net Framework (version 4 and above) 

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 

# set strong cryptography on 32 bit .Net Framework (version 4 and above) 

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord