Own .NET DLL: Error in PostAsync when DLL is used by Gupta: "no protected SSL/TLS channel"

Discussion forum about all things Team Developer 5.x and 6.x
isential
Germany
Posts: 14
Joined: 05 Jul 2017, 15:18
Location: Germany

Own .NET DLL: Error in PostAsync when DLL is used by Gupta: "no protected SSL/TLS channel"

Post by isential » 23 Nov 2018, 11:11

Own .NET DLL: Error in PostAsync when DLL is used by Gupta: "no protected SSL/TLS channel"
We use TD 6.2 SP5

We have included some .NET classes in a project with the .NET Explorer. We have developed these classes ourselves in C#. So far, everything ran without problems.

Now we have extended one of our .NET classes using "HttpClient" to call "PostAsync".

Code: Select all

private async Task<Token.RootObject> GetToken(string AuthenticationFile, string URL)
{
    HttpClient client = new HttpClient();

    // Verschlüsselte Datei mit den Anmeldetaten entschlüsseln und einlesen.
    string DecryptedData = Encryption.DecipherFile(AuthenticationFile);

    // Anmeldename und Passwort in jeweils getrennte Feldern speichern.
    string[] DecryptedArray = DecryptedData.Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);

    // Anmeldedaten für die Abfrage aufbereiten
    string Authentication = Convert.ToBase64String(Encoding.Default.GetBytes($"{DecryptedArray[0]}:{DecryptedArray[1]}"));

    // Standards im Header setzen.
    SetHeaderStandards(client);

    // Authentifizierungsmethode im Header setzen.
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Authentication);

    HttpContent Body = new StringContent("grant_type=client_credentials");

    Body.Headers.ContentType = new MediaTypeHeaderValue("application/x-www-form-urlencoded");

    var serializer = new DataContractJsonSerializer(typeof(Token.RootObject));
    var response   = await client.PostAsync(URL, Body); // <<=== EXCEPTION HERE!!!
    var stream     = await response.Content.ReadAsStreamAsync();

    return serializer.ReadObject(stream) as Token.RootObject;
}
If we use our extended .NET class from a C# application and call PostAsync, the call works without problems. On the other hand, if we include the class with the .NET Explorer in TD, the call to PostAsync causes the following exception:
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: no secure SSL/TLS channel could be created.
Is it possible that the Wrapper from Team Developer does not know TLS in the version the counterpart wants to use?

According to http://www.md-consulting.de/wp-content/ ... Matrix.pdf (page 5) TD6.2 supports a maximum of .NET 4.0. Does that mean that our .NET class uses .NET 4.0 when it is called by TD, and thus no recent TLS version, even though the class was compiled for the Framework 4.7.1?

What solutions are there for this problem without having to buy an update again for expensive money?

Thank you in advance!

René

thomas.uttendorfer
Site Admin
Site Admin
Germany
Posts: 198
Joined: 05 Mar 2017, 17:19
Location: Munich Germany

Re: Own .NET DLL: Error in PostAsync when DLL is used by Gupta: "no protected SSL/TLS channel"

Post by thomas.uttendorfer » 19 Jun 2020, 12:56

Hi René,

I got the exact same situation when using our .NET-Assembly vom TD 7.3.
When connecting to a https://... - address it tries to use TLS1.0 which is rejected by the server for good reasons.
When I call the exact same function from another c#-project it connects using TLS1.3.

So there is something in the TD-runtime which forces our assembly to use TLS1.0.

Did you find a solution?

Regards Thomas
Thomas Uttendorfer
[ frevel & fey ] Software-System GmbH
https://thomasuttendorfer.wordpress.com/

thomas.uttendorfer
Site Admin
Site Admin
Germany
Posts: 198
Joined: 05 Mar 2017, 17:19
Location: Munich Germany

Re: Own .NET DLL: Error in PostAsync when DLL is used by Gupta: "no protected SSL/TLS channel"

Post by thomas.uttendorfer » 19 Jun 2020, 13:02

Ok I found a solution in the net:

https://kevinchalet.com/2019/04/11/forc ... piling-it/

In Short:
The best practices paper lists a few options, but my favourite one is the one that consists in simply updating the configuration file associated with the application executable, as it's easy to do and doesn't impact anything else on the machine.

For that, locate the configuration file associated to the executable of the application you want to add TLS 1.2 support to: it's always named [name of the executable].exe.config. If there's no such file, create one. Once located or created, update its content to enable the compatibility switch required to support TLS 1.2:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
</configuration>
That worked for me.

Regards Thomas
Thomas Uttendorfer
[ frevel & fey ] Software-System GmbH
https://thomasuttendorfer.wordpress.com/

Return to “General Discussion”

Who is online

Users browsing this forum: [Ccbot] and 0 guests