Configuring TLS for data grid applications

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 be assigned the Appliance administration permission.
You must have access to the keytool tool. This tool is in the java_home/bin directory.
If you want to use FIPS encryption, and you run with Java 6, then you must use Java 6 SR15 or higher.

Important: Configure the TLS configuration before loading data into the data grid. When you configure TLS, the appliance restarts automatically. When the appliance is a member of a collective, the entire collective is restarted. All members of the collective use the same TLS settings, keystore, and truststore. If any data is loaded when this restart occurs, it is discarded. Therefore, configuring the TLS configuration before loading data into the data grid ensures that data is not discarded when the collective is restarted.

About this task

The appliance comes configured with a default keystore and truststore. The default truststore includes the signer certificate from the default keystore. Because this certificate is included with every appliance, it should be replaced for the SSL 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™ 7, 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 appliance 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 appliance truststore. If the certificate that you want to use in the appliance 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 appliance keystore might be an intermediate CA. In this case, you must add the signer certificate for that intermediate CA to the appliance truststore.

You must import the certificates that you add to the appliance truststore into the truststore files of any clients for the appliance. For example, if a WebSphere® Application Server instance acts as an appliance 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 appliance trusts when it connects to other members of the collective, or for ORB configurations, when the appliance makes callbacks to clients.
One method is to download the default truststore from the appliance, and modify it to include the certificates that you need. To do so in the user interface, click Collective > Settings, and expand Transport Layer Security (TLS). Click Download active truststore, and remember the location where you saved the file on disk, for example in the /downloads/trustStore.jks directory.

Since the appliance truststore files contain the default certificate, remove the signer certificate from the truststore that is labeled IBM WebSphere DataPower XC10, 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 websphere datapower xc10, 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 d:\chainsample\root.arm -keystore d:\chainsample\xc10trust.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 d:\chainsample\root.arm -keystore d:\chainsample\xc10key.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\xc10key.jks -storepass ogpass
```
Optional: Make sure that the DNS name for all servers includes the domain name (DN) of your certificate.
When you access the data grid 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 xc10*.acme.com matches all the servers that have the DNS name, xc10*.acme.com:
```
cn=xc10*.acme.com,ou=production,o=acme
```
Request a certificate from the local CA.
```
keytool -certreq -alias server -sigalg sha256withRSA -file d:\chainsample\serverreq.arm -keypass ogpass -keystore d:\chainsample\xc10key.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 appliance keystore.

Import the certificate from the local CA into the new keystore for the appliance. 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 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\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
]
]

Upload the new keystore and truststore and configure the password for each one. To do so in the user interface, click Collective > Settings, and expand Transport Layer Security (TLS). Click Upload new store to upload the active keystore or truststore file.
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 appliance.
Note: When TLS communication is required, the appliance truststore must be configured to trust the certificate in the client keystore, and the client truststore must be configured to trust the certificate in the server keystore. See Configuring client security.
Optional: Select a cryptography standard.
You can configure the appliance collective for FIPS or NIST SP800-131a compliance for all encrypted network communication, or with no special cryptography protection at all. The SP800-131a specification requires longer key lengths and stronger cryptography. It provides two modes, transition and strict, which allow you to move to a strict enforcement of SP800-131a or to use the transition mode first, if needed. The NIST SP800-131a compliance has three different modes, SP800-131a transition, SP800-131a transition mode with TLSv1.2, and SP800-131a strict. See the following list of possible cryptography settings for the appliance:
Basic

When you select the Basic setting, the appliance runs with no special cryptography protection. Basic transport layer security communication is used.

FIPS 140-2

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.

SP800-131a transition

The SP800-131a transition mode specifies that all SSL communication uses both FIPS and NIST transition standards, with the TLSv1 transportation protocol.
Restriction: You can use FIPS data encryption with the TLSv1 protocol only.

SP800-131a transition with TLSv1.2

Select SP800-131a transition with TLSv1.2 to enable SP800-131a transition mode with the TLSv1.2 transport protocol.

SP800-131a strict

The SP800-131a strict standard specifies that all SSL communication uses both FIPS and NIST standards, with the TLSv1.2 transportation protocol.
Restriction: Some web browser versions do not work with a NIST SP800-131a-enabled server. Current versions of most browsers, including Microsoft Internet Explorer and Google Chrome, do support communication with NIST SP800-131a-enabled servers. For browser information, see the documentation for your browser. For more information about configuring data grid connections for NIST SP800-131a, see Configuring NIST SP800-131a compliance for data grid connections.
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. [Version 2.5 and later]

For more information, see Configuring secure access to the data grid.