Click here to Skip to main content
15,307,117 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am creating a VB.net application which is required to use some data retrieved from an API, via a POST request. Said POST request appears to be working fine on my end (a Windows 10 machine), both via the Insomnia REST client app and my own application. However, on a client's machine (using Windows Server 2012 R2), the same request, while executing as usual when ran on the Insomnia client, fails when ran from my application with the following error message:

"The request was aborted: Could not create SSL/TLS secure channel"

Here is the RestSharp code I am using, as generated from the Insomnia client's code generator


var client = new RestClient("my_api_endpoint");
var request = new RestRequest(Method.POST);
request.AddHeader("Content-Type", "multipart/form-data; boundary=---011000010111000001101001");
request.AddCookie("PHPSESSID", "1dhpd76ip6o6hhle4ffg9tp30m");
request.AddParameter("multipart/form-data; boundary=---011000010111000001101001", "-----011000010111000001101001\r\nContent-Disposition: form-data; name=\"username\"\r\n\r\nmy_user\r\n-----011000010111000001101001\r\nContent-Disposition: form-data; name=\"password\"\r\n\r\nmy_password\r\n-----011000010111000001101001\r\nContent-Disposition: form-data; name=\"isbn\"\r\n\r\nmy_product_code\r\n-----011000010111000001101001--\r\n", ParameterType.RequestBody);
IRestResponse response = client.Execute(request);


What I have tried:

Adding any combination of the following three lines before the request is executed (I tried many different variants of the second line, none worked)

ServicePointManager.Expect100Continue = True
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
ServicePointManager.ServerCertificateValidationCallback += Function(sender, certificate, chain, errors) True


Adding or reordering cipher suites to the client's server machine using IISCrypto, after using https://www.ssllabs.com/ssltest/ to determine the suites I needed to add/reorder.

However, none of the aforementioned seemed to solve the issue.
Posted
Updated 19-Jul-21 0:27am

1 solution

Transport Layer Security (TLS) best practices with the .NET Framework | Microsoft Docs[^]

If you're targeting .NET Framework 4.7 or later, it will use the system's enabled protocols by default. You don't need to touch the ServicePointManager.

For 4.6.x, you need to set an AppContext switch to enable this behaviour.

For 3.5 - 4.5.2, you need to set a registry key. You will also need a hotfix if you're using 3.5 and haven't already installed it.

NB: Your ServerCertificateValidationCallback is a security vulnerability waiting to happen. Any site will be able to impersonate the service you're trying to call with any invalid certificate. If you control the endpoint you're calling, you should make sure it presents a valid certificate, and remove the callback. Otherwise, use the data in the callback parameters to verify the invalid certificate used by the service.
   
Comments
Member 11871860 21-Jul-21 2:53am
   
Appears that none of these suggestions worked - I am still facing the same issue ("The request was aborted: Could not create SSL/TLS secure channel"). Reminder: the server is running Windows Server 2012 R2. Could it be an operating system issue? Albeit keep in mind third-party clients (Insomnia REST, Postman) work fine. In addition, the same application works perfectly in Windows 10 and newer Windows Server.
Richard Deeming 28-Jul-21 4:52am
   
It's almost certainly a mis-match between the protocols / ciphers enabled on the server, and those being tried by your application.

Since other applications work on the same client as your application, the assumption is that the OS has the correct protocols and ciphers enabled.

The fact that your code can reference the SecurityProtocolType.Tls12 enum member means you must be using .NET Framework 4.5 or later. Which version are you actually using, and which steps from the linked article did you try?
Member 11871860 29-Jul-21 3:54am
   
As mentioned above, I ran the same test you mention on the comment below for the API I am trying to access and found out the cipher suites the API's server was supporting were not even included on the list of cipher suites available on the client's server. I tried adding the options mentioned in the test but that did not work - I still got the same error message.

As for the .NET framework, I am using 4.7.2 - I also tried downgrading down to 4.5.0 but it did not help. It is mentioned in the article that in that case, I should not change anything in my code, yet naturally that was not the answer - so I tried the other solutions as well. Neither setting the AppContext switch nor setting the registry key seemed to solve the issue, however.

After communicating with the API provider, they suggested the "newer cryptographic protocols do not work with Windows Server 2012 R2 and the client needs to update their OS". However, I strongly believe that there should be a solution to the issue - if there was an issue with the OS, the Insomnia REST client would return a similar error, not work correctly.
Richard Deeming 29-Jul-21 4:01am
   
Did they tell you which protocol and cipher suites they're using? Or did the Qualys SSL Server Test tool work?

You can find the list of available cipher suits for 2012 R2 in Microsoft's documentation:
TLS Cipher Suites in Windows 8.1 - Win32 apps | Microsoft Docs[^]

But as you say, if the OS didn't support it, the request should also fail in Insomnia on the same server.
Member 11871860 29-Jul-21 6:24am
   
I used the ciphers that were mentioned in the Qualys SSL Server Test tool.
Namely, the three ciphers below that Qualys mentioned were supported by the server were completely missing from the cipher suite list when I checked using the IISCrypto tool (using TLS 1.2, as the .NET Framework I am using does not support TLS 1.3).

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

I added them in that specific order as the first three suites using IISCrypto but it did not seem to work. They're not on the list you linked above, but none of those mentioned in the Qualys test are.


Richard Deeming 28-Jul-21 4:54am
   
NB: If the server you're trying to access is public, you can use the Qualys SSL Server Test[^] page to find out which protocols and ciphers the server supports, which might help to narrow down the problem.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS


CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900