TL；DR：是的。
当您使用 IBM GSKit（例如 runmqakm）创建 CSR 时，结果是未签名的证书和 CSR 文件本身。 CSR 以加密方式绑定到保留在密钥库的.rdb 文件中的未签名证书。那时，签名的 CSR 不能被接收到任何密钥库中。
当您收到签名的 CSR 时，它会与待处理的未签名证书合并并移动到密钥库的 .kbd 文件中。此时，它是一个有效的个人证书，带有您指定的标签名称（在本例中为ibmwebspheremqqmgr1）和您指定的 DN。
完成后，您将拥有一个可用的个人证书。如果您想在另一个 QMgr 上使用它，您需要通过以下两种方式之一将该证书发送给另一个 QMgr：
- 复制构成密钥库的文件集。
- 将个人证书导出到文件中，然后将该文件导入到其他 QMgr 的密钥库中。
如果您复制了整个密钥库并且另一个 QMgr 也被命名为 QMGR1，那么您可以立即使用它们。如果另一个 QMgr 具有不同的名称，那么您必须将证书重命名为 ibmwebspheremqqmgr1 以外的名称，或者在现代 QMgr 中将 QMgr 的 CERTLABL 属性设置为 ibmwebspheremqqmgr1。通常，您希望 cert 标签反映使用它的 QMgr 的名称，因此不建议使用名为 QMGR2 且 CERTLABL 或 ibmwebspheremqqmgr1 的 QMgr。
如果您导入证书，那么您可以在导入命令期间设置标签。
请记住，标签和专有名称是两个完全不同且不相关的东西。专有名称是 CA 验证和签署的值，并以加密方式绑定到证书中的密钥。这是远程连接伙伴决定是否信任的事情。
标签是本地 QMgr 或客户端如何找到自己的证书。假设您创建了两个个人证书，QMgr 需要知道要发送哪一个。它通过将证书的标签与ibmwebspheremq[qmgr name in lower case] 的预期值相匹配或与 QMgr 的CERTLABL 属性（如果它不为空）匹配来找到正确的标签。
这就是为什么可以使用 GSKit 命令轻松更改证书标签但专有名称不可变的原因。
考虑到这一点，请注意，外部和许多内部 CA 将期望证书的证书公用名包含将使用证书的完全限定主机名。 HTTPS 客户端在连接时检查证书 CN 是否与主机名匹配。对于 MQ 连接，情况并非如此。您可以在 CN 中放入 CA 将签署的任何内容，并将其用于任意名称的 QMgr。所以你的证书可以有 CN=QMGR1 并且 QMgr 可以存在于 mqhost.yourcompany.com 上，并且 MQ 很喜欢它。但是，使用新 MQ REST API 的客户端不会！对于希望使用新 MQ REST API 的人来说，这是一个重要的区别。
最后，请注意，最佳做法是在将要使用它们的地方生成证书，使用文件系统权限保护它们，将它们保存在本地存储中，并且永远不要从该位置复制或移动它们。发明公钥/私钥加密是为了解决安全交换私钥的非常困难的问题。如果个人证书被复制，它首先会破坏使用它们的目的。
各种商业 PKI 软件包（即 IBM Tivoli Key Lifecycle Manager、Venafi 等）都使用 FIPS 认证的算法解决了这个问题，这些算法不在磁盘上存储密钥或加密原语，在释放内存空间之前安全地擦除内存空间，并且通常要格外小心，不要让密钥在传输、磁盘或内存中不受保护。如果您必须复制个人证书，请使用为该目的设计的真实 PKI 包（如果公司有）。否则，请将它们导出到 .p12，并使用非常长且随机的密码，并避免使用电子邮件、FTP 或其他不安全的方式复制文件。