Developing keystore files for data encryption

[Version 8.6.0.4 and later] You can configure Transport Layer Security (TLS) by modifying or replacing the keystore and truststore, and choosing the certificate alias for your configuration.

Before you begin

You must have access to the keytool tool. This tool is in the java_home/bin directory.

About this task

To use SSL or TLS for secure transport, you must create a keystore and a truststore. 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. You can use any tool that can create a compliant .p12 or .jks file. In this task, you use the keytool in Java™ 7, along with the certificate issuance capabilities of the local certificate authority (CA). The Java 7 runtime environment that is shipped with the WebSphere® eXtreme Scale client and server includes keytool, and it also includes a graphical tool, iKeyman, which you might also use. All of the eXtreme Scale servers in a deployment might share copies of a single keystore and truststore, but this file sharing is not necessary.

The keystore must contain one or several certificates of type keyEntry, along with the corresponding private keys. The certificate is typically of one of the following types:

Self-signed. In this case, the certificate is its own signer. To establish trust in the certificate, you must export the certificate and import it into the truststore files for each of the client applications, and for each of the eXtreme Scale servers.
Signed by a known certificate authority. The certificate of that certificate authority must be in each truststore.
A chained certificate that is signed by a local certificate authority. The certificate for the certificate authority at the root of the chain must be added to each truststore.

Procedure

Create or modify the truststore, which contains the signer certificates that the appliance trusts when it connects to other members of the collective, or for ORB configurations, when the appliance makes callbacks to clients.
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 d:\chainsample\root.arm -keystore d:\chainsample\wxstrust.jks -storepass ogpass
```
The Java runtime environment includes a cacerts file that has certificates from many known CAs. You can use the -trustcacerts option to include these certificates in your truststore.

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 must import.
Create a keystore by importing the certificate that you have.
The keystore must have the root certificate or you cannot use the keytool to import generated certificates:
```
keytool -importcert -alias root -file d:\chainsample\root.arm -keystore d:\chainsample\wxskey.jks -storepass ogpass
```
Generate a key pair.
In the appliance, the keypass and the storepass name 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 d:\chainsample\wxskey.jks -storepass ogpass
```
Request a certificate from the local CA.
```
keytool -certreq -alias server -sigalg sha256withRSA -file d:\chainsample\serverreq.arm -keypass ogpass -keystore d:\chainsample\wxskey.jks -dname cn=server,o=acme -storepass ogpass
```
The arm file is a certificate request that can be sent to an intermediate CA and used by that CA to build the actual certificate to be used in the appliance keystore.

Import the certificate from the local CA into the new keystore for the appliance.

In this example, the file, serverresp.arm, 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 appliance or collective. In the following example, the certificate response is imported:

keytool -importcert -alias server -file d:\chainsample\serverresp.arm -keypass ogpass -keystore d:\chainsample\wxskey.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
]
]

Upload the new keystore and truststore, and configure the password for each one.
Change the certificate alias setting to match the name of the certificate in the keystore.
The truststore files for all data grid clients must also be updated to establish trust with the appliance certificate.
Specify an SSL mode from the following options: TCP/IP, where SSL is not used for data grid communication, TLS Supported, and TLS Required.
The TLS Required setting is suggested for security. When TLS is not used, passwords and sensitive grid data pass unencrypted over the network links connecting the grid clients and the server.
Optional: Enable Federal Information Processing Standard (FIPS).
You can configure the appliance collective to use FIPS 140-2 for all encrypted network communication. This standard ensures high protection of data as it is sent over the wire. Select Enable FIPS 140-2 Cryptography to enable FIPS.

Restriction: Some web browser versions do not work with a FIPS-enabled server. Current® versions of most browsers, including Mozilla Firefox, Microsoft Internet Explorer, and Google Chrome, do support communication with FIPS-enabled servers. You might configure the browser to enable TLS because SSLv3 is not supported in FIPS mode. For more information, see the documentation for your browser.
Optional: Enable client certificate authentication.

When client certificate authentication is enabled, the keystore for each client and browser that communicate with the appliance must be configured to have a certificate that is trusted by the appliance truststore. Client certificate authentication is not used for ORB transport. It is used only for HTTPS and XIO transport. It is not necessary to enable client certificate authentication to have a secure configuration.

What to do next

Configure server-to-server authentication, client authentication, telnet access, and LDAP to finish securing your data grid.