Problem using TLS12/13 for connection with webService

AitorEG

Hi everyone,

I am working with NAV 2018, installed windows server 2012 R2 standard.

I have created a a few years ago an integraion with an external webService. it is working perfectly, but they are changing the security protocol to use TLS 1.2 or 1.3. The system administrators from the webService gave me a new URL for testing that we can connect via TLS1.2 or higher. I'm jsut changing the URL in my development, and I get this error(filtering traffic with fiddler):




This is the error in NAV:




"Error in call System._ComObjectSend with the message: Cannot finde the specified resource"

The code is like this:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls13;
  
 
  IF ISCLEAR(XMLHTTP) THEN
    CREATE(XMLHTTP,FALSE,TRUE);
  XMLHTTP.open('POST', 'https://express5.xxx.com/expressconnect/shipping/ship',0,User,PSWD);
  XMLHTTP.setRequestHeader('Content-Type: ', 'application/x-www-form-urlencoded');
  XMLHTTP.setRequestHeader('Host','express5.xxx.com');
  XMLHTTP.setRequestHeader('SOAPAction', 'https://express5.xxx.com/expressconnect/shipping/ship');
  
  XMLText := 'xml_in=' +  XMLDocDotNet.OuterXml;
  XMLHTTP.send(XMLText);

It worries me that may be it will be an issue with the server, or any setting of it..

Any hint? Thank you all

AitorEG

Hello,

I've changed the develompnet to use DOTNET instead of automation. This is the new code:

ServicePointManager.SecurityProtocol(SecurityProtocolType.Tls13);
HttpWebRequest := HttpWebRequest.Create('https://express5.xxxx.com/expressconnect/shipping/ship');
credentials := credentials.NetworkCredential(User,PSWD);
HttpWebRequest.Credentials := credentials;
HttpWebRequest.Method :='POST';
HttpWebRequest.Accept := 'application/x-www-form-urlencoded';
HttpWebRequest.ContentType := 'application/x-www-form-urlencoded';
StreamWriter := StreamWriter.StreamWriter(HttpWebRequest.GetRequestStream);
StreamWriter.Write(XMLText);
StreamWriter.Close;
StreamWriter.Dispose;
HttpWebResponse := HttpWebRequest.GetResponse;
response := HttpWebResponse.ToString;

And I get this error:

"...cannto create a secure channel..."

Any tip?

Remco_Reinking

tell dotnet it should use tls1.2 using this line of code:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;

with these variables:
- ServicePointManager : System.Net.ServicePointManager
- SecurityProtocolType : System.Net.SecurityProtocolType

AitorEG

Remco_Reinking wrote: »

tell dotnet it should use tls1.2 using this line of code:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;

with these variables:
- ServicePointManager : System.Net.ServicePointManager
- SecurityProtocolType : System.Net.SecurityProtocolType

Thanks for your answer. As you can see in my code, I've added that in the first line. But I've changed it to the line you are indicating, and the error still the same...

I'm starting to get desperate., I doubt if it might be an issue in the server or something...

AitorEG

Must sayt that using the code I wrote first, or this last one (DOTNET instead of automation), I get the same failure in the fiddler

ftornero

Hello @AitorEG,

Have you try to connect outside NAV with something like Postman o Powershell, so you can see if the webservice is working.

Regards.

AitorEG

Hello @ftornero

THis is what I get using SOAPui, I don't know how to test this type of WS in the correct way, but seems that connection is correct...

AitorEG

Thehe web service is correct:

ftornero

Hello @AitorEG,

Ok, where are you running your .NET vars, server or client ??

Because if it is on server maybe the server don't have access to the web service and the client have.

Regards.

AitorEG

Hello @ftornero . All the .NETs where setup to RunOnClient = yes. Anyway, seems that I get the same result running with "yes" or "no"

ftornero

Hello @AitorEG,

Well, assuming that the tests with Postman and NAV have been done in the same computer, I would check firewalls, antivirus, etc.

Regards

AitorEG

Hi @ftornero ,

Both test have been made in the server where NAV is installed. So, if in SOAPui works, I must assume that TLS1.2 is activated on the server?
I

ftornero

Hello @AitorEG,

Yes, but maybe you have a rule in the firewall blocking the access to finsql.exe.

I say that because otherwise it must works the same way that work in Postman.

Regards.

AitorEG

Thanks @ftornero ,

But how can that be possible? I mean, exactly the same development is working against a different URL.. We have jsut change the destination URL, because the service provider is doing tesst to see if we are able to create TLS12 comunications...

ftornero

Hello @AitorEG,

Was the other URL an https too ?

Regards

AitorEG

Yes @ftornero , it was also HTTP

AitorEG

This is calling the old URL:




And this to the new one:

ftornero

Hello @AitorEG

In both cases you are using TLS1.2, but looks like in the new one you have an authentication issue.




Regards

AitorEG

Thanks @ftornero .That's what I'm thinking about, but that schannel native error... I don't know.

Thank you for your tips, really wellcome.

pd: good job with TBAI by the way

ftornero

Hello @AitorEG,

I usually do the test with Powershell to check that everything is ok before do the same in NAV.

And regarding TBAI, it is still a work in progress. Are you developing it too ?

Regards.

AitorEG

Hello @ftornero . My knowledge in PS is limietd, I wouldn't know even what to check,,,
With TBAI we have started with the basics, but we don't know if we have enough resources to make such a huge development. We'll see..

AitorEG

More than desperate....

ftornero

Hello @AitorEG,

In Powershell is pretty much the same code that you already has wirtten in NAV

$request = 'THE XML TO SEND'

$URL = "THE URL"
$username="THE USERNAME"
$password="THE PASSWORD"

$uri = New-Object System.Uri $URL

$req = [System.Net.WebRequest]::Create($uri)
$req.Method = "POST"        
$req.ContentType = "text/xml"
$SOAPAction = 'THE SOAPACTION'
$req.Headers.Add("SOAPAction", $SOAPAction)

$credentials = New-Object System.Net.NetworkCredential($username,$password)
$req.Credentials = $credentials

$writer = New-Object System.IO.StreamWriter $req.GetRequestStream()
$writer.WriteLine($request)
$writer.Close()
$response = $req.GetResponse()
$receiveStream = $response.GetResponseStream()
$reader = New-Object System.IO.StreamReader($receiveStream, [System.Text.Encoding]::UTF8)

Write-Output $reader.ReadToEnd()

And about the TBAI send me a private message and we can talk.

Regards.

AitorEG

Hi @ftornero ,

Sorry, but I got more info that could help to understand the problem. First of all, wih the PS script shown before, if i call he old URL, works correclty, as I can see on the fidler.
My next step has been to try to see the soap call into fidler. Fidler wasn't filtering calls from SOAP, so looking into the net, I found to try to change this value from authomatic to:



and....



Seems that the conecction is stablished, but fails when sending the message...

I don't know if this will help to figure which is the error, but any new information is welcome...

ftornero

Hello @AitorEG,

Looks like your are sending the request XML like a parameter in the URL, usually is not the way with SOAP.



Regards

AitorEG

hi @ftornero

We are testing against a rest API.
Anyway, is I use your example script against the old URL works correctly, but against the new..




And same adding:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Must say that all this test are donde in the server where NAV is installed, in my laptop for example, I'm not having any error with the scripts.
I'm running out of ideas, but with this last test with the PS script, seems to be something about the server itself, no?

ftornero

Hello @AitorEG,

Yes, If with your laptop you don't have any error connecting to the new webservice then the problem is in your server.

Regards.

AitorEG

Thanks for all your tips @ftornero . I was expecting that from the very beginning, but as you know, a research is mandatory before talking about the server...

We will try to talk about this with the system administrator of our customer, hopefully we willl fidn a solutions as soon as possible.
Thank you again!