I received a call from a client that has Sametime 9.0.1 running in their environment and the issue was a user couldn’t login to the Sametime Proxy site any longer. I tested it and it was working fine, and at that point only one person had complained. We eventually determined that the issue was if the user was using the Chrome browser and they had just updated to the latest version (83 if you’re keeping score). Firefox and MS Edge worked fine. The issue was they were getting a timeout in the browser trying to connect to the Proxy website. Nothing was getting logged in the WAS logs and trying to use Dev Tools in the browser wasn’t any help either.
Double-checking the configuration, I found that the site was still responding with TLSv1.1 as an option, though Firefox connected at TLSv1.2. After hours, I changed the TLS QoS options for the ST Proxy to only use TLSv1.2 and that did not resolve the issue. I tried playing around with the cipher setttings in the TLS QoS settings, but that broke things even worse.
Looking at it further, WebSphere was using 8.5.5.11, which was the minimum required at the time of installation. Looking through the WebSphere fix list, I found some references to updates to ciphers in subsequent fixpacks.
I decided to try WAS fix pack 13 first (not for any numerological reasons) and installed that. And that resolved the issue. It looks like the ciphers included in the more recent fix packs are what Chrome wants and now users are able to login on their browser of choice.
Next, upgrading to Sametime V11 to get them on the “latest and greatest.”