将证书部署到密钥库后是否需要 "refresh security type(ssl)" 命令
Is a "refresh security type(ssl)" command needed after deploying the certs into the keystore
在我们将更新的证书部署到密钥库后是否需要 refresh security type(ssl) 命令。我通常在证书续订后执行此命令，但我看到了未执行此命令但渠道仍然获取新证书的情况。放入密钥库的证书是立即生效还是我们需要执行ssl刷新。
为确保所有进出队列管理器的连接都使用密钥库中的当前信息，您应该始终 运行 REFRESH SECURITY TYPE(SSL) 在进行任何更新后（例如对私有密钥甚至添加新的可信 CA 证书）。
任何 MQ 进程第一次需要访问密钥存储时，该进程将读取密钥存储并将其缓存在内存中。在默认配置中，进入队列管理器的连接由保持 运行ning 的进程处理，因此在与需要密钥存储的队列管理器的第一个入站连接之后，它们将保留该密钥存储缓存。在默认配置中，出站通道连接使用单独的 运行mqchl 进程，这些进程在通道启动时启动，因此它们每次总是读取当前密钥存储。
这意味着在某些情况下，即使没有 REFRESH SECURITY TYPE(SSL) 也可以工作，例如：
- 如果具有
MCATYPE(PROCESS) 的 SDR 通道启动，则会启动一个新的 运行mqchl 进程并将读取密钥库并获取任何更改。
- 如果自上次启动队列管理器后没有接收到入站 TLS 连接，那么即使您对密钥库进行了更改，它们也会在第一次接收到入站 TLS 连接时被拾取。
Morag Hughson 在 Capitalware 的 MQ 技术会议 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):
- On platforms other than z/OS, the command updates all SSL channels regardless of whether a security refresh is needed.
- 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.
在我们将更新的证书部署到密钥库后是否需要 refresh security type(ssl) 命令。我通常在证书续订后执行此命令，但我看到了未执行此命令但渠道仍然获取新证书的情况。放入密钥库的证书是立即生效还是我们需要执行ssl刷新。
为确保所有进出队列管理器的连接都使用密钥库中的当前信息，您应该始终 运行 REFRESH SECURITY TYPE(SSL) 在进行任何更新后（例如对私有密钥甚至添加新的可信 CA 证书）。
任何 MQ 进程第一次需要访问密钥存储时，该进程将读取密钥存储并将其缓存在内存中。在默认配置中，进入队列管理器的连接由保持 运行ning 的进程处理，因此在与需要密钥存储的队列管理器的第一个入站连接之后，它们将保留该密钥存储缓存。在默认配置中，出站通道连接使用单独的 运行mqchl 进程，这些进程在通道启动时启动，因此它们每次总是读取当前密钥存储。
这意味着在某些情况下，即使没有 REFRESH SECURITY TYPE(SSL) 也可以工作，例如：
- 如果具有
MCATYPE(PROCESS)的 SDR 通道启动，则会启动一个新的 运行mqchl 进程并将读取密钥库并获取任何更改。 - 如果自上次启动队列管理器后没有接收到入站 TLS 连接，那么即使您对密钥库进行了更改，它们也会在第一次接收到入站 TLS 连接时被拾取。
Morag Hughson 在 Capitalware 的 MQ 技术会议 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):
- On platforms other than z/OS, the command updates all SSL channels regardless of whether a security refresh is needed.
- 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.