Working with SSL and certificates
UFT Mobile 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 UFT Mobile server and connector support the latest SSL standards for all communication between server and connectors, supported testing tools (UFT One, UFT Developer, LoadRunner, and Appium) and browsers:
- TLS v1.2,
- TLS v1.1,
- TLS v1.0.
Connecting to UFT Mobile over SSL
When you install an on-premises UFT Mobile server, you can choose whether to work with a non-secure (HTTP) or a secure (SSL) connection. When you use the SSL option during server installation, a self-signed SSL certificate is automatically generated on the local UFT Mobile machine. Alternatively, you can import a certificate from a certified authority (CA). For details, see Using SSL certificates issued by a Certification Authority (CA).
UFTM SaaS: The connection to the UFTM SaaS server is secure, and the server is installed with a CA certificate.
Self-signed certificates do not, however, provide a trusted identity of the server owner. Therefore, when using the default self-signed certificate, browsers display a warning or error when you first try to access the UFT Mobile server over SSL. For web browsers to trust the certificate that the server has presented, the SSL certificate must be issued by a recognized Certificate Authority (CA).
Despite the warning messages, the self-signed certificate encrypts the data. The warning is issued to inform 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 (CA). 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 UFT Mobile server (on-premises).
Note: If you change the certificate on the server, you may need to re-establish trust between connectors and the UFT Mobile server. For details, see Using SSL certificates issued by a Certification Authority (CA).
Using SSL certificates issued by a Certification Authority (CA)
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.
UFTM SaaS: The connection to the UFTM SaaS server is secure and the server is installed with a CA certificate. On-premises UFTM 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: UFT Mobile 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 Micro Focus testing tools accessing UFT Mobile.
Establishing server trust on the connector in SSL connections (on-premises)
This section is relevant for on-premises installations only. When a connector acts as a client connecting to the UFT Mobile 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 will trust 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 UFTM 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 will be an SSL handshake failure and an error message will be issued.
Configuring UFT Mobile for secure LDAP
To use UFT Mobile with secure LDAP (SSL), see Use secure LDAP on the UFT Mobile server .
Generating a new certificate
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:
See also: