Page History

...

Configuring SSL (HTTPS) for the Virtualize Server

If the AUT is deployed to an environment that communicates over SSL, you will need to make sure that the Virtualize server can communicate with the AUT and its dependencies. There are several options:

1. (Preferred) Create a certificate for the Virtualize server, sign it with a certificate authority that is trusted by the AUT, and issue it for the host where the Virtualize server is installed. With this option, you don’t need to make any changes to the AUT.
2. Configure Virtualize Server with a generated (possibly self-signed) certificate and add it to the trust store of the AUT.
3. Add your actual server certificate to Virtualize. This option assumes that access to the server certificate and keys is possible and that changes to the AUT are difficult or should be avoided. However, this option may not be possible if the certificate was signed for a hostname other than the hostname where Virtualize is deployed.
4. Disable certificate trust in the AUT. The AUT would still connect over SSL but trust any server (such as the Virtualize server) without validating its certificate or its trust paths.
5. Set up a frontend like a load balancer that provides SSL and forwards to the Virtualize server.

For the AUT to accept a certificate/private key pair, you generally need—at minimum—a self-signed certificate/private key pair whose common name (CN) parameter matches the fully-qualified name of the server. For example, if your Virtualize server URL is http://myserver.mycompany.com, the CN parameter should be "myserver.mycompany.com".

In any case, Virtualize can be configured to accept incoming HTTPS connections on port 9443 (default SSL connector) or another port. 

...

To secure communication between the Virtualize server and your AUT (Application Under Test), you need to configure HTTPS using a trusted certificate and its corresponding private key. This can be a certificate issued by a trusted certificate authority (CA), or a self-signed certificate. Note that if you use a self-signed certificate, you must ensure that all client applications (such as your AUT) trust this certificate. For Java-based clients, this typically involves importing the certificate into the Java truststore (cacerts).

There are several options to setup SSL:

1. (Preferred) Use a CA-Signed Certificate. Create a certificate for the Virtualize server, sign it with a certificate authority that is trusted by the AUT, and issue it for the host where the Virtualize server is installed. With this option, you don’t need to make any changes to the AUT.
2. Use a Self-Signed Certificate. Configure the Virtualize Server with a generated self-signed certificate and import it into the AUT's truststore (such as the cacerts file used by Java clients).
3. Reuse the Real Server's Certificate. Install your real server certificate and private key on the Virtualize server.  This option assumes that access to the server certificate and keys is possible and that changes to the AUT are difficult or should be avoided. However, this option may not be possible if the certificate was signed for a hostname other than the hostname where Virtualize is deployed.
4. Disable Certificate Validation in the AUT. Configure the AUT to accept any SSL certificate. The AUT would still connect over SSL but trust any server (such as the Virtualize server) without validating its certificate or its trust paths.
5. Set Up a Frontend. Configure a frontend component, such as a load balancer or proxy, to manage SSL connections using a trusted certificate. The frontend then forwards traffic to the Virtualize server.

For the AUT to accept a certificate/private key pair, you generally need—at minimum—a self-signed certificate/private key pair whose common name (CN) parameter matches the fully-qualified name of the server. For example, if your Virtualize server URL is http://myserver.mycompany.com, the CN parameter should be "myserver.mycompany.com".

In any case, Virtualize can be configured to accept incoming HTTPS connections on port 9443 (default SSL connector) or another port. 

Configuring server.xml

After obtaining your certificate and private key, you need to configure the Virtualize server's underlying Tomcat instance to use them. This requires editing the server.xml configuration file.

• For desktop client users, refer to the product’s provided server.xml located at: <INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf 
• For WAR file deployments, update the server.xml located in: <TOMCAT_HOME>/conf

SSL details can be configured by modifying the the SSL HTTP/1.1 Connector entry in server.xml. For example:

<Connector port="9443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:/Path To Keystore/virtualize.pfx"
keystorePass="security" keyAlias="virtualize" keystoreType="PKCS12" truststoreFile="../lib/cacerts"
truststorePass="changeit" truststoreType="JKS" />

To access the server.xml file, launch Virtualize and ensure that at least one responder has been created. The file is located in the <INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf directory.

keystoreFile

/>

keystoreFile

The keystoreFile attribute specifies the location of the keystore file that contains the Virtualize server’s private key and SSL certificate. This file is essential for enabling HTTPS, as it allows the server to identify itself securely to clients. The value depends on your The value you set for the keystoreFile attribute in server.xml depends on your configuration option. 

• If

...

• using Option 1 (preferred) or

...

• Option 2: Specify the path to the keystore file you generated for the Virtualize server

...

• . Although the keystore paths can be relative to the location of the server.xml file, it is best to provide absolute paths in order to ensure correct configuration.

...

• If

...

• using option 3

...

• : Specify the path to the

...

• keystore file

...

• used by the

...

• real SSL-based service that you want to emulate. Use forward slashes (/) instead of backward slashes (\). For example, C:/Users/myUser/keystore.jks.

...

• If using option 4: No change is needed for the keystoreFile attribute, since the AUT will accept any server certificate.

keystorePass

Set the keystorePass attribute to be the password to your keystore.

...

Set the keystoreType to the type of keystore you are using, such as PKCS12, JKS, BKS, UBER, or PEM.

clientAuth

Two-Way SSL (Mutual Authentication)

For two-way SSL (mutual authentication), the clientAuth attribute must be set to true and the

...

truststore used for validating client certificates should be specified using the truststoreFile, truststorePass, and truststoreType attributes:

...

...

• Set clientAuth to true to require clients (AUT) to present a certificate.
• Modify 

• truststoreFile to point to your keystore file. Use forward slashes (/) instead of backward slashes (\). For example, C:/Users/myUser/keystore.jks.

...

• Modify truststorePass to be the password to your keystore.

...

• Modify truststoreType to PKCS12, JKS, BKS, UBER, or PEM, depending on the type of keystore you're using.

Additional Configuration Details

For more details on how to enable and configure the SSL connector, see the Apache Tomcat documentation (https://tomcat.apache.org/tomcat-89.50-doc/ssl-howto.html).

It is possible to configure more than one port number for SSL. This is typically the case if different keystore/certificate configurations need to be virtualized.

...