比方说，我在host1中使用了一个队列管理器QMGR1来创建一个CSR，并获得一个标记为ibmwebspheremqmgr1的CA验证证书。我可以在另一个主机主机2中为名为same的队列(即QMGR1)加载相同的证书(及其根链和中间链)吗？换句话说，当我们使用rumqakm"接收"证书时，需要存在certreq，还是不存在？我们可以像添加证书一样添加证书吗？如果问题不清楚，请询问，我可以提供更多详细信息。在我的情况下，host2是生产。host1是一个QA环境，我们在其中测试连接。谢谢
从评论26DEC16
针对MQ，我认为我必须首先在host2上加载CSR，然后再次接收CER，对吗？我想知道如何在不创建CSR的情况下"加载"CSR。我在runmqakm中看到了一个重新创建CSR的选项，以前从未使用过，也不确定这是否有效。
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。通常，您希望证书标签反映使用它的QMgr的名称，因此不建议使用名为QMGR2、CERTLABL为ibmwebspheremqqmgr1的QMgr。
如果导入证书，则可以在导入命令期间设置标签。
请记住，标签和专有名称是两个完全不同且不相关的东西。可分辨名称是CA验证和签署的值，并以加密方式绑定到证书中的密钥。它是远程连接伙伴决定是否信任的东西。
标签是本地QMgr或客户端查找自己证书的方式。假设您创建了两个个人证书，QMgr需要知道要发送哪一个。它通过将证书的标签与ibmwebspheremq[qmgr name in lower case]的预期值匹配来找到正确的证书，如果该值不为空，则根据QMgr的CERTLABL属性匹配。
这就是为什么证书标签可以通过GSKit命令轻松更改，但可分辨名称是不可变的。
考虑到这一点，请注意，外部和许多内部CA都希望证书的证书通用名包含将使用证书的完全限定主机名。HTTPS客户端在连接时会检查证书CN是否与主机名匹配。对于MQ连接，情况并非如此。您可以将您的CA将签署的任何内容放入CN中，并在任何任意名称的QMgr上使用它。所以你的证书可以有CN=QMGR1，QMgr可以住在mqhost.yourcompany.com上，MQ很喜欢它。但是，使用新的MQRESTneneneba API的客户端不会对于希望使用新的MQRESTneneneba API的人来说，这是一个重要的区别。
最后，请注意，最佳做法是在将要使用证书的位置生成证书，使用文件系统权限保护证书，将证书保存在本地存储中，并且永远不要从该位置复制或移动证书。公钥/私钥加密是为了解决安全交换私钥这一非常困难的问题而发明的。如果个人证书被复制在周围，它会首先破坏使用它们的目的。
各种商业PKI软件包(即IBM Tivoli Key Lifecycle Manager、Venafi等)都使用FIPS认证的算法来解决这个问题，这些算法不将密钥或加密基元存储在磁盘上，在释放之前安全地擦除内存空间，并且通常要非常小心，不要在传输、磁盘或内存中留下不受保护的密钥。如果你必须复制个人证书，如果公司有，就使用一个真正的PKI包。否则，请将它们导出到具有超长随机密码的.p12中，并避免使用电子邮件、FTP或其他不安全的方式复制文件。