Is a "refresh security type(ssl)" command needed after deploying the certs into the keystore

To ensure that all connections in or out of the queue manager are using current information in the key store you should always run the REFRESH SECURITY TYPE(SSL) after any updates are made (for example to the private key or even adding new trusted CA certs).

The first time any MQ process needs to access the key store, the process will read the key store and cache it in memory. In a default configuration the connections into the queue manager are handled by processes that keep running so they would hold onto that key store cache after the first inbound connection to the queue manager which requires the key store. In a default configuration outbound channel connections use separate runmqchl processes that start when the channel is started so they always read the current key store each time.

This means that in some cases things may work without a REFRESH SECURITY TYPE(SSL) for example:

1. If a SDR channel with MCATYPE(PROCESS) starts, a new runmqchl process is started and will read the key store fresh and pick up any changes.
2. If no inbound TLS connection has been received since the last time the queue manager was started then even if you make changes to the key store they will be picked up the first time an inbound TLS connection is received.

Morag Hughson gave a presentation at Capitalware's MQ Technical Conference v2.0.1.4 titled "MQ SSL/TLS Channels Including V8 changes". The notes portion of page 10 of the PDF have a good summary of what REFRESH SECURITY TYPE(SSL) does.

Refreshing SSL on WebSphere MQ - Notes

• This feature was introduced in WebSphere MQ V6.
• The SSL environment set up to run SSL channels in a channel process has a cached view of the key repository made at initialization time. If you make changes to your key repository, i.e. add, remove or update certificates, for example, because your are replacing a certificate that is about to expire, this cached view needs to be refreshed in order for the SSL channels to start using the new certificates.
• In order to refresh this cached view of the SSL environment, without disrupting any non-SSL channels, use the REFRESH SECURITY TYPE(SSL) command. This will stop all the SSL channels on the queue manager, new cached view(s) of the key repository will be made and all the sending type channels will be started again. Receiving type channels will get restarted as the partner end retries the connection.
• Non-SSL channels will be unaffected by this command and will continue to run.
• Also use this command to pick up other changes, such as a new Key Repository locations, or new LDAP CRL/ARL locations.

IBM documents this in the IBM MQ Knowledge Center, below are two pages with information on the topic:

IBM MQ v7.5 KC page "Refreshing SSL or TLS security"

About this task

When a channel is secured using Secure Sockets Layer (SSL) or TLS, the digital certificates and their associated private keys are stored in the key repository. A copy of the key repository is held in memory while a channel is running. If you make a change to the key repository, you can refresh the copy of the key repository that is held in memory without restarting the channel.

When you refresh the cached copy of the key repository, all SSL or TLS channels that are currently running are updated:

• Sender, server, and cluster-sender channels that use SSL or TLS are allowed to complete the current batch of messages. The channels then run the SSL handshake again with the refreshed view of the key repository.
• All other channel types that use SSL or TLS are stopped. If the partner end of the stopped channel has retry values defined, the channel retries and runs the SSL handshake again. The new SSL handshake uses the refreshed view of the contents of the key repository, the location of the LDAP server to be used for the Certificate Revocation Lists, and the location of the key repository. In the case of server-connection channel, the client application loses its connection to the queue manager and has to reconnect to continue.

MQ v7.5 KC page "REFRESH SECURITY" states:

Usage notes for REFRESH SECURITY

When you issue the REFRESH SECURITY TYPE(SSL) MQSC command, all running SSL channels are stopped and restarted. Sometimes SSL channels can take a long time to shut down and this means that the refresh operation takes some time to complete. There is a time limit of 10 minutes for an SSL refresh to complete (or 1 minute on z/OS), so it can potentially take 10 minutes for the command to finish. This can give the appearance that the refresh operation has "frozen". The refresh operation will fail with an MQSC error message of AMQ9710 or PCF error MQRCCF_COMMAND_FAILED if the timeout is exceeded before all channels have stopped. This is likely to happen if the following conditions are true:

• The queue manager has many SSL channels running simultaneously when the refresh command is invoked
• The channels are handling large numbers of messages

If a refresh fails under these conditions, retry the command later when the queue manager is less busy. In the case where many channels are running, you can choose to stop some of the channels manually before invoking the REFRESH command.

...

When using TYPE(SSL):

3. On platforms other than z/OS, the command updates all SSL channels regardless of whether a security refresh is needed.
4. If a refresh is to be performed, the command updates all SSL channels currently running, as follows:
   • Sender, server and cluster-sender channels using SSL are allowed to complete the current batch. In general they then run the SSL handshake again with the refreshed view of the SSL key repository. However, you must manually restart a requester-server channel on which the server definition has no CONNAME parameter.
   • All other channel types using SSL are stopped with a STOP CHANNEL MODE(FORCE) STATUS(INACTIVE) command. If the partner end of the stopped message channel has retry values defined, the channel retries and the new SSL handshake uses the refreshed view of the contents of the SSL key repository, the location of the LDAP server to be used for Certification Revocation Lists, and the location of the key repository. In the case of a server-connection channel, the client application loses its connection to the queue manager and has to reconnect in order to continue.