Develop Reference

Using TLS 1.2 on .net 6

Is there any way to force my .net 6.0 application to use TLS 1.2? Im sadly forced to use TLS 1.2 by an API that is yet to be updated and i would prefer to not make a lot of loopholes to run 4.7/4.8 just to get TLS 1.2.

Forcing .NET application to use TLS 1.2 or later

I wonder how to force a .NET application targeting .NET Framework 4.8 to use TLS 1.2 or later (including future TLS versions).
The application execute as a Windows service. For >98% of the users, it is correctly using TLS 1.2 but in a couple of cases it tries to use older versions like TLS 1.0 or even SSL 3.0. The users who have had issues with it using older TLS versions has been able to resolve it by making registry changes, but telling users to reconfigure settings in Windows registry is a bit risky.
I have followed Microsofts recommendation to not hardcoded the application to use a specific TLS version and instead just rely on the OS default (https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls).
So what I wonder is: Is there some way in a .NET application to:
Use the Windows default TLS version if it's TLS 1.2 or later.
If the Windows default TLS version is SSL 3.0, TLS 1.0 or TLS 1.1 then use TLS 1.2 or later (including TLS 1.3)
I know I can hardcode the TLS version using ServicePointManager.SecurityProtocol, but this goes against Microsofts recommendation and if I hardcode it to TLS 1.2 and 1.3, then whenever TLS 1.4 is used and the customers OS is patched to support it, my application will still use TLS 1.3 which I don't want.

What about adding TLS declaration before calling the action
public static void UploadFile()
{
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
}

What version of TLS does my C# program use?

I develop a C# program in Visual Studio 2013 which communicates with a SOAP webservice. How can I tell which version of TLS my program uses?

I got the answer by directing my program to make requests to https://www.howsmyssl.com/a/check.

TLS 1.2 was added in .NET 4.5. The earliest supported .NET version is 4.5.2, so you won't have any issues if you use a supported version.
.NET 4.6 uses TLS 1.2 by default. Earlier versions need this line to enable it :
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 |
SecurityProtocolType.Tls11;
TLS 1.0 is being phased out and SSL v3 is considered broken so they shouldn't be added.

Another good way to check is to install WireShark (https://www.wireshark.org/download.html)
and to use it while running your application.
within the TLS Packets you will be able to see versions and such:
Example for Wireshark View Of TLS traffic...

.NET Framework 3.5 and TLS 1.2

I currently have a web application that uses the .NET 3.5 framework and I am wondering if it will be compatible with TLS 1.2. No where in our code are we dictating TLS version. This is a legacy application and recompiling is not on the table right now. I am not finding much info on whether you can or cannot, but I was under the impression that compatibility is more dependent on the OS version. It looks like the minimum is 2008 R2. The goal is to get paypal to communicate properly come July 1st.

As was mentioned .net 3.5.1 DOES now support TLS 1.2; but you don't need the registry changes mentioned by #Paulina's answer.
I'm using VS 2008 with .net 3.5.30729.4926. All I had to do was:
Add imports:
Imports System.Security.Authentication
Imports System.Net
Add this to my code (C#):
public const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
public const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12
VB.net version:
Const _Tls12 As SslProtocols = DirectCast(&HC00, SslProtocols)
Const Tls12 As SecurityProtocolType = DirectCast(_Tls12, SecurityProtocolType)
ServicePointManager.SecurityProtocol = Tls12
Culled from: https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework Note: by defining the const in my code I could ignore everything else in the article including the registry edits and cs files.

As you can see from the docs, TLS 1.2 is not in the enumeration for SslProtocols, it was added to the enum in .NET 4.5 (thanks #orhun).
There is no workaround for TLS 1.2 compatibility on .NET 3.5.
Unfortunately you will have to upgrade to .NET 4.5 or later to get TLS 1.2 compatibility.
EDIT 10/11/17
My above answer is no longer accurate. In May of 2017, Microsoft released a package to allow TLS 1.2 in .NET 3.5.1.

You can make TLS 1.2 work with Framework 3.5.
Microsoft have released update for it.
Follow this steps
Install Support update for TLS in Framework 3.5 from here:
https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework-3.5.1-on-windows-7-sp1-and-server-2008-r2-sp1
Go to registry
Type regedit in start
Right click and run as administrator
Navigate to registry keys
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
Right click on the registry key and click Export
Name the file and save it with .reg extension (keep them as your backup in case you need to restore them)
Add entry to registry keys
Make copy of the saved files and rename them
Open with text editor and add following text to each key (this is for 64-bit operating system) and save changes (for 32-bit operating system look at the info in the link)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
Double click on the file and click Yes on the window to allow changes
Add code to your project as specified in the link - Developer Guidance section
I applied this solution and it worked for me.

I have just verified that this is all you need in your code to enable support for TLS 1.2 in .NET Framework 3.5:
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
I verified by creating a unit test in .NET Framework 3.5 that fetches this HTML page: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html
Without the above line, the TLS test page says that I'm using TLS 1.0, which is .NET 3.5's default.
TLS 1.1 is deprecated along with 1.0, but if you want to enable it as well, you can use this line instead (not recommended):
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072 | (SecurityProtocolType)768;
The "magic" values 3072 and 768 are taken from .NET Framework 4.5's version of the SecurityProtocolType enum:
192: Specifies the TLS 1.0 security protocol
768: Specifies the TLS 1.1 security protocol
3072: Specifies the TLS 1.2 security protocol
I'm not sure whether the server running this code has to have .NET Framework 4.5 runtime installed or not, but it could be so.

I am having the same problem as the OP - old .net 3.5 code having to connect to an external service using tls 1.2.
As mentioned in the accepted answer there is a patch for tls1.2 released by MS.
After this they have released a patch for Server 2008 (not R2):
https://cloudblogs.microsoft.com/microsoftsecure/2017/07/20/tls-1-2-support-added-to-windows-server-2008/
So it should be possible to upgrade to tls 1.2 while still running server 2008.

SoapHttpClientProtocol and TLS 1.2 - The client and server cannot communicate, because they do not possess a common algorithm

There are numerous posts on SO about this and I have scoured them, but still don't have a solution. I am hoping that someone can point me in the right direction.
We have a requirement now to use TLS 1.2 to connect to a remote provider. So I have installed Windows Server 2016 and configured it as needed:
I know the remote server is running TLS 1.2 and that it supports the highlighted cipher.
We connect to the remote end point using C# proxy class generated by the WSDL provided by the provider - before they converted their end to TLS (System.Web.Services.Protocols.SoapHttpClientProtocol).
When I connect using the proxy I get an exception with the inner exception being "The client and server cannot communicate, because they do not possess a common algorithm".
I cannot see anywhere that ServicePointManager.SecurityProtocol so I am assuming .NET is picking up TLS 1.2 as it is the only enabled protocol? No idea how it is doing the cipher.
Can someone tell me how I go about attempting to fix this? If possible I don't want to regenerate the WSDL proxy class.

If your client application was compiled against .NET Framework 4.5.2 or lower, then by default ServicePointManager.SecurityProtocol is initialized to SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls (SSL 3.0 and TLS 1.0 only), so it won't be able to connect to a remote server that requires TLS 1.2.
There are several ways to allow your client application to use TLS 1.2:
Recompile your client application against .NET Framework 4.6 or later. (In Visual Studio, open your project's property pages, go to the Application tab, and change the Target Framework.)
On the client machine, run RegEdit.exe, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ .NETFramework\v4.0.30319, add a DWORD (32-bit) value named SchUseStrongCrypto, and set it to 1. (This flag causes ServicePointManager.SecurityProtocol to be initialized to Tls | Tls11 | Tls12.)
When your client application starts up, turn on TLS 1.2: ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;
There's no need to regenerate your proxy class because it's not responsible for negotiating the TLS protocol or cipher.

I had this issue removing TLS 1.0 from a website that was connecting to a web service.
For me it was a httpRuntime that was stuck on 4.5.1 in web.config of the web service. The service was changed to 4.6.1, changing the version of httpRuntime in the web.config to 4.6.1 fixed the issue.
The web site tried to set up TLS to the webservice and only has 1.2 and 1.1 available. The web service only supported 1.0 so that caused the error.