POST request goes through via insomnia app but not via VB.NET application on windows server 2012 R2 (using restsharp)

Question

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 18-Jul-21 23:30pm

Fydobas

Updated 19-Jul-21 0:27am

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Richard Deeming · Answer 1 · 2021-07-19T00:27:00

Solution 1

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.

Posted 19-Jul-21 0:27am

Richard Deeming

Comments

Fydobas 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?

Fydobas 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.

Fydobas 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.