- Revenera Community
- :
- FlexNet Embedded
- :
- FlexNet Embedded Knowledge Base
- :
- How To Diagnose SSL/TLS Negotiation Problems
- Mark as New
- Mark as Read
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
How To Diagnose SSL/TLS Negotiation Problems
How To Diagnose SSL/TLS Negotiation Problems
Summary
When the FlexNet Operations backoffice removes support for older versions of TLS, communication between the backoffice and .NET XT clients may be disrupted. The cause for the disruption has been traced to .NET XT client applications being built against .NET framework versions older than 4.6. The problem with building against these older versions is that, by default, the .NET communications will utilize the older version of TLS.
This article describes how to diagnose if the communication failure is caused by the TLS version by using a packet sniffer. In this example, we will use the Wireshark packet sniffing tool.
Configuring the Wireshark packet sniffer
We will use Wireshark to see the TLS communication between the client application and backoffice server. In order to do this, we will need to filter on the following:
- The client's ethernet adapter (if unsure which to use, select all of them)
- The protocol: TLS
- Communications to and from the target ip address
Using Wireshark
The client application uses the following url to communicate to FlexNet Operations:
https://<tenant>-uat.flexnetoperations.com/operations/deviceservices
Using nslookup or ping for the hostname, you can obtain the communications ip address
NOTE: In the example below, internal ip addresses have been obfuscated or modified for security reasons.
For the example, the ip address to use is 64.12.34.56.
Next you will need to set up Wireshark to filter for this ip address communication and the TLS protocol. To do that, you specify "(ip.src== 64.12.34.56 or ip.dst == 64.12.34.56) and tls" as the display filter. Do not set this as the capture filter. Then select the appropriate ethernet adapters.
Click the button with the shark fin to start capturing.
Below we have an example using C# XT client (using .NET framework 3.5) sending a capability request to the FlexNet Operations url.
Notice the client specifies using TLS 1.0 and the failure to communicate with the backoffice.
If we update the client application to use .NET framework 4.6 or greater, and send another capability request to FlexNet Operations, we observe the TLS version is 1.2 and the communication is successful.