How to check the current no of TLS records that the Sender channel is sent ?

The channel is reset after 23726566 are sent in the sender channel .it uses TLS_RSA_WITH_AES_256_GCM_SHA384 .This is due to the the Limit on the cipher as per the GSK tool kit provider used in MQ .

Once the limit is reached the channel will abort and then new session key is generated by re-negotiation . During this time SSL handshake will happen

The following link is what you are looking for but it is talking about the client side.

SSL key resets

The number of successful TLS key resets. The count of TLS secret key resets is reset when the channel instance ends.

Note: TLS 1.3 key resets are integral to TLS 1.3, and not communicated to applications. As a result, on z/OS queue managers, for receiver channels, this value will not be set when the channel is communicating using a TLS 1.3 CipherSpec. On distributed queue managers this value will not be accurate, and might even be set to zero at either end of a channel, when the channel is communicating using a TLS 1.3 CipherSpec.

Resetting SSL and TLS secret keys

I believe you could set SSLRKEYC = 0 so it does not renegotiate a key.

Resetting SSL and TLS secret keys

Queue manager

For a queue manager, use the command ALTER QMGR with the parameter SSLRKEYC to set the values used during key renegotiation.

Typically, SSLRKEYC change would be effective straight away. As per the below documentation link, the reset can be done on the Queue Manager side or the Client side. All details are within the link above, Please review them carefully. 

Resetting SSL and TLS secret keys

After this is you can refresh the Queue Manager’s security cache.

You can also set the environment variable “GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE” on both client/qmgr side to disable this restriction.

Kindly go through the below technotes.

Change in behaviour for channels using GCM based CipherSpecs.

You can manually set environment variables as below: 

 In Windows.. 


 in Unix/Linux 


then start the manager.

Or set the environmental variable into mqm user’s .profile, (if MQ is started by mqm user.)

Also to prevent this error from happening, You can use a different CipherSpec that does not use GCM and is not affected by the TLS limit. You can find the complete list and details from IBM document.

Enabling CipherSpecs

Following a recommendation by GSKit, TLS 1.2 GCM CipherSpecs have a restriction which means

that after 2ˆ24.5 TLS records are sent, using the same session key, the connection is terminated

with message AMQ9288. This GCM restriction is active, regardless of the FIPS mode being


To prevent this error from happening, avoid using TLS 1.2 GCM Ciphers, enable secret key

reset, or start your IBM MQ queue manager or client with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set. For GSKit libraries, you must set this environment variable on both sides of the connection, and apply it to both client to queue manager connections and queue manager to queue manager connections. Note that this setting affects unmanaged .NET clients, but not Java™ or managed .NET clients.

This restriction does not apply to IBM MQ for z/OS.

Related document:

About the “SSLRKEYC 0 was already there on the qmgr” issue, I have consulted to mq development team and will get back to you once they update case.

MQ has implemented the recommendation, and by default TLS
connections using a GCM cipherspec will terminate when the
transfer limit of 2^24.5 TLS records using the same session
key is reached.

Any such termination will be reported in the error log with
error code AMQ9288.

The 2^24.5 transfer limit means 23 726 566 TLS records using
the same session key. As each TLS record has a maximum size of
16KB, this presents a theoretical data limit of 379 625 056 KB,
approximately 362 GB. The amount of data transferred may be
lower, as not all TLS records exchanged on the connection may be
at full capacity.

Customers wishing to use GCM cipherspecs should consider use of
the SSLRKEYC attribute to enforce a session key reset once a set
amount of data has been transferred. As the limit applies to
records with the same session key, resetting the session key
before reaching the limit allows the connection to continue

Alternatively, setting the environment variable
GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE in the environment used to
start the queue manager remains valid to disable the reduced
transfer limit.

Note that this change does not affect MQ on IBM i. On IBM i, the
GSKit configuration is maintained at the system level and should
be configured as described in the IBM i system administration

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *