CRM TLS 1.0 Server specific issues

After deprecating TLS 1.0 internally on premise or self hosted clients may encounter errors such as 'Error: The underlying connection was closed: An unexpected error occurred on a send' or 'Error: An error occurred validating the web service. The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.' or similar connection errors when attempting to deploy ancillary CRM functionality such as...
 

Blackbaud DataWarehouse deployment
SQL Server Reporting Services/CRM report deployment

For knowledgebase articles specific to individual functionalities please see the following

Blackbaud DataWarehouse: BBDW does not deploy when TLS 1.0 is disabled

Microsoft SQL Server Reporting Services/ CRM reports: Issues running the Blackbaud.AppFx.Reports.Deploy.exe with TLS 1.0 disabled


*****************General Resolution for all**********************************

This is a result of recent TLS security changes made to meet new PCI compliance regulations, to see more about TLS click here.

The error occurs as a result of TLS 1.0 being disabled internally, which should be noted is not currently a PCI requirement and as such re-enabling TLS 1.0 internally would serve as a solution.  Should your organization choose to keep TLS 1.0 disabled internally and resolve this issue your organization’s IT department will need to review the below details regarding registry key additions that will need to be added to all CRM related servers including (Application, Web/IIS servers, Database, and/or Report server).  These changes will need to be performed by your organization. 

Blackbaud always recommends having a valid, restorable backup for any component of your environment before making changes. Many of the server configurations require registry settings to enable or activate. Staff should be familiar with making changes to the registry. Ensure you have a plan to, and can, revert any changes to a previous, working state if there are problems.  There are multiple ways to change or add registry settings including (but not limited to) manually adding via the registry editor or via PowerShell or Microsoft Group Policy.  Your organization should review the recommended changes below and evaluate the best method to make the changes on the required servers.

Update the .NET Framework

To update the .NET Framework to support vTLS 1.2, first determine your .NET version number. (For help, see KB 318785.) Earlier versions of the .NET Framework may require updates or registry changes to enable strong cryptography.
Use these guidelines:
  • The .NET Framework 4.6 and earlier versions must be updated to support TLS v1.1 and TLS v1.2.
  • The .NET Framework 4.6.2 supports TLS v1.1 and TLS v1.2.

If you're using the .NET Framework 4.5.1 or 4.5.2 on Windows 8.1, Windows RT 8.1, or Windows Server 2012, the relevant updates and details are also available from the Download Center.
  • The .NET Framework 4.6.1 and earlier versions must be configured to support strong cryptography. Set the SchUseStrongCrypto registry setting to DWORD:00000001. This disables the RC4 stream cipher and requires a restart. To learn more about this setting, see Microsoft Security Advisory 296038.

For 32-bit applications on 32-bit systems (or 64-bit applications on 64-bit systems), update the following subkey value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
 
For 32-bit applications running on x64-based systems, update the following subkey values:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
 
Additional Resources:
Microsoft White Paper on TLS: https://www.microsoft.com/en-us/download/confirmation.aspx?id=55266
PowerShell: http://blog.whatsupduck.net/2014/10/checking-ssl-and-tls-versions-with-powershell.html
PCI Security Standards Council site: https://www.pcisecuritystandards.org/

With suggested resources
 
Q&D PowerShell: https://palmarg.wordpress.com/2014/06/09/enabling-tls-1-2-using-powershell/
Strong crypto .net 4.x
https://www.johnlouros.com/blog/enabling-strong-cryptography-for-all-dot-net-applications

Enabling Strong Authentication for .NET applications
The .NET Framework 3.5/4.0/4.5.x applications can switch the default protocol to TLS v1.2 by enabling the SchUseStrongCrypto registry key.
This registry key will force .NET applications to use TLS v1.2.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

Environment

 Specific to TLS 1.0 being deprecated internally for self hosted/on prem clients
 Blackbaud CRM
 4.0
 4.0
 4.0.180.1600

Was this article helpful?