As per the firm's policy we are required to encrypt communication channels b/w our client processes with MQ server. In our distributed system, we have a few Java processes required to establish connection with MQ. Let me say, process A and B.
A and B run on different virtual machines. They have EXACTLY the same environment including JRE of same version(1.8.0_151-b12), same dependencies, same JCE extension files. We added ssl related JVM parameters to the launching scripts of each process, such as
-Djavax.net.ssl.trustStore
-Djavax.net.ssl.trustStorePassword
-Djavax.net.ssl.keyStore
-Djavax.net.ssl.keyStorePassword
the corresponding trustStore and keyStore files are in place and properly referred to.
A works fine and we observed the SSL handshake and encrypted messages. However, process B failed with messages such as:
ignoring unavailable cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
...
Caused by: java.lang.IllegalArgumentException: Cannot support
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with currently installed providers
I did spend time checking online and one relevant post is from here : it suggested downloading and upgrading JCE files - the thing is that I already have JCE files (unlimited) installed and those are the same for both processes. I don't think JCE files is the root of the problem.
My question is, does the MQ team also have to install JCE files as well, in order for the client to establish SSL connection? Is the configuration on my end completed, anything I might have missed?
Update: problem solved. See my comments below.
Unlimited Strength Jurisdiction Policy Files were not included and enabled (crypto.policy set to unlimited) by default until 1.8.0_162. At 1.8.0_151 Unlimited Strength Jurisdiction Policy Files were included but not enabled.
Please check that you in fact running Java 1.8.0_151-b12 on both VMs, if you are then make sure the java security file crypto.policy setting on the working VM is identical to the non-working VM.