Using Secure Sockets Layer (SSL) support

In order to use SSL, both the client (the IMS™ TM resource adapter) and the server (IMS Connect) must be configured.
The following table provides a high level description of the steps you should follow in configuring the IMS TM resource adapter, IMS Connector for Java™ and IMS Connect for SSL.
SSL Client (IMS Connector for Java) SSL Server (IMS Connect)
  1. Decide if client authentication is required. If client authentication is not required, skip to Step 5.
Note: It is strongly recommended that you use client authentication to protect against unauthorized access to IMS Connect.
2. If client authentication is required, obtain signed certificates and private key.  
3. If client authentication is required, create a keystore and insert the client's private key and certificate. For more detail, see the description below.  
  4. If client authentication is required, insert the client's public key certificate into the keyring. See IMS Connect User's Guide (SC27-0946-03) for more information.
5. Create a truststore (another optional keystore) and insert the Server's public key certificate. Alternatively, insert the Server's public key certificate into the client's keystore if trusted and non-trusted certificates are stored in the same keystore.  
  6. Decide which IMS Connect SSL port to use. Set up the IMS Connect and SSL Configuration members with the appropriate values. For more information about setting up these configuration members, see IMS Connect User's Guide (SC27-0946).
7. Set up the connection factory with the appropriate SSL parameters, including the port number from step 6. For more detail, see the description below.  
8. Bind the application to the SSL connection factory.  

Creating the keystore or truststore for the client

For the client and server to authenticate one another, you must provide a JKS keystore or RACF® keyring with valid X.509 certificates at both the client and server ends. If client authentication by the server is not required, it is not necessary to create the client certificate and add it to the server's keystore or keyring. Several tools are available for managing keystores. To provide a JKS keystore at both the client and server ends, you must perform the following steps:
  • To set up the client, IMS Connector for Java, create a certificate and have it signed by a Certificate Authority (for example, VeriSign), or create your own Certificate Authority (CA) using software such as OpenSSL to sign your own (self-signed) certificate.
  • To create a keystore, use a key management tool such as Ikeyman or Keytool. After the keystore is created, import the client certificate (if one is available) into the keystore.
  • To create a truststore, create another keystore and import the server's (IMS Connect's) certificate. Note: If you want to create only one keystore, import the server's certificate into the same keystore used to store the client's certificates. Consult your RACF documentation for guidance in creating a RACF keyring for use as a keystore or truststore.

SSL configuration

A secure SSL connection between a Java client application and IMS Connect is created by ensuring that the connection factory used by the Java client application has the appropriate values for its SSL properties. See Connection properties for a description of the SSL property values.

Using IBM's WebSphere® and Rational® products as examples, there are multiple ways to set up SSL properties:

Note: Informational messages and warnings can be found in the trace.log file generated by WebSphere Application Server. See Logging and tracing with the IMS TM resource adapterfor information on IMS Connector for Java logging an tracing.

At runtime, when the Java client application executes an interaction with IMS, the interaction flows on a secure (SSL) connection between the SSL client, IMS Connector for Java, and the SSL server, IMS Connect. To open an SSL connection between the client and server, an SSL handshake process takes place. This SSL handshake, which is transparent to the Java client application, occurs as follows:
  • The SSL client, IMS Connector for Java initiates a connection by sending a client hello. The server, IMS Connect, replies with a server hello and its certificate containing its public key.
  • If this certificate is authenticated successfully by the server, a session key is established at both ends and a cipher spec is negotiated that determines the type of encryption to be used on the connection. The cipher may be STRONG, WEAK, or ENULL. The SSL handshake is then completed.
  • If the server does require client authentication, the client authenticates the server's certificate using the server's public key from its certificate. If this authentication is successful, a client certificate is sent from the client's keystore. If this certificate is authenticated successfully by the server, a session key is established at both ends and a cipher spec is negotiated that determines the type of encryption to be used on the connection. The SSL handshake is then completed.
  • The client and server are then ready to send and receive encrypted data.
It is important to note that, when running applications in a managed environment (as is strongly recommended when using SSL connections due to the overhead of the SSL handshake process,) the IMS TM resource adapter uses only persistent socket connections to communicate with IMS Connect. In fact, the IMS TM resource adapter always uses persistent socket connections, but in a non-managed environment, these persistent connections are disconnected by the application after each use rather than being made available for re-use by another application. When the WebSphere Application Server Connection Manager is used, connections can be serially re-usedby other client applications. The connection manager creates connections if necessary, and provides them to the applications as needed. When an application is finished using a connection, the connection manager returns that connection to the free pool making it available for reuse by any other application requiring that type of connection. However, client and server authentication only occurs once for each socket during the handshake that takes place when that socket is first created and initialized as an SSL socket. When a socket is reused, the SSL client, the IMS TM resource adapter, and server, IMS Connect, do not change. Consequently, there is no reason to re-authenticate the client and server (go through the handshake process again) when a socket is reused. This is consistent with the fact that the client ID which identifies a socket remains the same each time a socket is reused.

If the SSLEncryption value is set to ENULL, performance should be faster than SSL connections using Strong or Weak encryption. The level of improvement will depend on several factors, including whether hardware or software encryption is used. If hardware encryption is used, the improvement will be less because hardware encryption is faster than software encryption.


Feedback