TLS stops working at POA 18.4.2

 

Hi.

Recently updated a customer that was still  running GW18.4.1 to 18.4.2. 

A few days later, they called me, and GW Web stopped working with "Unable to communicate with server", and GMS also showed communication errors with one POA (which is the default one configured in GW Web).

After a little digging, I found out that while all posrts of the POA (including 7191) were listening, I would not get a certificate when trying to connect to them:

openssl s_client -connect gw01.undisclosed.dom:7191
CONNECTED(00000003)
140188125603472:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 293 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1674562396
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

Now, as we all know, in GW18.4.2, soap runs on it's own POA process now, and that process is also listening on port 17191 (when the main soap port is configured for 7191):

Oddly enough, I still *could* get a proper certificate on port 17191, but not on 7191.

A simple restart of the problem POA fixed the issue, but this is not good. There has been nothing in the poa logs that I'd identifiy as an error. The POA also wasn't restarted, it simply stopped properly handling TLS in the middle of the day for no apparent reason.

Is this a known one? Anybody else?


Top Replies

  • 0  

    One thing I forgot: I also took a lan trace between gwweb and the problem POA, and the POA simply responded with a TCP connection RST to the "CLIENT HELLO" from gwweb. So not even a handshake error or something int hat regard, it simply actively reset the connection when the other side attempted to negotiate TLS.

    Also, I initially attempted to disable and re-enable SOAP on the problem PO, and despite the logs show "SOAP stopped", it was still listening on 7191, and the issue stayed the same. Only fully restarting the POA fixed it.

    LAst but not least: Running on OES2018SP3 fully patched.

  • 0   in reply to mrosen

    Hey Massimo,

    did you change the loglevel to verbose in POA? Maybe then you will see more infos...

  • 0   in reply to mrosen

    Massimo - would you open a case on this one?  Thanks Pam

  • 0   in reply to Gabriel Gheorghiu

    No GW agent that I ever touched runs in anything other than verbose logging.

  • 0   in reply to probello

    As long as I can't dupe it (and so far I can't), I don't think that will do any good.

  • 0   in reply to mrosen

    we Must have ALL the data

    because it can't be recreated later to answer "what happened"

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0   in reply to KonecnyA

    Like I said, there is no data. There's nothing in the (verbose) logs that would indicate an issue. The POA while in that state didn't log anything when I attempted to use SOAP. Which makes sense, as this is a TLS communication error that happens *before* the POA even sees it.