2

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.

JoshMc
  • 10,239
  • 2
  • 19
  • 38
J.E.Y
  • 1,173
  • 2
  • 15
  • 37
  • Strong crypto provider was not included and enabled by default until 1.8_162. At 1.8_151 they were included but not enabled. Are you sure the java security file on the working VM is identical to the non-working VM? Check for crypto.policy setting. – JoshMc Sep 02 '20 at 15:15
  • Thanks @JoseMc. My bad, I just noticed that on the server of process A, its script redefined the Java path to a higher version one: JRE1.8.0_191 so it didn't require the JCE setting tweak. I upgraded the JRE version on the server for process B and now it works. I am closing this thread. – J.E.Y Sep 02 '20 at 21:18
  • No problem, glad to help. I put my info into a answer, please accept. Please also add the details you put in your comment to the update of your question. – JoshMc Sep 02 '20 at 21:33
  • Thank you@JoshMc, answer accepted – J.E.Y Sep 02 '20 at 21:35

1 Answers1

2

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.

JoshMc
  • 10,239
  • 2
  • 19
  • 38