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.
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=attributes-channel-status-properties
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
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=messages-resetting-ssl-tls-secret-keys
I believe you could set SSLRKEYC = 0 so it does not renegotiate a key.
Resetting SSL and TLS secret keys
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=messages-resetting-ssl-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
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=messages-resetting-ssl-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.
https://www.ibm.com/support/pages/change-behavior-channels-using-gcm-based-cipherspecs
https://www.ibm.com/support/pages/apar/IT33239
You can manually set environment variables as below:
In Windows..
set GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE
in Unix/Linux
export GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE
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
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=messages-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
used.
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:
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=messages-enabling-cipherspecs#q014260___d59e8308
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 indefinitely. 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 guidance.