SSL使用.net mq客户端SSLV3连接到MQ?

我不确定我是否同意您的结论，因为WMQ支持SSL V3.0和TLS V1.0

I'm not sure I agree with your conclusion since WMQ has supported SSL V3.0 and TLS V1.0 since at least V6.0 and possibly earlier. This is more likely a mismatch of configurations between the client and server. The procedure I recommend to resolve SSL/TLS issues is as follows:

我在WMQ上调试SSL连接的方法是按照以下顺序进行，以确保在前进到下一个步骤之前，每个步骤均有效:

My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:

1. 使通道在没有SSL的情况下运行.这可以验证通道名称是否正确拼写，端点之间存在网络路由，QMgr的侦听器正在运行以及客户端指向正确的端口.您会惊讶于有人误输入端口或通道名称的次数.
2. 使通道在SVRCONN定义设置为SSLCAUTH(OPTIONAL)的情况下运行.这将执行类似于您的浏览器的匿名SSL连接. QMgr向客户端出示证书，但客户端没有义务将证书发回.这验证了QMgr可以找到其证书，并且客户端可以找到其信任库并正确地验证了QMgr的证书. (注意:QMgr将始终请求客户端证书，并且如果存在证书，客户端将始终发送该证书.要执行此测试，请使用客户端密钥库的副本，该副本具有签名者证书，而不是应用程序的个人证书.复制密钥库并从副本中删除个人证书.请勿删除原始证书！)
3. 将SVRCONN通道设置为SSLCAUTH(REQUIRED).现在，这要求客户端找到其密钥库(在最后一步中，它仅需要其信任库)并能够找到其证书.它还要求QMgr能够验证客户的证书.
4. 设置SSLPEER或CHLAUTH映射规则以缩小将在通道上接受的经过验证的证书的数量.

1. Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port. You'd be surprised how many times someone mis-keys a port or channel name.
2. Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but the client is not obligated to send one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert. (Note: the QMgr will always request the client cert and the client will always send it if one is present. To perform this test, use a copy of the client's keystore that has the signer cert(s) but not the application's personal cert. Copy the keystore and delete the personal cert from the copy. Do NOT delete the original!)
3. Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
4. Set up SSLPEER or CHLAUTH mapping rules to narrow the population of validated certificates that will be accepted on the channel.

步骤2和步骤3之间的差异有助于通过一次仅在一个方向上测试SSL凭证交换来隔离问题.这使您可以确定问题是存在于个人证书还是公共证书中以及通道的哪一侧.这两个步骤几乎解决了所有问题.

The difference between steps #2 and #3 helps to isolate the problem by testing the SSL credential exchange in only one direction at a time. This allows you to identify whether the problem exists in the personal cert or the public cert and on which side of the channel. Nearly all problems are sorted out in these two steps.

更新
回答问题的注释. SSL/TLS使用两种类型的证书.个人证书包含私钥，并且是不会被传递的证书.公共证书是包含公共密钥的证书，可以免费颁发.私钥保存在密钥库中.公钥(通常是CA的根证书和中间证书)存储在信任库中.在某些情况下，这些是单独的文件.例如，在Java和JMS中，JSSE提供程序在环境中查找指向密钥库和信任库的变量.在Java和JMS中，密钥库和信任库变量可能指向同一文件.

UPDATE
Notes to respond to questions. There are two types of certificate used with SSL/TLS. The personal certificate contains the private key and is the one that doesn't get passed around. The public certificate is the one that contains the public key and can be given out freely. The private key is held in a keystore. The public keys (usually these are the CA's root and intermediate certs) are stored in a trust store. In some cases, these are separate files. For example, in Java and JMS the JSSE provider looks in the environment for variables that point to the keystore and to the trust store. It is possible in Java and JMS that the keystore and trust store variables point to the same file.

对于Java以外的WebSphere MQ服务器和客户端，将密钥库和信任库组合到一个位置.通常称为kdb文件，它实际上是CMS密钥数据库，由几个文件组成，其中一个文件是KDB.在这种情况下，密钥库"实际上是组合的密钥库和信任库的简写.对于.Net客户端，请在

In the case of WebSphere MQ servers and clients other than Java, the keystore and trust store are combined into a single location. Often referred to as a kdb file, it is actually a CMS key database comprised of several files of which one is the KDB. In this case "keystore" is actually shorthand for a combined keystore and trust store. For the .Net client, set the keystore location and other SSL properties in the MQEnviornment.

在SSL/TLS握手中，服务器总是发送其公共证书以响应连接请求.然后，客户端必须通过首先检查签名和有效日期，然后在其信任库中查找对证书进行签名的事物来验证该证书.如果对证书进行签名的事物是中间签名者证书(它本身已经由某人签名)，则搜索将继续在签名者证书链上进行，直到到达根证书为止.假设服务器已通过身份验证，则通过使客户端出示证书并由服务器对其进行验证，来反向应用相同的过程.

In the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate. If the thing that signed the certificate is an intermediate signer cert (it has itself been signed by something) then the search continues up the signer cert chain until the root cert is reached. Assuming that the server is authenticated, the same procedure is applied in reverse by having the client present a cert and the server validating it.

当步骤2中的过程失败时，我们可以使用上述过程的知识进行调试. QMgr必须首先在其密钥库中找到其证书，并将其提交给客户端.如果QMgr找不到其证书，则结果是AMQERR01.LOG文件中指出此错误.当步骤2中所有问题消失时，请始终首先关注QMgr！

When the process fails in Step #2 we can debug using knowledge of the process above. The QMgr must first find its cert in its keystore and present it to the client. If the QMgr cannot find its cert, the result is errors in the AMQERR01.LOG file stating this. Always look on the QMgr side first when things die in Step #2!

如果QMgr 找到了它的证书，那么下一步就是客户端必须能够找到其信任库，然后在该信任库中必须找到必要的签名者证书链.如果失败，则客户端应有错误表明这一点.例如，设置客户端环境时的常见错误是指定整个文件名，包括.kdb扩展名.发生这种情况时，QMgr将查找不存在的[keystorename].kdb.kdb.另一个常见错误是个人证书存在于密钥库中，但标签错误.非Java WMQ客户端按标签名称查找证书，该标签名称由文字字符串ibmwebspheremq和小写的用户ID构成.例如，如果我的用户ID是TRob，那么我的证书标签将是ibmwebspheremqtrob.请注意，这是密钥库中证书的标签，而不是证书的通用名称"或专有名称"中的其他字段.

If the QMgr does find its cert then the next step is that client must be able to find its trust store and then within that trust store must find the necessary signer cert chain. If this fails, there should be errors on the client side to indicate that. For example, a common error when setting the client environment is to specify the entire file name, including the .kdb extension. When this happens the QMgr looks for [keystorename].kdb.kdb which doesn't exist. Another common error is that the personal certificate exists in the keystore but with the wrong label. Non-Java WMQ clients look for the certificate by label name constructed from the literal string ibmwebspheremq followed by the user ID in lower case. For example, if my user ID is TRob then my certificate label would be ibmwebspheremqtrob. Note that this is the certificate's label in the keystore and NOT the certificates Common Name or other field in the Distinguished Name.

取决于所用客户端的类型，这些可能在Windows错误日志，本地MQ错误日志或其他位置中.如果找不到客户端错误，请 WMQ跟踪也是一种选择.

Depending on the type of client in use, these may be in the Windows error log, local MQ error logs or other location. If you can't find client-side errors, WMQ tracing is also an option.