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.

To import an SSL certificate:

If your SSL certificate is divided into separate files (key and certificate)

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 code
```
openssl 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
```

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\server\openssl\lib\ossl-modules

Decrypt the original .p12/.pfx file using legacy mode to handle older ciphers.
Copy code
```
openssl 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 code
```
openssl pkcs12 -in cert-decrypted.tmp -export -out NewCertificate.pfx
```
Remove the temporary decrypted file to clean up

Windows:
Copy code
```
del cert-decrypted.tmp
```
Linux:
Copy code
```
rm 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: