Enabling SSL security

For Web applications, SSL security between the user's browser and the HATS application requires an HTTPS connection. This requires that both HTTP server and WebSphere® Application Server be configured to support HTTPS. The HTTP server certificate is stored in the browser certificate store for the browser-HTTP server connection.

The HATS SSL configuration discussed in the remainder of this section is used to configure SSL between the HATS application and the Telnet server (which must be configured with an SSL port). This HATS SSL configuration is supported for HATS Web, rich client, and EJB applications, and for HATS portlets.
Note:
SSL is not supported for 5250W connections between HATS and the WebFacing server.

To enable SSL between the HATS application and the Telnet server, select the Enable SSL check box on the Security tab of the connection editor. For more information see Security. By enabling SSL for a connection, you request that data flowing over the connection be encrypted to secure the connection.

Selecting the Use JSSE check box enables the use of TLS v1.0, TLS v1.1, TLS v1.2, or TLS v1.3 using the Java Secure Socket Extension (JSSE) security library, instead of SSLite, for the connection between HATS and the HOST system. If not selected (default option), the SSLite library is used, and TLS v1.1, TLS v1.2, and TLS v1.3 are unavailable for the connection.

Supporting JRE versions for TLS 1.3 Protocol:

  1. Oracle/OpenJDK 1.8 update 261 and above.
  2. IBM 1.8 update 291 and above.
  3. Java version 11 and above.
Note:
The IETF Internet-Draft, TLS-based Telnet Security, defines the protocol for doing the SSL handshake over a TLS-based Telnet connection. If the Telnet server you are connecting to supports this protocol, you must add the SSLTelnetNegotiated property to the advanced connection settings of your connection definition. The advanced connection settings are found on the Advanced tab of the connection editor, see Configure optional, advanced connection settings. Set the value of the property to true.

HATS uses Host On-Demand technology to provide connection support from HATS applications to 3270 and 5250 applications using Telnet protocols. HATS uses the SSL support provided by Host On-Demand technology for securing these connections. Using a secure connection over SSL encrypts data flowing over the connection and thus protects it against observation by a third party.

For a connection to be secured, both the HATS application and the Telnet server it is connected to must support SSL. To secure the connection, the Telnet server must provide a certificate, which is used in encrypting the data.

When connection establishment is attempted, HATS receives the certificate from the Telnet server and determines whether to accept or reject the connection. HATS searches its built-in keystore file for a signer certificate that matches the Telnet server's personal certificate. The HATS keystore file contains a set of well-known certificates including Verisign, Thawte, and RSA. If the Telnet server is using a valid well-known certificate, it will be accepted because it will match one of the well-known certificates that are provided with HATS. In this case, there is no need to create a keystore file containing the certificate - the needed signer certificate is already in the HATS built-in keystore file.

If the Telnet server is not using a well-known certificate, a keystore file containing a valid signer certificate must be created and configured to HATS. This certificate can be obtained by opening the Telnet server's keystore file, extracting the certificate as a binary .der file, and importing the .der file into the keystore file you use with HATS.

Important notice: With version 10 onwards, the IBM Key Management Utility is no longer supported by IBM SDP. Developers should utilize either the standard Java keytool (SDP_Installation_location\jdk\bin\keytool.exe) or the certificate management features provided by the target application server (e.g., WebSphere, Tomcat) for general key and certificate tasks."

Detailed documentation on IBM and OpenJDK Keytool:

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=commands-creating-adding-data-keystorehttps://cr.openjdk.org/~jjg/8261930/docs/specs/man/keytool.html

Below is an example of how to extract the certificate file from the Telnet server's keystore file.

View the Signer certificate from a JKS or P12 key database:
keytool -list -v -keystore <databaseFile.jks|databaseFile.p12> -storetype <JKS|PKCS12> -storepass <YourStrongPwd>

Record the alias of each signer (trusted) certificate. These entries are identified in the keytool output by the line Entry type: trustedCertEntry.

Extract the selected signer certificate as DER
keytool -exportcert -alias verisign_root_ca -keystore <databaseFile.jks|databaseFile.p12> -storetype <JKS|PKCS12>  -file <cert.der>
Extract the selected signer certificate as BASE64-encoded ASCII data
keytool -exportcert -alias verisign_root_ca -keystore <databaseFile.jks|databaseFile.p12> -storetype <JKS|PKCS12> -rfc -file <cert.cer>
Create new JKS Keystore
keytool -genkeypair -alias <DummyAliasName> -keyalg RSA -keysize 2048 -keystore <databaseFile.jks> -storetype JKS -storepass <YourStrongPwd>
Note:
Replace keyalgo details as per your organization details.

This self-signed certificate and its associated private key are stored together in the keystore entry under a specific alias.

Import the certificate (DER or Base64)
keytool -importcert -trustcacerts -alias telnet-server-ca -file cert.der -keystore <databaseFile.jks> -storetype JKS -storepass <YourStrongPassword> -noprompt
Remove the dummy keypair so the keystore contains only trusted certificates
keytool -delete -alias <DummyAliasName> -keystore <databaseFile.jks> -storetype JKS  -storepass <YourStrongPwd>
Note:

If a certificate is required by HATS, you can use options on the Security tab of the connection editor to configure how HATS finds the keystore file containing the certificate. Use the Import button to import the keystore file into your project. Or, use the Use PKCS12 keystore at a specific path option to specify that the keystore file will not be contained within your project but will exist elsewhere on the target runtime system. This option is useful if you want to update the keystore file without having to redeploy the HATS application. If you import the keystore file, HATS copies it to the root of the EAR project (for Web projects), to the \Web Content\WEB-INF directory (for portlet projects), or to the runtime extension plug-in (for rich client projects). If imported, the keystore file becomes a part of the HATS project, and it is packaged with the rest of the project files when you export the project. For more information see Security.

Note:
  1. Multiple certificates can be added to a single keystore file.
  2. Multiple HATS projects can use the same keystore file, either by importing the same keystore file in the EAR project (for Web applications) or in the runtime extension plug-in (for rich client applications), or by referencing the same keystore file in the Use PKCS12 keystore at a specific path option.
  3. Each connection within a single HATS project can reference the same or different keystore files.