我使用T.Rob的建议来调试Websphere MQ服务器和客户端之间的SSL错误，并需要帮助了解SSL握手（SSL connect to MQ using .net mq client SSLV3?）。Websphere MQ服务器和客户端之间的SSL/TLS握手
我WMQ 7.5客户端应用程序是C代码，并使用密钥库（名.kdb）。使用WebSphere管理员提供的CHLTAB。 WMQ服务器正在运行Java，并且通道被定义为相互认证。
该文章指出，在SSL/TLS握手中，服务器总是发送其公共证书以响应连接请求。然后，客户必须首先检查签名和有效日期，然后在其信任库中查找签署证书的东西，以验证该证书。
这是我的困惑：由于我在客户端的密钥库只有应用程序的个人证书，客户端如何验证服务器发送的公共证书？我已将我的应用程序证书的通用名称提供给WebSphere服务器管理员，但仅此而已。
预先感谢澄清！
关于“我的客户端上的密钥库仅在应用程序的个人证书”的位，令人担忧。这是行不通的。客户端KDB 必须有有服务器的公钥。如果MQ服务器具有SSLCAUTH(OPTIONAL)，则服务器的公共证书是KDB中所需的全部功能，以使连接成功。
TLS握手的第一部分是在客户端验证服务器的证书。公钥/私钥对的使用是如何保证对方事物的真实性。为了发生这种情况，服务器必须拥有自己的个人证书，并且客户端必须拥有签署者链根的公钥。对于自签证书，个人证书的公开部分必须由客户信任。对于CA签名的证书，CA Root必须受到客户端的信任。它是哪一个，用来签署服务器的个人证书客户必须信任的东西，或者证书不能被验证。
TLS握手是对称的，所以第二部分与第一部分完全相同，但角色相反。因此，在启用双向身份验证的情况下，客户端必须拥有自己的个人证书（因为该证书包含私钥），并且服务器必须信任与客户端匹配的公钥的任何签名。如果客户证书是自签名的，QMgr必须信任它。如果客户的证书是CA签名的，QMgr必须信任签名者。无论哪种方式，QMgr必须有一个证书来验证客户端的KDB。
遵循此逻辑，对于匿名客户端连接，所需的部分是QMgr密钥库中的个人证书（因为它包含QMgr的私钥）以及客户端KDB或Java Trust Trust中匹配的可信证书。这些都不是可选的。
如果要对客户端进行身份验证，则仍然需要与匿名客户端相同的两个证书，因为握手部分必须在客户端通过身份验证之前完成。此外，现在你还需要在客户端拥有自己的个人证书（因为它包含了客户端的私钥）和QMGR现在需要信任任何签署了客户端证书 - 客户端证书如果自签名或签名的根，如果CA -签。
作为一个方面说明，也有在后一些混乱，因为它说，“我的WMQ 7.5客户端应用程序是C代码和WMQ服务器运行Java。”在服务器端使用Java的队列管理器中没有任何内容。有些Java组件可以用来管理JNDI对象并运行示例代码。在现代MQ版本中，Java运行Web控制台。但QMgr本身没有Java组件，传入通道连接请求的路径中没有Java组件。 QMgr的听众，代理商和其他内部流程都受到了限制。因此，我不能确定那里提到的是什么，除了在MQ服务器端运行的Java以及参与TLS握手的概念可能是该帖子中提到的一些混淆的来源。 ;-)
谢谢T.Rob的详细解释。使用MQ管理员，我们已经成功地通过步骤1和2调试SSL连接。在步骤3，用SRVCONN通道设置为SSLCAUTH（必填）我的客户端应用程序触发了以下错误： –
下面是来自客户端应用程序触发错误（运行用C语言编写的Linux V7.5）： AMQ9654：无效的SSL证书是从远程系统收到的。 我重建了.kdb并插入了一个SHA256证书（由Venafi创建）。想知道MQ服务器通道上指定的CypherSpec类型（TLS_RSA_WITH_AES_128_CBC_SHA256）是否存在兼容性问题？ –
除非您在通道上使用椭圆曲线密码，否则该证书应该起作用。由于不清楚所看到的错误是在客户端还是在服务器端，但是假设这是一个QMgr错误，听起来像您可能需要在客户端上走签署者链，以确保服务器拥有正确的可信签名者。此外，在更新KDB之后，您在QMgr上执行了“刷新安全类型（SSL）”或重新启动它，对吧？ –
您客户端的密钥库有个人证书。个人证书是一对密钥。有公共部分和私人部分。公共部分可以用来验证服务器的信任。 – Alaine