Difference between the V4 cloud vs the V3 cloud with webservices

This morning I was testing some webservices on the v4 cloud and encountered some errors. At first I thought I made a mistake, but it seems their are differences in behaviour between the V4 and the V3 cloud. I created a new test project in SOAPUI and as always I copied the URL https://someURL/ws-doc/someWebservice?wsdl in SOAPUI. But it suddenly gives me the following error: Error loading [https://someURL/ws-doc/someWebservice?wsdl]: java.lang.Exception: Failed to load url; https://someURL/ws-doc/someWebservice?wsdl, 0 - Since we have the same webservice on multiple environments I tested the other environments. On V3 environments they all loaded without a problem and failed on all the V4 environments. I then did a manual import of the wsdl and tried to consume the webservice. On the V4 cloud they all fail with the following error: Error getting response,javax.ssl.SSL HandshakeException:Received fatal alert:handshake_failure But on the V3 cloud all just works. I did found this post on the forum recently: https://forum.mendix.com/link/questions/87697 So it seems I am not the only one having problems with the V4 cloud. Any pointers someone what is happening here. Did I miss something in the documentation? Regards, Ronald  
2 answers

What is likely the the issue here is that cloud v4 enforces the use of tls 1.2 which is badly supported by SoapUI. 

You can edit the startup script of SoapUI to enforce the right java version but this gave me an annoying popup and loads of warnings so what i did instead to enable this in SoapUI  is copy/paste the jre 1.8 folder into your SoapUI installation folder, this allows you to use tls 1.2.

e.g. copy C:\Program Files (x86)\Java\jre1.8.0_131 to C:\Program Files (x86)\SmartBear\SoapUI-5.3.0\jre

If you do this make sure that you copy the right bits version of java i.e. i use the 32 bits version of SoapUI so i also require a 32bits version of java.

*No guarantees that SoapUI will still work as before, but so far it seems to be okay for me.


I hit this problem too on using the V4 cloud. 

I would have followed Pieter's advice but I am on 64-bit and the folders didn't correspond - and actually I'm out of my comfort zone chopping about runtime folders. 

So I did some more googling and eventually came across this blog which gives an even simpler remedy that worked straightwaway for me: https://siking.wordpress.com/2016/02/18/another-way-to-fix-sslhandshakeexception-in-soapui/

All you have to do is rename the jre folder in the SOAPUI programme directory to jre.ignore so that it goes off and finds an uptodate version of the java libraries elsewhere in your system.  And if it doesn't work it's very easy to revert.