WebSphere 8.5.5 FP27 & HCL Connections… beware!
HCL Connections 8.0 CR9 currently lists in its system requirements WebSphere 8.5.5 FP26 as its highest supported WebSphere version. However, I suspect that CR10 will try to support FixPack 27, which became available on April 21st. Brave companies might just update their servers with the latest fixpack, and usually that works just fine. This fixpack, however, has introduced changes in outbound TLS certificate hostname validation (PH58798). Btw, this fix is available as a separate fix for WebSphere 8.5.5 FP26, so if you’re on that version and tend to download the latest fixes, pay attention. What it does is if WebSphere will make a connection to https://example.acme.org, it will check if the certificate that example.acme.org returns contains example.acme.org in either the hostname or as a subject alternative name (SAN). If it doesn’t, you’ll be greeted with a message:
CWPKI0062E: SSL HANDSHAKE FAILURE: Host name verification error while connecting to host [example.ibm.com]. The host name used to access the server does not match the server certificate's [Subject Alternative Name [dnsName:notexample.acme.org,dnsName:example.acme.org]]. The extended error message from the SSL handshake exception is: [No subject alternative names matching example.acme.org found].
Also in a WebSphere-only Connections environment, you need to carefully check if your servers all do contain certificates which are valid for the hostname on which they are accessed. Especially your IBM HTTP Server’s certificate is an important one to check.
The biggest problem, however, are the certificates of the HCL Connections Component Pack, as those are created by HCL. They’ll look like:
subject=C = US, O = HCL, OU = CES, CN = opensearch-http
X509v3 Subject Alternative Name:
DNS:localhost, Registered ID:1.2.3.4.5.5
That is, most likely, not going to be the hostname on which you’re going to connect to, in this case, the opensearch cluster. As there’s no way, that I know of, to add your hostname as a SAN to this certificate, you will have to disable this TLS hostname check for all servers that are making connections to the component pack. In the environment where I ran into this, those were the Metrics servers.
The way to do that is described in this document, though there it’s described environment wide. You can go to the affected servers – Process definition – Java Virtual Machine – Custom properties and add:
Name: com.ibm.ssl.verifyHostname
Value: false
This is a workaround though. A proper solution will have to come from HCL.
