【问题标题】:2538 error on MQ for SSL channel connection用于 SSL 通道连接的 MQ 上的 2538 错误
【发布时间】:2023-03-23 09:02:01
【问题描述】:

我使用的是 IBM WebSphere MQ 8.0 版本。

我已使用“TLS_RSA_WITH_AES_256_CBC_SHA256”密码规范加密配置我的通道之一,并安装了有效证书并正确映射到密钥存储路径。

我的 .NET 客户端代码无法连接到此安全通道。它连续给出2538错误。 我配置了另一个没有加密的通道(不安全)。客户端代码可以正常连接到这个通道。

这是我的 .NET 客户端代码:

        Hashtable queueProperties = new Hashtable();
        queueProperties[MQC.HOST_NAME_PROPERTY] = host; // IP address
        queueProperties[MQC.PORT_PROPERTY] = 1541
        queueProperties[MQC.CHANNEL_PROPERTY] = channel; // channel name
        queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED;
        queueProperties[MQC.SSL_CERT_STORE_PROPERTY] = "*USER";
        queueProperties[MQC.SSL_CIPHER_SPEC_PROPERTY] = "TLS_RSA_WITH_AES_256_CBC_SHA256";
        queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "CN=FXCMTST1,O=IBM,C=US";
        queueProperties["CertificateLabel"] = "ibmwebspheremqfxcmtst1";
        queueProperties[MQC.KEY_RESET_COUNT] = 0;
        MQEnvironment.SSLCertRevocationCheck = true;
        queueProperties[MQC.USER_ID_PROPERTY] = user; // variable
        queueProperties[MQC.PASSWORD_PROPERTY] = pwd; // variable
        try
        {
            // Attempt the connection
            queueManager = new MQQueueManager(qmgr, queueProperties);
            strReturn = "Connected Successfully";
        }

我还将 MCA 用户设置为具有所有必需访问权限的有效用户。

当我删除这些行并将频道名称替换为不安全的频道名称时,上述代码适用于不安全的频道。

    queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED;
    queueProperties[MQC.SSL_CERT_STORE_PROPERTY] = "*USER";
    queueProperties[MQC.SSL_CIPHER_SPEC_PROPERTY] = "TLS_RSA_WITH_AES_256_CBC_SHA256";
    queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "CN=FXCMTST1,O=IBM,C=US";
    queueProperties["CertificateLabel"] = "ibmwebspheremqfxcmtst1";
    queueProperties[MQC.KEY_RESET_COUNT] = 0;
    MQEnvironment.SSLCertRevocationCheck = true;

我是否遗漏了代码或 MQ 配置中的任何内容?

更新 1: 我发现错误是由于关键数据库的路径不正确。我已经提到了放置证书的文件夹名称的路径。但是,它应该是文件夹名称,后跟不带扩展名的 kdb 文件名称。

进行此更改后,2538 错误消失了。但现在我收到 2059 错误,日志中显示以下错误消息。

“在 SSL 握手期间协商的 CipherSpec 与通道所需的 CipherSpec 不匹配...”

我的频道配置为具有我在 MQ Explorer 中设置的“TLS_RSA_WITH_AES_256_CBC_SHA256”。客户端代码也发送相同的密码规范。它仍然给出 2059 错误。

更新 2:正如@JoshMc 所建议的,我设置了组策略并解决了上述错误。然后我开始收到错误“频道缺少证书”。

更新 3:在我将 SSLCAUTH 更改为 OPTIONAL 后,此错误消失了。之前它被设置为 REQUIRED。感谢@JoshMc 指出。

【问题讨论】:

  • 我没有安装完整的客户端。我只是在我的代码中使用 .Net dll 来连接 MQ 服务器。另外,我将按照您的建议更改对等名称。
  • 如果是这种情况,那么即使在执行 TLS 时,您也不需要设置 MQC.TRANSPORT_PROPERTY,因为在未安装客户端时 dll 默认为托管模式。让我知道日志显示的内容,同时执行客户端 .Net 跟踪可能会为您指明正确的方向。
  • @JoshMc 包含 MQC.TRANSPORT_PROPERTY 仍然是个好主意
  • @Roger 同意,意思是指出,在没有 TLS 的情况下删除该行作为测试的一部分不会有任何影响,因为没有安装客户端。我应该措辞更好。
  • SSL_CERT_STORE_PROPERTY -->D:\\temp\\eClient\\client_certificate,我设置了这个属性(没有.kdb)但我还是取了2538,你最新的工作代码示例是什么@AnilSoman跨度>

标签: .net ibm-mq


【解决方案1】:

最初在您的问题中,您有以下代码行:

queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "ibmwebspheremqtestqueue";

我建议:SSL_PEER_NAME_PROPERTY 旨在验证队列管理器证书的部分或全部 DN 值,因此它的格式类似于 CN=x.domain.com,OU=Y,O=Company Inc,您所拥有的看起来像证书标签。

如果队列管理器 AMQERR01.LOG 有错误,您能看到产生了什么错误吗?在本地客户端 AMKERR01.LOG 中呢?

您以来自队列管理器的错误响应:

AMQ9660: SSL key repository: password stash file absent or unusable.

并且您在每次更新时都发现了错误:

更新:我发现错误是由于密钥数据库的路径不正确。我已经提到了放置证书的文件夹名称的路径。但是,它应该是文件夹名称,后跟不带扩展名的 kdb 文件名称。

现在您继续收到以下错误:

The CipherSpec negotiated during the SSL handshake does not match the required CipherSpec for channel...

我建议:托管 .net 不使用您指定的密码,它是从 Windows 策略中提取的。这个问题和答案应该对“IBM MQ.Net CertificateLabel, CipherSpec”有所帮助。

您建议您修复了组策略,然后当您在 SVRCONN 频道上设置 SSLCAUTH(REQUIRED) 时出现以下错误:

channel is lacking a certificate

SSLCAUTH(REQUIRED) 告诉队列管理器您要求客户端拥有证书。无论SSLCAUTH 设置为什么,客户端都将始终要求队列管理器拥有证书。

假设您已将队列管理器配置为执行CONNAUTH 以验证您发送的用户和密码,并且您已在CONNAUTHAUTHINFO 对象上设置ADOPTCTX(YES),那么拥有SSLCAUTH(OPTIONAL) 是合理的设置,因为这意味着客户端和队列管理器之间的所有数据都将被加密,并且连接由 id/pw 进行身份验证。即使您有SSLCAUTH(REQUIRED),除非您还通过通道的SSLPEER 属性或CHLAUTH TYPE(SSLPEERMAP) 规则的SSLPEER 属性配置SVRCONN 以匹配特定的DN 值,否则它不提供任何形式的身份验证。

【讨论】:

  • 我终于将 SSLCAUTH 设置为 OPTIONAL 并且效果很好。我这样做是因为我们想使用单向加密方法而不是双向加密。现在连接正常。感谢您的帮助和知识分享@JoshMc
猜你喜欢
  • 2020-01-12
  • 1970-01-01
  • 2012-05-02
  • 1970-01-01
  • 2013-11-08
  • 2012-10-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多