ibm-mq - 将证书部署到 keystore 后是否需要 "refresh security type(ssl)"命令

Question

在我们将更新的证书部署到 keystore 之后，是否需要refresh security type(ssl) 命令。我通常在证书续订后执行此命令，但我看到了未执行此命令但 channel 仍然获取新证书的情况。放入 keystore 的证书是立即生效还是我们需要执行 ssl 刷新。

Answer 1

为确保所有进出队列管理器的连接都使用 keystore 中的当前信息，您应该始终在进行任何更新后运行 REFRESH SECURITY TYPE(SSL)(例如私钥甚至添加新的可信 CA 证书)。

---

任何 MQ 进程第一次需要访问 keystore 时，该进程将读取 keystore 并将其缓存在内存中。在默认配置中，与队列管理器的连接由持续运行的进程处理，因此在与需要 key 存储的队列管理器的第一个入站连接之后，它们将保留该 key 存储缓存。在默认配置中，出站 channel 连接使用单独的 runmqchl 进程，这些进程在 channel 启动时启动，因此它们每次总是读取当前 key 存储。

这意味着在某些情况下，即使没有 REFRESH SECURITY TYPE(SSL) 也可以正常工作，例如:

1. 如果带有 MCATYPE(PROCESS) 的 SDR channel 启动，则会启动一个新的 runmqchl 进程，并将读取 key 存储并获取任何更改。
2. 如果自上次启动队列管理器后没有接收到入站 TLS 连接，那么即使您对 keystore 进行了更改，它们也会在第一次接收到入站 TLS 连接时被获取。

---

Morag Hughson 在 Capitalware 的 MQ 技术 session v2.0.1.4 上发表了题为“MQ SSL/TLS Channels Including V8 changes”的演讲。 PDF 第 10 页的注释部分很好地总结了 REFRESH SECURITY TYPE(SSL) 的作用。

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 在 IBM MQ 知识中心对此进行了记录，下面是包含有关该主题的信息的两页:

IBM MQ v7.5 KC 页面“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 页面“REFRESH SECURITY”指出:

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.