Renegotiating the secret key used for encryption

 

A WebSphere MQ base Java™ client application can control when the secret key that is used for encryption on a client connection is renegotiated. The application can do this in any of the following ways:

• By setting the sslResetCount field in the MQEnvironment class.

• By setting the environment property MQC.SSL_RESET_COUNT_PROPERTY in a Hashtable object. The application then assigns the hashtable to the properties field in the MQEnvironment class, or passes the hashtable to an MQQueueManager object on its constructor.

If the application uses more than one of these ways, the usual precedence rules apply. See MQEnvironment for the precedence rules.

The value of the sslResetCount field or environment property MQC.SSL_RESET_COUNT_PROPERTY represents the total number of bytes sent and received by the WebSphere MQ base Java client code before the secret key is renegotiated. The number of bytes sent is the number before encryption, and the number of bytes received is the number after decryption. The number of bytes also includes control information sent and received by the WebSphere MQ base Java client.

If the reset count is zero, which is the default value, the secret key is never renegotiated. The reset count is ignored if no CipherSuite is specified.

If you are using an HP or Sun Java 2 Software Development Kit (SDK) or Java Runtime Environment (JRE), do not set the reset count to a value other than zero. If you do set the reset count to a value other than zero, a client connection fails when it attempts to renegotiate the secret key.

For more information about the secret key that is used for encryption on an SSL enabled channel, see WebSphere MQ Security.

uj11360_