Should rfc1323 be 1 (related to: Remote host closed connection during handshake)?
Ok, I'm dredging up old work items here as we're somewhat at a loss. Our RTC clients are getting variations of errors mentioned on ( comment 19 )
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=195587 Reading the APAR suggests we set rfc1323 to 0 to try alleviate this issue. However, examining the interface shows that it already is. Environment: AIX 6100-07-05-1228, CLM 4.0.7 in WebSphere 8.5.5.2 (base). Several IP on the same interface ( unchanged since forever ) The only new in our environment is CLM 4.0.7 all in WebSphere The interface is 1000/full and recommendations are for rfc1323 to be "on" (i.e. 1) Anyone have any wisdom to share ? cf: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=328380 |
One answer
I'm going to put some findings here as they won't fit in a comment.....
For those of us that know about SPoRT, I searched all the current SPoRT Tomcat logs for occurrences of the SSLHandshakeException and found them not too many days after we released our newly minted 4.0.7/WebSphere out to the wild. I then searched SPoRT logs from the older setups and only found the SSLHandshakeException on connection attempts to the one lone WebSphere we had at the time ( as far back as April 2014 ) In our WebSphere logs we can sometimes see complaints of distrust of an SSL certificate, but it does not reference the configured default certificate, rather the WebSphere created "default" certificate. Said another way, our NodeDefaultKeystore has 3 items: Automatically created ssl and root certificate(s) and an installed certificate which is configured on the SSL Settings as the server and client certificate. I verified this was also the case in our previous WebSphere configuration; now it is similar across all. Thus a possible cause is that on occasion, the wrong certificate is handed out and it doesn't pass muster. I think the solution would be to remove that "default" certificate and possibly the root certificate, but I am waiting to be advised via the PMR I created. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
I think you will need to capture network trace and analyze it to confirm whether the issue is the same as mentioned in comment 19 of WI 195587 .
My LPAR has the fix mentioned.
APAR= IV14297 SER=
TCP RETRANSMIT PROCESSING IS VERY SLOW
APPLIES TO AIX 6100-07
instfix -ik IV14297
All filesets for IV14297 were found.