Enable SSL communication in Liberty
To enable SSL communication in Liberty, add the Transport Security feature and specify a keystore configuration. The Transport Layer Security (TLS) protocol supersedes the now deprecated Secure Sockets Layer protocol.
For the most current information about enabling SSL communication in Liberty, see the Open Liberty website.
- Enable the transportSecurity-1.0
Liberty feature in the server.xml file.
<featureManager> <feature>transportSecurity-1.0</feature> </featureManager>
- Optional: Alternatively, we can enable SSL communication by adding the ssl-1.0
Liberty feature in the server.xml file.
<featureManager> <feature>ssl-1.0</feature> </featureManager>
The transportSecurity-1.0 feature supersedes the ssl-1.0 feature and adds functions that are not included with the ssl-1.0 feature. For more information, see Differences between the transportSecurity-1.0 and ssl-1.0 features.
- Optional: Alternatively, we can enable SSL communication by adding the ssl-1.0
Liberty feature in the server.xml file.
- Add the keystore element to the server.xml file.
The default keystore configuration is called defaultKeyStore and contains the keystore password.
<keyStore id="defaultKeyStore" password="yourPassword" />
Liberty creates a keystore password during server creation and puts it in the server.env file that is in the server home directory. If no keystore element exists for the defaultKeyStore file, this password is used to create a keystore file. This keystore file is then used as the defaultKeyStore file. Likewise, if a defaultKeyStore entry exists without a password in the sever.xml file when the server starts, the password from the server.env file is used to open the file. If we don't want to use the Liberty-generated keystore password, remove the keystore_password entry from the server.env file. If a default keystore was already generated with the password from the server.env file, we might need to remove it.
This configuration is the minimum that is needed to create an SSL configuration. In this configuration, the server creates the keystore and certificate if it does not exist during SSL initialization. The password provided must be at least 6 characters long. We can enter the password in clear text or encode it using the securityUtility encode option.
The keystore is assumed to be a PKCS12 keystore file called key.p12 in the server home/resources/security directory.
In version 19.0.0.2 and earlier, the keystore is assumed to be a JKS keystore file called key.jks in the server home/resources/security directory.
If the file does not exist, the server creates it for you. If the server creates the keystore file, it also creates the certificate inside it. The certificate is a self-signed certificate with a validity period of 365 days. The CN value of the certificate subjectDN is the hostname of the machine where the server is running, and it has a signature algorithm of SHA256withRSA.
- Optional: We can extend the single keystore entry for a minimal SSL
configuration to include the keystore location and type, as shown in the following example.
<keyStore id="defaultKeyStore" location="myKeyStore.p12" password="yourPassword" type="PKCS12"/>
- Optional: Specify an SAF key ring URL as the keystore
location.
The following example shows an SAF key ring in the minimal configuration:
<keyStore id="defaultKeyStore" location="safkeyring://racfid/WASKeyring" type="JCERACFKS" password="password" fileBased="false" readOnly="true" />
The RACF key ring must be set up before configuring them for use by the Liberty server. The server does not create certificates and add them to RACF. Specify the SAF key ring URL is in the following format:
safkeyring://racfid/WASKeyring
The racfid value is the RACF user ID with read authority to the key ring named WASKeyring.
- Optional: We can extend the single keystore entry for a minimal SSL
configuration to include the keystore location and type, as shown in the following example.