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