Creating a keystore and a truststore

You can configure Transport Layer Security (TLS) by modifying or replacing the keystore and truststore, and choosing the certificate alias for your IBM® WebSphere® eXtreme Scale Liberty Deployment (XSLD) cache member group.

Before you begin

You must be logged in with a user assigned the administrator role to perform these steps.
Configure the TLS configuration before loading data into the data grid. When you configure TLS, the XSLD cache member group will restart. If any data is loaded when this restart occurs, it is may be discarded. Therefore, configuring the TLS configuration before loading data into the data grid ensures that data is not discarded when each member of the XSLD cache member group is restarted.
All members of the XSLD cache member group must be updated separately.

About this task

The XSLD cache member group comes configured with a default keystore and truststore. The default truststore includes the signer certificate from the default keystore. Because this certificate is included in every XSLD install, it should be replaced for the TLS configuration to be secure. There are multiple ways and tools to help set up keystore and truststore files, and depending on the tools that are provided with your certificate authority, the specific steps can vary. In this task, you use the keytool in Java™ 8, along with the certificate issuance capabilities of the local certificate authority (CA).

Using chain certificates is suggested because the root CA signs the certificate, which means that you do not have to manually add the signer certificate to the truststore. In your environment, you likely have a root CA and several intermediate CAs. Certificates that are issued by intermediate CAs are typically chained certificates, where the chain points back to the root CA for signing. In this case, you add the certificate of the root CA to the XSLD cache member group truststore. If the certificate that you want to use in the XSLD cache member group keystore is not a chained certificate, then you must take this additional step. For example, the issuer of the certificate that is stored in the XSLD cache member group keystore might be an intermediate CA. In this case, you must add the signer certificate for that intermediate CA to the XSLD cache member group truststore.

You must import the certificates that you add to the XSLD cache member group truststore into the truststore files of any clients of the XSLD cache member group. For example, if a WebSphere Application Server instance acts as a client, then you must add the certificate of the root CA to the WebSphere Application Server truststore, and if you use a non-chained certificate, the signer certificate for the non-chained certificate must be added as well.

Procedure

Create or modify the truststore, which contains the signer certificates that the XSLD collective member trusts when it connects to other members of the collective.
One method is to copy the default truststore from one of the collective member, and modify it to include the certificates that you need.
Since the default truststore file contains the default certificate, remove the signer certificate from the truststore that is labeled ibm extreme scale liberty deployment, and then add a certificate to establish trust with the new keystore. You can use the keytool -delete command to remove the certificate with alias, ibm extreme scale liberty deployment, from the truststore.

Alternatively, create a new truststore with only the certificates that you need. Use the following command in the keytool to create a new truststore file. In this example, the root.arm file contains the certificate for the local root CA. This certificate is exported from the CA, using the tools that come with the CA, and then it is shared so that clients and servers trust certificates that are issued by the root CA and any intermediate CAs.
```
keytool -importcert -alias root -file root.arm -keystore truststore.jks -storepass ogpass
```
You can also add any other certificates for which trust is needed. However, for certificates that are issued by the root CA or its associated intermediate CAs, this certificate is the only one that you need to import.
Create a keystore by importing the certificate that you have. The keystore must have the root certificate. Otherwise, you cannot use the keytool to import generated certificates; for example:
```
keytool -importcert -alias root -file root.arm -keystore keystore.jks -storepass ogpass
```
Generate a key pair. For the XSLD cache member group, the keypass and the storepass must be the same. The key size, alias, key algorithm, signature algorithm, distinguished name, and validity in the following code snippet are examples only. Specify values according to your local policies.
```
keytool -genkeypair -alias server -keyalg RSA -keysize 2048 -sigalg sha256withRSA -dname cn=server,o=acme -validity 3650 -keypass ogpass -keystore keystore.jks -storepass ogpass
```
Optional: Make sure that the DNS name for all servers includes the domain name (DN) of your certificate.
When you access XSLD cache member group from a browser, domain name (DN) validation is completed. To avoid the browser prompt that indicates the DN of the certificate does not match, give the DN a name similar to the following example, where xsld*.acme.com matches all the servers that have the xsld*.acme.com DNS name.
```
cn=xsld*.acme.com,ou=production,o=acme
```
Request a certificate from the local CA.
```
keytool -certreq -alias server -sigalg sha256withRSA -file serverreq.arm -keypass ogpass -keystore keystore.jks -dname cn=server,o=acme -storepass ogpass
```
The arm file is a certificate request that can be sent to an intermediate CA. The intermediate CA uses the arm file to build the actual certificate that is used in the keystore.

Import the certificate from the local CA into the new keystore. In this example, the serverresp.arm file is received from the local CA in response to the request. The generated certificate should be a chained certificate that includes, in the chain certificate information for the root CA, certificate information for one or several intermediate CAs that link in a chain to the root and the certificate to be used by the XSLD cache member group. In the following example, the certificate response is imported:


keytool -importcert -alias server -file d:\chainsample\serverresp.arm -keypass ogpass -keystore d:\chainsample\xc10key.jks -storepass ogpass

The following example keystore file includes a chained certificate of the required keyEntry type. The contents of your keystore can be displayed by issuing the keytool -list command.


Keystore type: jks
Keystore provider: IBMJCE

Your keystore contains 1 entry

Alias name: server
Creation date: Jul 31, 2013
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=server, O=acme
Issuer: CN=inter, O=acme
Serial number: 697527ba
Valid from: 7/31/13 12:58 PM until: 7/29/23 12:58 PM
Certificate fingerprints:
	 MD5:  F8:29:F1:6E:E3:D5:8C:4E:4C:68:98:AD:7D:90:AF:36
	 SHA1: 2C:42:8B:B6:85:68:B4:A3:A9:46:11:91:E0:8D:68:47:C9:61:C9:02
	 SHA256: 49:A8:EA:AC:99:39:DB:6D:93:38:2E:88:CE:3E:54:1E:14:80:FC:24:C7:63:6E:FD:BA:4E:CE:C1:63:90:6F:DE
	 Signature algorithm name: SHA256withRSA
	 Version: 3

Extensions: 

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 57 d9 49 2c 5c f8 13 9f  eb 98 a7 2b f5 ae 64 2e  W.I...........d.
0010: fe 2a 02 fd                                        ....
]
]

#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 48 8b 07 dc 6c 20 cd 1b  ec 54 d0 a6 19 c4 02 2e  H...l....T......
0010: af b1 b5 2c                                        ....
]
]

Certificate[2]:
Owner: CN=inter, O=acme
Issuer: CN=root, O=acme
Serial number: 5e399139
Valid from: 7/31/13 12:58 PM until: 7/29/23 12:58 PM
Certificate fingerprints:
	 MD5:  9C:25:76:99:AB:F4:DD:98:35:18:54:03:A5:D8:84:18
	 SHA1: 7C:66:B2:86:6E:D7:2F:0E:70:B1:49:BB:3B:FF:45:CF:90:C2:28:D8
	 SHA256: CB:E7:ED:3E:0F:AF:09:58:4E:EB:94:14:58:45:ED:CC:16:F0:F6:A3:D6:92:50:8F:10:CE:D8:17:07:DE:03:CC
	 Signature algorithm name: SHA256withRSA
	 Version: 3

Extensions: 

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 69 6e 41 41 a4 17 97 44  4a 8d e0 e3 dc 51 0a d8  inAA...DJ....Q..
0010: d9 0a 5a 49                                        ..ZI
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 57 d9 49 2c 5c f8 13 9f  eb 98 a7 2b f5 ae 64 2e  W.I...........d.
0010: fe 2a 02 fd                                        ....
]
]

Certificate[3]:
Owner: CN=root, O=acme
Issuer: CN=root, O=acme
Serial number: 1d5fdbdd
Valid from: 7/31/13 12:58 PM until: 7/29/23 12:58 PM
Certificate fingerprints:
	 MD5:  06:8F:A0:D0:9A:FB:43:3F:C7:A0:8E:2D:49:61:D8:FE
	 SHA1: 42:9B:9B:4C:FA:82:1B:BF:15:6F:DF:B5:14:C0:85:9D:97:86:2F:0A
	 SHA256: 9F:53:6D:6A:80:D6:6B:5D:C6:E2:BB:45:9B:FC:A1:57:61:F0:4E:2E:1D:F9:D5:0F:B5:69:9B:F1:2C:AC:50:BC
	 Signature algorithm name: SHA256withRSA
	 Version: 3

Extensions: 

#1: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 69 6e 41 41 a4 17 97 44  4a 8d e0 e3 dc 51 0a d8  inAA...DJ....Q..
0010: d9 0a 5a 49                                        ..ZI
]
]

What to do next

Configure TLS on the cache member group. You can configure TLS from the Admin console, or using cURL commands with the REST API. For more information see, Configuring TLS for a cache member group, or Configuring TLS for a cache member group with cURL.