Enabling TLSv1.2 in SOAtest/Virtualize

OmarR

Parasoft: Enabling TLSv1.2 in SOAtest/Virtualize:

Description:

SOA/Virt 9.10 and up now comes prepackaged with Java1.8 which has TLSv1.2 enabled by default. The Java version that comes with all the previous SOA/Virt versions does not. If you are using SOA/Virt 9.9.5 and below, there are two methods to enable TLSv1.2.

Solution:

Method 1 (Recommended):
The recommended and overall best solution is to run the tool with Java1.8. Java1.8 has TLSv1.2 enabled by default.

To do this, simply run your tool with the following command:
-Zjava_home "c:/Program Files/Java/jdk1.8.x_xx"

If you wish to use Java1.8 every time the tool is run (in Windows), please add the command to the end of the target field in the tool’s properties:

Method 2:
If you wish to use TLSv1.2, Parasoft ultimately recommends that you run SOA/Virt with Java1.8 (Method 1) as it enables the most modern version of the encryption protocol by default. If you are unable to access Java1.8, the following method will suffice while you receive authorization from management to install Java1.8 on your machine.

Since SOA/Virt is built upon the Eclipse framework, you will need to configure the JVM options in the eclipse.ini file located in the directory below. This directory will be similar for a Linux installation of the tool.

“C:\Program Files\Parasoft\Test\9.9\eclipse.ini”

1.Open the eclipse.ini file with notepad.

2.Add the following JVM options after -vmargs:

-Ddeployment.security.SSLv2Hello=false 
-Ddeployment.security.SSLv3=false 
-Ddeployment.security.TLSv1=false 
-Ddeployment.security.TLSv1.1=false
-Ddeployment.security.TLSv1.2=true

These options disable all deprecated protocols and enables only TLSv1.2.

We will also need to configure these TLS/SSL settings in the Java Control Panel located in the following directory:

"C:\ProgramFiles\Parasoft\Test\9.9\plugins\com.parasoft.xtest.jdk.eclipse.core.win32.x86_64_1.7.0.76\jdk\jre\bin\javacpl.exe"

3.Open Parasoft in Program Files.

4.Open Test

5.All current versions support TLS (including 9.6)

6.Open Plugins

7.Open com.parasoft.xtest.jdk.eclipse.core.win32.x86_64_1.7.0.76

8.Open jdk

9.Open jre

10.Open bin

11.Double click Javacpl.exe

12.The Java Control Panel (Javacpl) will open. Select the Advanced Tab and scroll down to “Advanced Security Settings” and check/enable the “Use TLS 1.2” option. Please uncheck/disable SSL, TLS1.0, and TLS1.1 to ensure that they do not over- ride TLS1.2.

Please note that if you are using a Windows OS, you will need to invoke eclipse.exe from here on in order for these new settings to take effect successfully. You can add eclipse.exe to your start menu or task bar for quick access. This is only required for Method 2 using Windows.

ashokan_moorthi

Me too faced the same issue (handshake failure) when try to run script from Parasoft tool. Then I have provided this command "-Zjava_home "c:/Program Files/Java/jdk1.8.x_xx" in the shortcut tab. After this script runs successfully.

But when I try to the same script from command line, i am getting again the "handsahke failure" error. Can you anyone explain me how to rectify this error??

OmarR

When executing your tests from CLI, you will need to add -Zjava_home as part of your command line.

For example:
"C:\Program Files\Parasoft\SOAtest\9.9\soatestcli.exe" -Zjava_home "C:\Program Files\Java\jdk1.8.0_131" -localsettings "C:\localsetting.properties" -data "C:\myWorkspace"

ashokan_moorthi

Thanks a lot.. Do you know how to format of this line( -Zjava_home "C:\Program Files\Java\jdk1.8.0_131") when execute the script from Linux server?

jakubiak

It's the same: -Zjava_home /usr/bin/java

benken_parasoft

Please note this should be the path to the JDK, not the java binary. For example:
-Zjava_home /usr/lib/jvm/java-8-openjdk-amd64

jakubiak

Correct - good catch @benken_parasoft

ashokan_moorthi

Thanks for the response. But i don't see either of these folders "/usr/bin/java", "/usr/lib/jvm/java-8-openjdk-amd64" in linux server. can you please tell me what to do??

jakubiak

You need to know where the JDK is installed on your particular system and point to that.

ashokan_moorthi

Thank you. I got the location and the scripts are running good.

benken_parasoft

Method 2

I'm not sure I like or totally agree with method 2. If you are running an old version of SOAtest that included Java 7 then you just set the "https.protocols" property. You can do this on the command line like this:
soatest.exe -J-Dhttps.protocols=TLSv1.1,TLSv1.2

benken_parasoft

Actually, looks like the "https.protocols" property does not entirely work in java 7 because of this:
https://bugs.openjdk.java.net/browse/JDK-8076153

A new property named "jdk.tls.client.protocols" is what's needed but that wasn't added until Java 7u95:
https://bugs.openjdk.java.net/browse/JDK-8076369

SOAtest 9.9.5 includes Java 7u76 which does not have the "jdk.tls.client.protocols" property. However, using a newer Java 7 with "jdk.tls.client.protocols" property should work as well. This may be safer than running SOAtest 9.9.5 or earlier with Java 8. SOAtest 9.10 is the first release with official support for Java 8. Issues that were fixed for SOAtest 9.10 to support Java 8 include the following:

• Certain XPaths failing to evaluate properly because of a bug with in Saxon: https://saxonica.plan.io/issues/1944 . SOAtest 9.10 uses a newer version of Saxon.
• Scripts originally written for Java 7's Mozilla Rhino were not working as expected in Java 8's Oracale Nashorn. SOAtest 9.10 improved support for Oracle Nashorn, enabling support for ES6 with compatibility enabled for older scripts that were originally written for Mozilla Rhino.

Athul

Hi All,

I am currently facing the same issue(handshake failure). Method One resolves the issue when we run the tool.

However, I am getting issues when I run the scripts from ALM tool. ALM VAPI scripts are hitting 'soatestcli'. And its not feasible to change all the VAPI scripts to hit the target command. Is there any other way I can configure soatestcli to hit java 1.8?

Please help.

@benken_parasoft @jakubiak

jakubiak

If you don't want to change the VAPI scripts, you could try something like this: create a batch or shell script that has the name "soatestcli.bat" or "soatestcli.sh". Rename soatestcli.exe to something else, like soatestcli-new.exe. Then call soatestcli-new.exe from your script, while adding the -Zjava_home argument to point to Java 1.8.

Athul

Hi jakubiak,

Thanks for the response.

I tried creating a batch/shell script as "soatestcli.bat" or "soatestcli.sh" and running the script from ALM. But the ALM is not able to find the file. As I have given the location as "var SOAtestExe = "C:/Program Files/Parasoft/SOAtest/9.8/soatestcli.exe" in the VAPI scripts.

Converting bat file to exe also doesn't seem to be a good option.

Please help with other options

jakubiak

Right - that makes sense since the file is explicitly referenced as a .exe file from the VAPI script. Sorry I missed that. Unfortunately I am not aware of any other way to set the JDK without modifying the VAPI script.

benken_parasoft

Method 2 from Omar's original comment should work if you are on Windows. Otherwise, you might also consider upgrading to the latest SOAtest release which runs with a Java 8 by default.

Athul

Thanks jakubiak and benken_parasoft!

Jhenderson

What about updating the java so that the soatestcli.exe program can run with tls1.2

benken_parasoft

TLS 1.3 is now available in Java 8 but is not enabled on client sockets by default. You can enable it as follows:

soatest.exe -J-Djdk.tls.client.protocols="TLSv1.3,TLSv1.2"