Skip to main content

The customer is on IFS Cloud 23R2 SU8.  They have the North American Freight Interface mod that works with Pacejet.

 

When the TLS is v1.3, Pacejet gets the call.  When the TLS is v1.2, the call fails to leave the network.  Attempts to permanently make the TLS v1.3 have failed.  And the system keeps switching between TLS v1.2 and v1.3.  No pattern for the switch has been found. 

Our questions are:

  1. Is anyone else experiencing this issue?
  2. If so, what have you done to resolve it?

 

*crossposted in IFS Cloud-New Customers group

 

Hi @cmdriordan,

Are you able to expand on what the functional issue is?  Is this an issue when the user attempts to Rate Shop or when they are sending a Shipment to Pacejet?

I’ve worked with two different customers who are using the IFS Cloud Freight Integration, one of which is on 23R2 SU6.

Admittedly, TLS protocol is a little out of my wheelhouse, but when I perform a quick test, it appears IFS cloud is leveraging v1.2 and Pacejet is leveraging v1.3.  The messages are passing back and forth without issue.  

Hi @astfarazt 

I can add some details - the “FRTINT Process Shipments at Pacejet” background job, that is polling Pacejet to retrieve shipment tracking information, errors multiple times a day. We were able to determine that the background job always fails when TLSv1.2 is used. If TLSv1.3 is used, the background job runs successfully. Typically what we see is the background job gets stuck and eventually times out. During this time, not only is shipment info not received back from Pacejet to IFS but shipments being sent from IFS to Pacejet also fail.

Also, not sure if it matters but this customer is on IFS Cloud 23R1 SU8, not R2, as initially reported.

We’ve tried a few things to try and force it to use TLSv1.3 but, so far, nothing we’ve tried has worked. It still flips back and forth between using v1.2 and v1.3.

Reply


Terms & ConditionsCookie settings