2

I need to force the usage of TLS 1.2 in SQLCLR assembly which is installed on SQL Server 2008 R2. I have read the answer explaining how to enable TLS 1.2 programatically.

Unfortunately, adding System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolTypeExtensions.Tls12; causes the error The requested security protocol is not supported, even though the Windows Server (2008 R2) is up-to-date (so mentioned Microsoft's hotfix is included).

Does anybody use the same approach in SQLCLR assembly? Is there any other way to support TLS 1.2 in such assembly?

The target framework of the assembly is set to: .NET Framework 3.5

gis
  • 141
  • 11

1 Answers1

1

The answer you linked to actually has the following code, which looks similar to what I have tried myself and gotten to work, and is effectively the same thing as using SecurityProtocolTypeExtensions:

Add this to my code (C#):

public const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
public const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12

Did you try exactly that? Also, if SQL Server is running on Windows Server 2008 R2, what SP level is the OS at? Reading through the KB article on "Support for TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and Server 2008 R2 SP1" (linked in the answer you linked to), there are a few possibilities for the "System.NotSupportedException: The requested security protocol is not supported" error:

  1. hotfix is not installed (have you rebooted the OS since updating .NET?)
  2. you SQL Server is running on Windows Server 2008, not 2008 R2

If neither of those are the case, then perhaps explicitly targeting .NET 3.5.1 might work (though I didn't think it was necessary). While you did mention already targeting 3.5.1, I suspect you did this in the app.config file for your project, in which case it will have no effect since SQL Server has no knowledge of that file. SQL Server uses its own app config file located at:

"C:\Program Files\Microsoft SQL Server\MSSQLxx.yyyyy\MSSQL\Binn\sqlservr.exe.config"

where:

  • "xx" = 2-digit SQL Server version: 2008 / 2008 R2 = 10, 2012 = 11, 2014 = 12, and so on.
  • "yyyy" = instance name. Default instance name is "MSSQLSERVER".

After making a change to that config file, you at least need to reload user app domains via DBCC FREESYSTEMCACHE(N'ALL');. That should be enough. However, to be 100% certain you can restart the SQL Server instance.

Solomon Rutzky
  • 46,688
  • 9
  • 128
  • 171
  • It turns out that mentioned hotfix may not be installed even though the system shows it is up-to-date (Windows Server 2008 R2 SP1). I have asked the administrator to install the patch manually and I am going to check it again. Nevertheless, thank you for your answer which ensured me that it is not a SQLCLR limitation but probably invalid configuration. I will mark this answer after the patch is installed. – gis Jul 06 '20 at 13:00
  • @gis "_hotfix may not be installed even though the system shows it is up-to-date_": that might simply indicate that a reboot of the OS is required, if it _looks_ like it's installed but doesn't _act_ like it's installed. Good luck. – Solomon Rutzky Jul 06 '20 at 13:09
  • The administrator has confirmed that the hotfix wasn't installed. Currently, after manual installation, it works as intended. So I guess that mentioned 'up-to-date' message may not exactly indicate that the system is '_fully up to date via Windows Update_'. By the way, I'm pretty sure the system was rebooted several times after the automatic update, so I don't think it was the reason. – gis Jul 14 '20 at 10:51
  • @gis I think hotfixes are not part of the "normal" updates. I think they also always come with the "only install if really needed and do not install if everything is fine" warning. – Andreas Reiff Dec 17 '21 at 17:22