目前，由于以下问题，我在连接服务器时遇到问题：
当我尝试连接到服务器时，它返回了一个错误：MQRC_SSL_INITIALIZATION_ERROR
通过 WireShark 进行更仔细的分析后，我发现客户端正在尝试使用 SSL v2 连接到服务器，而服务器只能接受 SSL V3 ，因此拒绝连接。
我查看了该文件，但无法找到任何相关信息 .Net客户端支持的SSL版本。
我想检查SSL版本是否是从.Net MQ控制的 客户端，如果是这样，我们如何配置以通过SSL v3进行连接？
感谢。
答案 0 :(得分：6)
我不确定我是否同意您的结论，因为WMQ支持SSL V3.0和TLS V1.0 since at least V6.0，可能更早。这很可能是客户端和服务器之间配置不匹配的原因。我建议解决SSL / TLS问题的程序如下：
我在WMQ上调试SSL连接的方法是按照以下顺序进行，确保每个步骤在前进到下一步之前有效：
SSLCAUTH(OPTIONAL)的情况下运行通道。这将执行类似于浏览器操作的匿名SSL连接。 QMgr向客户提供证书，但客户没有义务发回一个。这验证了QMgr可以找到其证书，并且客户端可以找到其信任存储并正确验证QMgr的证书。 （注意：QMgr将始终请求客户端证书，如果存在，则客户端将始终发送它。要执行此测试，请使用具有签名者证书的客户端密钥库的副本但不是应用程序的个人证书。复制密钥库并从副本中删除个人证书。不要删除原件！）SSLCAUTH(REQUIRED)。现在，这需要客户端找到其密钥库（在最后一步中它只需要其信任存储）并能够找到其证书。它还要求QMgr能够验证客户端的证书。步骤＃2和＃3之间的区别有助于通过一次仅在一个方向上测试SSL凭证交换来隔离问题。这使您可以识别个人证书或公共证书中是否存在问题以及渠道的哪一方。几乎所有问题都在这两个步骤中得到了解决。
<强>更新
回答问题的注释。 SSL / TLS使用两种类型的证书。个人证书包含私钥，并且是不会被传递的私钥。公共证书是包含公钥的公证书，可以自由发放。私钥保存在密钥库中。公钥（通常是CA的根证书和中间证书）存储在信任库中。在某些情况下，这些是单独的文件。例如，在Java和JMS中，JSSE提供程序在环境中查找指向密钥库和信任库的变量。在Java和JMS中，密钥库和信任库变量可以指向同一个文件。
对于WebSphere MQ服务器和Java以外的客户端，密钥库和信任库将合并到一个位置。它通常被称为kdb文件，它实际上是一个CMS密钥数据库，由几个文件组成，其中一个是KDB。在这种情况下＆＃34; keystore＆＃34;实际上是组合密钥库和信任存储的简写。对于.Net客户端，请在MQEnviornment中设置密钥库位置和其他SSL属性。
在SSL / TLS握手中，服务器始终发送其公共证书以响应连接请求。然后，客户端必须首先检查签名和有效日期，然后在其信任存储区中查找签署证书的内容，以验证该证书。如果签署证书的东西是中间签名者证书（它本身已由某些东西签名），则搜索继续向上签署者证书链，直到达到根证书。假设服务器已通过身份验证，则通过让客户端提供证书并使服务器验证它来反向应用相同的过程。
当步骤＃2中的流程失败时，我们可以使用上述流程的知识进行调试。 QMgr必须首先在其密钥库中找到其证书并将其呈现给客户端。如果QMgr无法找到其证书，则结果是AMQERR01.LOG文件中的错误说明了这一点。当第2步中的事情消失时，总是先看看QMgr方面！
如果QMgr 找到其证书，那么下一步是客户端必须能够找到其信任存储，然后在该信任存储中必须找到必要的签名者证书链。如果失败，客户端应该有错误来指示。例如，设置客户端环境时的常见错误是指定整个文件名，包括.kdb扩展名。发生这种情况时，QMgr会查找不存在的[keystorename].kdb.kdb。另一个常见错误是个人证书存在于密钥库中但标签错误。非Java WMQ客户端通过标签名称查找证书，该名称由文字字符串ibmwebspheremq构成，后跟小写的用户ID。例如，如果我的用户ID是TRob，那么我的证书标签将是ibmwebspheremqtrob。请注意，这是密钥库中的证书标签，而不是可分辨名称中的证书Common Name或其他字段。
根据所使用的客户端类型，这些可能位于Windows错误日志，本地MQ错误日志或其他位置。如果您无法找到客户端错误，WMQ tracing也是一种选择。