Tharmon (Customer) asked a question.

February 20, 2023 at 5:28 PM
BRX HTTPCMD is now receiving a SSL/TLS Handshake failure

I am using the BRX cpu to communicate with an API via the HTTPCMD. I am using the internal ethernet port to connect to the web. It has been working for several months now. Recently, it quit working and I am now receiving a SSL/TLS handshake error. The API source renew their SSL certificate around the time this stopped working. The API responds properly when I issue the string through my browser. Any idea on what might be happening? Maybe the certificate in the BRX is old?

 

  • 15 answers
  • 563 views

  • HOST_Greg (AutomationDirect)

    Taking the BRX to TLS v1.3 is not going to happen anytime soon. We're surprised that your API would force v1.3. Only recently have some APIs stopped allowing v1.0. Generally speaking, it's a negotiation. If the highest supported by one of the partners is v1.2, then the API will use v1.2. And for the record, it's going be a "heavy lift" for us to implement. The library we used for crypto hasn't been updated to v1.3. So, we're not sure it ever will be. We'll have to change crypto libraries, which is a major undertaking.

    Expand Post
    Selected as Best

  • ADC TechnologyGroup_05 (AutomationDirect)

    Time and Date:

    Using SSL/TLS adds a time sensitive nature to the communication. Make sure that the Time and Date on the BRX unit is correct. If not, update the Time and Date on the BRX unit and try the HTTPCMD instruction again.

  • Tharmon (Customer)

    I verified that the time & date was correct. Still having the problem.

  • ADC_PLC_ENG (AutomationDirect)

    Would it be possible for you to provide a wireshark of the coms on the plc ethernet port to show where the handshake is failing?

  • HOST_Greg (AutomationDirect)

    The HTTPCMD instruction does not use certificate validation. That only happens with email in the BRX. However, it might simply be timing out on the TLS encryption. You might try increasing the TLS Timeslice value. The default value is configured in the CPU Configuration but it can also be modified on the fly via DST68 ($TLSTimeslice). The value is in microseconds and the default is 1500.

     

    A Wireshark trace probably won't help much simply because TLS is encrypted.

    Expand Post

  • Tharmon (Customer)

    I increased the TLS timeslice several times all the way to the 20000 maximum. No change. One of our IT persons was questioning what version TLS you are using inside the BRX. The API I am trying to connect to recently changed it to 1.2

     

  • HOST_Greg (AutomationDirect)

    BRX uses TLS version 1.0 to 1.2. I'm now at a loss for what is happening. Are there settings for the TLS on your API (certificate, key, cipher, etc.)? I know next to nothing about that. Are there timing settings for your API (as the $TLSTimeslice on the BRX PLC)? I'm thinking your IT people might have the best chance of figuring this out, unless someone else on this forum has better ideas.

  • Tharmon (Customer)

    Thanks. It is defiantly related to the HTTPS. I can connect to another API that uses only HTTP. I will reach out to the API developers and see what their thoughts are. I will let you know if I find out something useful.

  • HOST_Greg (AutomationDirect)

    Since the $TLSTimeslice is really the only handle you have to pull in the BRX PLC, you might try this. Try making a new empty program/configuration for the BRX PLC making sure also that nothing is talking to it (HMIs, etc.). Then program two rungs at the top of $Main. Put your HTTPCMD on the first rung and an END on the second. This will give you the fastest scan time for the PLC. Then see if the HTTPCMD works jiggling the $TLSTimeslice as a test as well.

     

    This should give it the fastest TLS calculation time possible.

    Expand Post

  • Tharmon (Customer)

    It appears that the API switched from a version 1.2 to a 1.3 certificate. Is there any plans to update the firmware in the BRX to version 1.3 for the HTTPS?

  • HOST_Greg (AutomationDirect)

    Taking the BRX to TLS v1.3 is not going to happen anytime soon. We're surprised that your API would force v1.3. Only recently have some APIs stopped allowing v1.0. Generally speaking, it's a negotiation. If the highest supported by one of the partners is v1.2, then the API will use v1.2. And for the record, it's going be a "heavy lift" for us to implement. The library we used for crypto hasn't been updated to v1.3. So, we're not sure it ever will be. We'll have to change crypto libraries, which is a major undertaking.

    Expand Post
    Selected as Best
10 of 15

 

Did this information resolve your issue?