Configuring TLS for data grid applications

[Version 2.1 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

Important: 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, configure the TLS configuration before loading data into the data grid.

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).

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. 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. 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

  1. 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. In the user interface, click Collective > Settings > Transport Layer Security (TLS). Click Download active truststore, and remember the location that 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.

  2. 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\xc10key.jks -storepass ogpass
  3. 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
  4. 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
    Remember: Not all members of a collective share one certificate. Therefore, make sure to include the DN of each certificate in the DNS name for the appropriate servers.
  5. 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 and used by that CA to build the actual certificate to be used in the appliance keystore.
  6. 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\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
    ]
    ]
  7. Upload the new keystore and truststore and configure the password for each one.
  8. 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.
  9. 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.
  10. 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.
  11. 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. .