我正在使用T.Rob的建议调试Websphere MQ Server和Client之间的SSL错误，需要帮助理解SSL握手（SSL connect to MQ using .net mq client SSLV3?）。
我的WMQ 7.5客户端应用程序是C代码并使用密钥库（.kdb）。使用WebSphere管理员提供的CHLTAB。 WMQ服务器正在运行Java，并且通过相互身份验证定义了通道。
文章指出，在SSL / TLS握手中，服务器始终发送其公共证书以响应连接请求。然后，客户端必须首先检查签名和有效日期，然后在其信任存储区中查找签署证书的内容，以验证该证书。
这是我的困惑：由于我客户端的密钥库只有应用程序个人证书，客户端如何验证服务器发送的公共证书？我已经将我的应用程序证书的公共名称提供给WebSphere服务器管理员，但仅此而已。
提前感谢您的澄清！
答案 0 :(得分：2)
关于＆＃34;客户端的密钥库只有应用程序个人证书＆＃34;令人不安。那不会奏效。客户端KDB 必须拥有服务器的公钥。如果MQ服务器具有SSLCAUTH(OPTIONAL)，则服务器的公共证书就是KDB中为连接成功所需的全部内容。
TLS握手的第一部分是客户端验证服务器证书的位置。公钥/私钥对的使用是如何确保另一方的事物的真实性。为了实现这一点，服务器必须拥有自己的个人证书，并且客户端必须具有签名者链的根的公钥。在自签名证书的情况下，客户必须信任个人证书的公共部分。对于CA签名的证书，客户端必须信任CA Root。无论客户是谁，客户都必须信任用于签署服务器个人证书的内容，或者该证书无法通过验证。
TLS握手是对称的，因此第二部分的工作方式与第一部分完全相同，但角色是相反的。因此，在启用相互身份验证的情况下，客户端必须拥有自己的个人证书（因为它包含私钥），而服务器必须信任任何已签名的客户端＆＃39 ;匹配公钥。如果客户端证书是自签名的，则QMgr必须信任它。如果客户端的证书是CA签名的，则QMgr必须信任签名者。无论哪种方式，QMgr都必须有一个证书来验证其KDB中的客户端。
遵循此逻辑，对于匿名客户端连接，所需部分是QMgr密钥库中的个人证书（因为它包含QMgr的私钥），以及客户端中匹配的可信证书＆＃39 ; s KDB或Java用于Trust Store。这些都不是可选的。
如果要对客户端进行身份验证，则仍需要与匿名客户端相同的两个证书，因为在对客户端进行身份验证之前必须完成握手的这一部分。此外，现在您还需要客户端拥有自己的个人证书（因为它包含客户端的私钥），并且QMgr现在需要信任任何已签名的客户端证书 - 如果是自己的客户端证书-signed或签名者root，如果CA签名。
作为旁注，帖子中也有一些混乱，因为它说＆＃34;我的WMQ 7.5客户端应用程序是C代码，而WMQ服务器运行Java。＆＃34;队列管理器中没有任何东西在服务器端使用Java。安装了Java组件来执行诸如管理JNDI对象和运行示例代码之类的操作。在现代MQ版本中，Java运行Web控制台。但是QMgr本身没有Java组件，传入通道连接请求的路径中没有Java组件。这些都是由QMgr的听众，代理和其他内部流程所笼罩的。所以除了在MQ服务器端运行并参与TLS握手的Java概念可能是帖子中提到的一些混淆的来源之外，我完全不确定在那里被引用的是什么。 ; - ）