IBM Connections Files plugin not working within Notes when TLSv1.2 is enforced

After enforcing TLSv1.2 on our internal Connections 5.5 servers the Files plugin would not work.

In the IHS logs I would see errors such as

[warn] [client 80.229.222.90] [7f9a700a7060] [21173] SSL0222W: SSL Handshake Failed, No ciphers specified (no shared ciphers or no shared protocols). [xx.xx.xx.xx:62899 -> xxx.xxx.xxx.xxx:443] [09:45:11.000102454] 0ms

Enabling trace on IHS showed that the protocol being used was TLSv1.0 which matched Wireshark output. Oddly Status Updates and Activities plugins use TLSv1.2.

“GET /files/basic/api/library/4a7a7240-8f68-44d8-9447-7410cc2bb467/feed?pageSize=300&acls=true&sI=601 HTTP/1.1” 200 168770 TLS_RSA_WITH_AES_128_CBC_SHA TLSV1

I then had to allow TLSv1.0 until I could get an explanation from IBM.

Finally IBM came back with the following two lines to be added to the notes.ini.

SSL_DISABLE_TLS_10
DISABLE_SSLV3=1

Now in access_log I see TLSv1.2 being used.

“GET /files/basic/api/library/4a7a7240-8f68-44d8-9447-7410cc2bb467/feed?pageSize=300&acls=true&sI=601 HTTP/1.1” 200 168770 TLS_RSA_WITH_AES_128_GCM_SHA256 TLSV1.2

IBM also suggested that I check the following was set in plugin_customization.ini, which it was.

com.ibm.documents.connector.service/ENABLE_SSL=true

The notes.ini values have been pushed out to my colleagues via Domino policies.

Old version of Notes Java breaks IBM Connections Files plugin when TLSv1.2 is enforced

I had to raise a PMR on a problem I and others in my company had with the Notes client. After enforcing TLSv1.2 in Connections 5.5 using the following configuration in httpd.conf the Files plugin would not work but the Activities and Status Updates plugins would.

SSLEnable
SSLProtocolDisable SSLv2 SSLv3 TLSv11 TLSv10
SSLCipherSpec TLSv12 +TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 +TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 +TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA +TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 +TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 +TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 +TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

I kept seeing the following screen and clicking “try again using existing options” did nothing.

Whilst clicking on “try again using existing options” I would see the following in IHS.

[Wed Mar 29 14:30:41 2017] [warn] [client xxx.xxx.xxx.xx] [7f9a480ec800] [30453] SSL0222W: SSL Handshake Failed, No ciphers specified (no shared ciphers or no shared protocols).  [xxx.xxx.xxx.xx:49296 -> xxx.xxx.xxx.xx:443] [14:30:41.000571168] 0ms

The SSL certificate is at 4096 bits and I had previously replaced US_export_policy.jar and local_policy.jar with the unrestricted policy jars so that was not the problem.

I found, oddly, that if I swapped to the IBM Sametime Meetings plugin first and then changed to Files, my files would load…. Also, if I ran Fiddler and restarted my Notes client but went directly to Files it would load too. Weird.

I had a screen share with Elizabeth Hecht and Jacqueline Chewens to show them the odd behaviour and they too were baffled. Liz came across a thought of the version of Java being used may not be allowing connectivity to Files and asked whether I had applied the Java update for FP6? Not having so much focus on Notes and Domino of late I told her I wasn’t even aware that previously you were supposed to update the version of Java being used by the Notes client.

To test this I updated Notes to FP8, which bundles in the Java update and low and behold the Files plugin started working. Also, there was no need to replace the jars with the unrestricted ones!

The version of Java now in play is as follows.

c:\Program Files (x86)\IBM\Notes\jvm>java -version
java version “1.8.0_121”
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode, sharing)

BTW – if Connections enforces SSL then you need to make sure that com.ibm.documents.connector.service/ENABLE_SSL=true is set in the plugin_customization.ini.

Sametime and NETWORK_SPRAYER_ADDRESS

I am planning to move our internal servers to the latest Sametime servers which are using  a different LDAP. I have constructed managed-community-configs.xml to redirect the clients to the new Community server sitting behind a DNS alias of sametime.acme.com whilst resetting the client and automatically signing them in to the new servers using Notes client single sign on but I kept having a problem when the client tried to log in to the new Community server.

I found that the client wouldn’t log in to the new server using the Notes single sign on method. This process sends the Notes ID to the Community server (or another Domino server). Domino then checks the Notes ID and then sends back an LtpaToken to the Notes client. The Notes client sends the same LtpaToken to the Community server which Sametime uses to authenticate the user.

This really frustrated me. I couldn’t work out why this was happening. I enabled Wireshark trace and compared a successful connection to another server with the failing one. I found that the packets were similar up until a point and then there was a FIN, ACK. This normally means one of the host terminates the connection which seemed odd.

I spoke with a colleague who is a goldmine of Domino knowledge and after a bit of experimentation we found that when I try opening sametime.acme.com in the Notes client (Ctrl + O) it failed whilst it worked when opening a database for the actual Domino server ie sametime004.acme.com worked.

When putting  a trace on the client I got the following:

Using address 'x.x.x.x' for sametime.acme.com on TCPIP
Connected to the wrong server Sametime/Servers/ACME using address x.x.x.x
Using address 'sametime.acme.com' for sametime.acme.com on TCPIP
Unable to connect to sametime.acme.com on TCPIP (The server is not 
responding. The server may be down or you may be experiencing network 
problems. Contact your system administrator if this problem persists.)

The server document does not have sametime.acme.com listed but sametime004.acme.com since that is the name of the Domino server. I changed the name of the fqhn on the basics tab to sametime.acme.com and restarted the server. Now, I could access a database using sametime.acme.com.

Going back to the Wireshark trace it looks like the FIN, ACK was because the Notes client was stopped from connecting to the Domino server due to the different names.

My colleague then came up with NETWORK_SPRAYER_ADDRESS. This notes.ini value is described here.

When a notes client connects to a Domino server part of the protocol 
exchange includes the notes client telling the server what it thinks 
the server's name is.If the names do not match, the connection is 
terminated. This mechanism is part of the code which supports partitioned 
servers running on the same IP address. However, because of this 
algorithm, we cannot use network sprayers in front of Domino servers. 
When a Notes client uses a Network Sprayer address as a Domino server 
address, the network sprayer may make the final connection to any of 
the Domino servers behind it. If the name supplied by the client is not 
the Domino server name of the selected server, the connection will be 
broken. This fix provides a mechanism to skip the server name checking 
to allow this configuration to work.

I stopped Domino, added NETWORK_SPRAYER_ADDRESS=* and then started Domino. On testing I could open a database using sametime.acme.com and sametime004.acme.com.

When testing managed-community-configs.xml my Notes client was signed in fine to the new Community server!

The crux is that the problem was because I was using a DNS alias to connect to Domino which didn’t match the actual Domino server name. Sametime doesn’t care normally but the Notes client obviously does. Using NETWORK_SPRAYER_ADDRESS tells Domino not to care and to allow the client to connect.