Hi Bhushan,

Is it possible that either:-

• There were no channels running at the time and thus when the TLS channel using the new certificate was started it was the first channel to use TLS and so an in-memory copy of the key repository was taken at that time which included the new addition?
• The number of channels running was such that a new amqrmppa process was started to handle this new channel, and thus this was the first channel to use TLS in that process, and so an in-memory copy of the key repository was taken at that time which included the new addition?

The REFRESH command is required when changes are made to the contents of the key repository because MQ takes an in-memory copy of the contents and uses that. It does not go back to the 'real' key repository again unless you REFRESH or restart the queue manager.

However, MQ channels run as threads in amqrmppa processes, and each process will take this in-memory copy the first time it finds it needs it. This means that newer copies may contain updates that older copies do not have. This can make it appear like an internal refresh has taken place, but it is just an artefact of the pattern of threads starting in new processes.

There is no documentation about a security cache refresh interval time because that does not exist. However, the above behaviour that I have described is documented in IBM Docs here: When changes to certificates or the certificate store become effective on AIX, Linux, and Windows

I hope that makes the behaviour you are seeing, clearer. There is no guarantee that waiting even a week will make the certificate available.

Cheers,
Morag

Thank you Morag for explaining!
We will make sure to execute - REFRESH SECURITY TYPE(SSL)  which will guaranteed refresh the security cache and there is no another alternative other than just trying a luck :) 

Hi Bhushan,

Is it possible that either:-

• There were no channels running at the time and thus when the TLS channel using the new certificate was started it was the first channel to use TLS and so an in-memory copy of the key repository was taken at that time which included the new addition?
• The number of channels running was such that a new amqrmppa process was started to handle this new channel, and thus this was the first channel to use TLS in that process, and so an in-memory copy of the key repository was taken at that time which included the new addition?

The REFRESH command is required when changes are made to the contents of the key repository because MQ takes an in-memory copy of the contents and uses that. It does not go back to the 'real' key repository again unless you REFRESH or restart the queue manager.

However, MQ channels run as threads in amqrmppa processes, and each process will take this in-memory copy the first time it finds it needs it. This means that newer copies may contain updates that older copies do not have. This can make it appear like an internal refresh has taken place, but it is just an artefact of the pattern of threads starting in new processes.

There is no documentation about a security cache refresh interval time because that does not exist. However, the above behaviour that I have described is documented in IBM Docs here: When changes to certificates or the certificate store become effective on AIX, Linux, and Windows

I hope that makes the behaviour you are seeing, clearer. There is no guarantee that waiting even a week will make the certificate available.

Cheers,
Morag