Dealing with SSL secured webservices –and two-way (mutual) SSL in particular can be hard to debug when something goes wrong. The SSL handshake failures can be daunting, especially when it seems that everything is set up correctly. Within the integration world the marvellous tool SOAPUI is the Swiss Army Knife of testing. The saying is that if it doesn’t work in with SOAPUI, then it is broken. However, lately I’ve found an unexpected troublemaker which adds an extra variable to the debuging headache.
Let’s say you’d need to connect to some two-way SSL secured webservice. In my case it was an Oracle OSB 11g set up that needs to connect to a two-way SSL secured webservice with SHA2-certificated through a remote proxy. It simply didn’t work: the SSL handshake always failed although the set up was correct. After a while the working SOAPUI set up all of a sudden stopped working also. It seems that the Java JDK had changed: I’d entered the realm of the SUN Java JDK 1.6.0_21. The SUN 1.6.0_21 untill 1.6.0_28 seems flawed. I couldn’t get the SSL handshake to work. Simply installing the (at the moment) latest JDK 1.6.0_29 made everything work. Immediately.
So if you are faced with SSL handshake errors and you simply can’t explain them because everything seems right: check your JAVA_HOME to see which version you are running. Keep away from SUN 1.6.0_21 – SUN 1.6.0_28, and upgrade if necessary. In my case, simply editing the <DOMAIN_HOME>\bin\setDomainEnv.cmd and setting the correct Java version did the trick!
Whitehorses is specialized in succesfully implementing Oracle SOA solutions: BPEL, OSB, WebLogic & BPM