Our ASP.NET 2.0 website processes credit card transactions via calls to Authorize.Net's API. Authorize has informed us that on a date certain, to be announced, our client must utilize TLS 1.2 protocol for API calls.
Microsoft seemed to indicate that a solution is available in this 10-22-16 KB article: https://support.microsoft.com/en-us/help/3154517/support-for-tls-system-default-versions-included-in-the-.net-framework-2.0-sp2-on-windows-vista-sp2-and-server-2008-sp2
...we have added the SslProtocolsExtensions enumeration that you can use as an option for setting TLS v1.2, TLS v1.1, as well as operating system defaults for the ServicePointManager.SecurityProtocol property when targeting .NET framework version 2.0 SP2.
Please note that, despite the title of this article, the quote above does not refer to Windows Vista SP2 or Windows 2008 SP2 operating systems, since those operating systems do not support TLS v1.1 and 1.2.
I have implemented and tested my understanding of the solution indicated in the KB article by taking the following steps:
- Enabled TLS 1.2 on our Windows Server 2008 R2 web server (and confirmed via ssllabs.com).
- Confirmed that SP2 was, in fact, installed for .NET framework version 2.0.
- Added the two source files shown in the referenced KB article to our project (i.e., SecurityProtocolTypeExtensions.cs and SslProtocolsExtensions.cs)
- Entered the following line of code (from the KB article) to the project just above the API call: System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolTypeExtensions.Tls12;
Unfortunately, when running the application, I encounter the following error on the line of code shown in item #3 above:
System.NotSupportedException: The requested security protocol is not supported.
At this point, I am stumped. I'd especially appreciate any insights on how to move forward with this solution, but am interested in learning about any other approaches that you're aware of to allow an API call from an ASP.NET 2.0 application to utilize TLS 1.2. (Upgrading to a more recent version of the .NET framework is a last resort.)
Thanks in advance for your help!
We had to migrate to TLS 1.2 with our .NET 2.0 app and we didn't want to port the code to .NET 4.5/4.6. After a few days of research and after coming across this post we found the solution. This post references the wrong HOTFIX. To get TLS 1.2 working for .NET 2.0 on Server 2008 R2 you need this HOTFIX: https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework
It references 3.5.1 framework but ALSO works for 2.0 framework. Once the hotfix is installed you can either make registry changes on the server as indicated OR make code changes in your app to reference TLS 1.2 directly.
C# ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
VB ServicePointManager.SecurityProtocol = DirectCast(3072,System.Net.SecurityProtocolType)
For other OS's check out Troy Starr's post here: https://community.qualys.com/thread/16917-net-framework
Hope this helps
AS TLS 1.2 doesn't support asp.net 2.0. There is an alternate way to implement TLS 1.2 without migrating project from asp.net 2.0 to the latest/higher version. Following are the steps:
Below is sample code:
I realize this question is a bit old - but for the help of others this worked for us - and our Authorize.Net transactions now work with TLS 1.2 on our .NET 2.0 AbleCommerce application. [It looks like the transition deadline for production has been extended until February 28, 2018]
Environment: Windows Server 2008 R2, IIS 7.5, AbleCommerce 7.0.2 build 11659, CommerceBuilder.AuthorizeNet 7.0.9764.0
As per @JoeBoxer's answer above, this link did the trick - specifically setting the two registry keys for our x64 based system (the patch listed would not install on our box):
We also did this - as we did not have the entries for TLS 1.2 - but this alone did not fix the issue.
For anyone else that finds this thread, I was able to get TLS 1.2 to work on .Net 3.5, using the same steps (#1-#4) detailed in the original question above. Once I applied the patch to the Win 2012 server (which my shared hosting company was nice enough to apply), then added the line of code to enable TLS 1.2 before my API call, it worked right away: