To configure Virtualize to configureVirtualize to work with services withservices deployed using HTTPS (HTTP via the SSL), you need to identify and register the certificate being used for the HTTPS connection from the server:

1. Close Virtualize if CloseVirtualize if it is currently open.

2. Identify the location of the server certificate used for the HTTPS connection.
3. Ensure that this certificate’s COMMON NAME parameter contains both the server’s machine name and the subdomain (for example, machine.company.com).

4. Copy the certificate to the following location:

   <virtualize_install_dir>/plugins/com.parasoft.xtest.libs.web_<virtualize_version_number>/root/lib

    
   This directory should contain a cacerts file in which the trusted certificates are stored.

5. Execute a command of the following format:
   keytool -import -alias <certificate_alias> -file <certificate_file> -keystore cacerts
   
   For example, if your certificate file is named test.cert, you would execute the following command from the<virtualize_install_dir>/plugins/com.parasoft.xtest.libs.web_<virtualize_version_number>/root/lib prompt:
   keytool -import -alias serverTrustCert -file test.cert -keystore cacerts
   This will import the certificate into the cacerts file with the alias "serverTrustCert".

   Info
   icon false title keytool path must be set
   Before executing keytool commands, you must first set your path to include Java's keytool executable. You can use the version of the Java binaries that ship withVirtualize.To add the included Java binaries to your path, open a command line prompt and enter the following before referencing the keytool: PATH =%PATH%; <Parasoft Test install dir>\<Parasoft Test version number>\plugins\com.parasoft.xtest.jdk.eclipse.core.<arch>_<java_version>\jdk\bin Note that <Parasoft Test install dir> references the location where Parasoft Test is installed (e.g., "C:\Program Files\Parasoft\Test" on Windows), <arch> refers to the architecture (e.g.,  win32.x86, linux.x86, win32.x86_64, or linux.x86_64), and <java_version> references the Java version included with your Parasoft Test installation.

6. When prompted to enter a keystore password, enter changeit.
7. When asked whether you want to trust this certificate, enter yes. You will then see a message indicating that the certificate has been added to the keystore.
8. (Optional) Verify that the certificate has been added to the keystore by entering the following command, then checking the file that opens:
   keytool -list -keystore cacerts

9. LaunchVirtualize
   

    and Launch Virtualize and try to access the service again.

...

Virtualize will then try to access any WSDL you specify, regardless of any problems with the certificate. However,Virtualize will Virtualizewill still try use the certificate while trying to send SOAP messages because it is required to do so.

...

If none of these procedures solve your problem, contact Parasoft in one of the ways described in Contacting Parasoft Technical Supportカスタマーサポート.

Debugging SSL Issues

Virtualize runs on a standard JVM. To show the SSL/TLS handshake details and help identify causes of SSL connection problems, enable JVM network and SSL debugging:

1. Open a command line console and navigate to the SOAtest installation directory.
2. Start the executable with the arguments:
   -J-Dssl.debug=true -J-Djavax.net.debug=all -consolelog

Virtualize will Virtualizewill start normallyas usual, but whenever SSL connections are made, debugging output will be printed on the console. If you wish to save the trace output to a file (for example, output.txt), you may append the following to the end of the command :

...

• Windows: http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
• Linux, Mac: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

Troubleshooting Client Authentication

If you are sending a request using client-side SSL (two-way) and the connections fails or the server returns a 401 (unauthorized) or 403 (forbidden) HTTP response, then the SSL debug log may contain the following:

*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
Warning: no suitable certificate found - continuing without client authentication

Check the CertificateRequest message, which should be printed earlier in the output, to determine why the client's certificate was considered unsuitable. This message contains details about the request received from the server:

*** CertificateRequest
Cert Types: RSA, ...
Supported Signature Algorithms: SHA512withRSA, SHA256withRSA, SHA384withRSA, SHA1withRSA, ...
Cert Authorities:
<CN=GeoTrust ...
<CN=VeriSign ...
<CN=Go Daddy ...
...

The CertificateRequest message declares requirements for selecting a client certificate based on the values specified in the Cert Types, Supported Signature Algorithms, and Cert Authorities fields. If the client certificate that was configured in the client's HTTP transport settings (under Parasoft> Preferences> Security> Client side SSL) does not match all of the requirements in the CertificateRequest message, then the client's certificate will not actually be used and the connection will continue without client authentication.

In some cases, the client's certificate matches one of the requested Cert Types and Supported Signature Algorithms, but not the Cert Authorities. This can happen if the keystore is missing the client certificate chain. The certificate chain is required for connecting the client's certificate to its issuer's certificate, then to any intermediate certificate authorities, and then to one of the Cert Authorities requested by the server. If the certificate chain is missing then the client's keystore file needs to be rebuilt to include the missing certificate chain.

You can use the openssl command line tool to rebuild the client's keystore. The following openssl example commands will rebuild a client's keystore if the certificate file is "ssl-certificate-file.crt", the cert chain is "ssl-certificate-chain.crt", and the certificate's key "ssl-certificate-key.key":

...