SSL and certificates
OpenText Functional Testing Lab enables you to work in secure environments using SSL and to apply certificates when necessary. This section describes how to work with SSL connections. For details about installing certificates on your device for the purpose of accessing secure sites, see Testing sites that require certificates.
Supported SSL protocols
The server and connector support the latest SSL standards for all communication between server and connectors, supported OpenText testing tools/Appium, and browsers:
- TLS v1.2,
- TLS v1.1,
- TLS v1.0.
SSL connection
When you install the OpenText Functional Testing Lab server, you can select a non-secure (HTTP) or a secure (SSL) connection. When you select the SSL option during server installation, a self-signed SSL certificate is automatically generated on the local OpenText Functional Testing Lab machine. Alternatively, you can import a certificate from a certified authority (CA). For details, see Using SSL certificates issued by a Certification Authority.
OpenText Core SDP / OpenText Core Functional Testing Lab The connection to the lab server is secure, and the server is installed with a CA certificate.
For web browsers to trust the certificate presented by the server, the SSL certificate must be issued by a recognized Certificate Authority (CA). Self-signed certificates encrypt the data but do not provide a trusted identity of the server owner. When using the default self-signed certificate, browsers display a warning or error when you first try to access the OpenText Functional Testing Lab server over SSL. The warning informs you that the SSL certificate was self-signed by the server and not by a CA. To access the server, you need to trust the self-signed SSL certificate.
If the server was installed with the SSL option, all connectors and testing tool machines must connect to the server over a secure connection. When installing a connector with the SSL enabled option selected, a self-signed certificate is automatically generated on the connector machine. When you first access the connector from a browser, by opening the device remote view, a warning is displayed. Navigate to the connector URL, and trust the self-signed SSL certificate. Alternatively, you can import a certificate from a certified authority (CA). For details, see Using SSL certificates issued by a Certification Authority. For more details on connector installation, see Install the connector on a Windows machine or Install the connector on a Linux machine.
You can also reconfigure the connection to the server from non-secure to secure (or vice versa), or change the server address or port. For details, see Reconfigure the server.
Note: If you change the certificate on the server, you may need to re-establish trust between connectors and the server. For details, see Using SSL certificates issued by a Certification Authority.
Using SSL certificates issued by a Certification Authority
It is a best practice in a security conscious environment to replace the self-signed certificates on the server and connectors, with certificates issued by a trusted Certification Authority (CA).
OpenText Core Software Delivery Platform / OpenText Core Functional Testing Lab: The connection to the server is secure and the server is installed with a CA certificate. The connectors are installed with self-signed certificates. Follow the procedure detailed in this section to replace the self-signed certificates on connectors.
After you obtain your certificate file from a Certification Authority, ensure that it contains a complete chain of trust. A chain of trust is a list of certificates that enable the receiver to verify that the sender and all intermediate certificates are trustworthy. To detect and solve problems with your SSL certificate installation, perform an Internet search for "SSL checker" and use one of the online tools to diagnose your problems.
Tip: OpenText Functional Testing Lab is a multi-hosted deployment. We suggest generating the SSL certificate for both the server and connectors with a wildcard, and not for specific host. For example, *.LAB01.TEST.ACME.COM, and not MACHINEA.LAB01.TEST.ACME.COM. Without a wildcard, each certificate generated for a specific FQDN needs to be trusted on all browsers and by all OpenText testing tools accessing OpenText Functional Testing Lab.
If your SSL certificate is divided into separate key and certificate files, combine them into one PFX file.
The following example demonstrates how to combine your certificate and key. Run the commands below on the same machine on which the certificate is saved:
- Ensure that OpenSSL is installed on the machine using the following commands:
Linux:
In the terminal window enter the following to view the OpenSSL details for the machine:rpm -qa | grep -i openssl (rpm)
dpkg -l | grep -i openssl (deb)Windows:
In a command line window, enter the following:Copy codeopenssl version –a
If OpenSSL is installed, the OpenSSL information, such as the date and version number, is displayed. Otherwise, download and install the latest version of OpenSSL.
- Run the following command to convert the key and certificate files into one PFX certificate: Copy code
openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt -descert
- In the terminal window, change the directory to the server/ connector's Security directory:
<Path to OpenText Functional Testing Lab server installation directory>/server/Security
<Path to OpenText Functional Testing Lab connector installation directory>/connector/Security
- Enter
./importCA.sh
to import the authorized certificate to the server. -
Enter the current key store password (Default. password) and the password from the CA. This password is generated when creating the PFX file.The CA password becomes the new key store password. Store the password in a safe place for future access.
- The script adds a private certificate to keyStoreHpmc and a public certificate to trustStoreHpmc.
- Restart the server/ connector.
- Using your web browser, go to the server/ connector address:
https://<OpenText Functional Testing Lab server/ connector IP address>:<port>
- Validate that the correct CA certificate is displayed in the browser.
- Navigate to the server/ connector's Security directory:
<Path to OpenText Functional Testing Lab server installation folder>\server\Security.
<Path to OpenText Functional Testing Lab connector installation folder>\connector\Security.
- Enter
importCA.bat
to import the authorized certificate to the server. Admin permissions are required to run the batch file. - Enter the current key store password (Default. password) and the password from the CA. This password is generated when creating the PFX file. The CA password becomes the new key store password. Store the password in a safe place for future access.
-
The script adds a private certificate to keyStoreHpmc and a public certificate to trustStoreHpmc.
- Restart the service/ connector from the Start Menu.
-
Using your web browser, go to the server/ connector address:
https://<OpenText Functional Testing Lab server/ connector IP address>:<port>
-
Validate that the correct CA certificate is displayed in the browser.
Resolving errors related to legacy ciphers when running the importCA script
When running the importCA script, you may get an error : “40F7521FC47F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()”
This error is caused by trying to import a .p12 or .pfx file that uses a cipher algorithm from an older OpenSSL version into a newer version.
To avoid the issue, you can re-encrypt the pfx file.
To update the pfx file:
Note: If running these commands on Windows using the openssl included with OpenText Functional Testing Lab server/connector, create the OPENSSL_MODULES environment variable containing the openssl modules path: <OpenText Functional Testing Lab home directory>\openssl\lib\ossl-modules.
For example: set OPENSSL_MODULES=C:\Program Files\Functional Testing Lab for Mobile and Web Server\server\openssl\lib\ossl-modules
-
Decrypt the original .p12/.pfx file using legacy mode to handle older ciphers.
Copy codeopenssl pkcs12 -legacy -in Certificate.pfx -nodes -out cert-decrypted.tmp
-
Re-encrypt the decrypted file into a new .p12/.pfx file while using the newer OpenSSL version.
Copy codeopenssl pkcs12 -in cert-decrypted.tmp -export -out NewCertificate.pfx
-
Remove the temporary decrypted file to clean up
Windows:
Copy codedel cert-decrypted.tmp
Linux:
Copy coderm cert-decrypted.tmp
Establishing server trust on the connector in SSL connections
This section is not relevant for OpenText Core SDP and OpenText Core Functional Testing Lab.
When a connector acts as a client connecting to the OpenText Functional Testing Lab server, there needs to be trust present on the client, to the certificate on the server. This trust is initially established during the installation of the connector. If you replace the self-signed certificate on the server with a CA issued certificate, the trust needs to be re-established.
If the CA is a common one, such as Verisign, the CA already exists in the connector’s truststore, and the connector trusts the server certificate. If not, for example if the CA is private, the CA is not yet in the connector’s truststore. The CA certificate should be imported to the truststore for the connector to trust the server certificate. To establish trust when using a non-common CA on the lab server, you need to import the public certificate of the Certificate Authority (CA) that issued the server certificate—not the server certificate itself. To import the public certificate, see To import an SSL certificate:
After you import this certificate, trust is established between the client and any certificate issued by this CA. If this trust is not established correctly, there is an SSL handshake failure and an error message is issued.
Configuring the lab for secure LDAP
To use OpenText Functional Testing Lab with secure LDAP (SSL), see Use secure LDAP .
Generating a new certificate
This section is not relevant for OpenText Core SDP and OpenText Core Functional Testing Lab.
You many need to generate a new self-signed certificate if:
- You are using a CA certificate and would like to switch back to using a self-signed certificate
- The self-signed certificate, which is valid for 3 years, has expired.
You generate a new certificate for the server using the script in the Security folder as follows:
- Log in as OpenText Functional Testing Lab user and change directory to:
<Path to OpenText Functional Testing Lab server installation directory>/server/Security
- Run the following command to generate a new self-signed certificate on the server:
./generateSelfSignCertificate.sh
- Enter the required credentials. The script adds a private certificate to keyStoreHpmc and a public certificate to trustStoreHpmc.
- Restart the lab service:
service dl restart
Note: If the IP or FQDN is unavailable, the connection to the server fails and you must regenerate the certificate. After regenerating the certificate, you must also modify the configuration of connectors connecting to the OpenText Functional Testing Lab server. For details, see Modify the connector (Windows), Change the configuration of the connector (Linux), or Reconfigure the connector ( Mac).
- On the server machine, go to:
<Path to OpenText Functional Testing Lab server installation>\server\Security
- Run the following batch file to generate a new self-signed certificate on the server:
generateSelfSignCertificate.bat
-
Enter the required credentials.
- The script adds a private certificate to keyStoreHpmc and a public certificate to trustStoreHpmc.
- Restart the lab service either via the Start Menu or by navigating to
<Path to OpenText Functional Testing Lab server installation>\scripts\
and runningrestart.bat
Note: If the IP or FQDN is unavailable, the connection to the server fails and you must regenerate the certificate. After regenerating the certificate, you must also modify the configuration of connectors connecting to the OpenText Functional Testing Lab server. For details, see Modify the connector (Windows), Change the configuration of the connector (Linux), or Reconfigure the connector ( Mac).
See also: