ssl - QM具有特殊字符时，WMQ自签名SSL相互身份验证失败

我有两个在两个盒子上运行的队列管理器服务器。 QM1定义了一个发送方通道，QM2定义了一个同名接收方通道。
我为每个QM创建了自签名证书，提取了每个证书的公共部分并将其添加到其他QM的密钥数据库中。更改每个通道以使用CipherSpec TRIPLE_DES_SHA_US。

如果QM名称不包含任何特殊字符，则此设置可以很好地工作。如果发送方QM的名称为A_QM，另一个为B_QM，则发送方通道将永远不会出现并且处于RETRYING状态。

创建自签名证书时，我正在使用标签ibmwebspheremqa_qm
 如果队列管理器是QM1，则在A_QM和ibmwebspheremqqm1的情况下。同样，在添加证书的公共部分时，我会保留其他QM的标签。这是整个设置的唯一区别。

如果要配置SSL或TLS，定义QM名称是否有任何限制？

最佳答案

我毫不费力地创建了一对描述的QMgr和通道并使它们运行：

[mqm@rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.


dis chs(*) all
     1 : dis chs(*) all
AMQ8417: Display Channel Status details.
   CHANNEL(A_QM.B_QM)                      CHLTYPE(SDR)
   BATCHES(0)                              BATCHSZ(50)
   BUFSRCVD(1)                             BUFSSENT(1)
   BYTSRCVD(268)                           BYTSSENT(268)
   CHSTADA(2015-04-01)                     CHSTATI(10.57.43)
   COMPHDR(NONE,NONE)                      COMPMSG(NONE,NONE)
   COMPRATE(0,0)                           COMPTIME(0,0)
   CONNAME(127.0.0.1(3115))                CURLUWID(0C031C5501020010)
   CURMSGS(0)                              CURRENT
   CURSEQNO(0)                             EXITTIME(0,0)
   HBINT(300)                              INDOUBT(NO)
   JOBNAME(0000130700000001)               LOCLADDR(127.0.0.1(53145))
   LONGRTS(999999999)                      LSTLUWID(0000000000000000)
   LSTMSGDA( )                             LSTMSGTI( )
   LSTSEQNO(0)                             MCASTAT(RUNNING)
   MONCHL(OFF)                             MSGS(0)
   NETTIME(0,0)                            NPMSPEED(FAST)
   RQMNAME(B_QM)                           SHORTRTS(10)
   SSLCERTI(CN=rhel6base.ioptconsulting.com)
   SSLKEYDA( )                             SSLKEYTI( )
   SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
   SSLRKEYS(0)                             STATUS(RUNNING)
   STOPREQ(NO)                             SUBSTATE(MQGET)
   XBATCHSZ(0,0)                           XMITQ(B_QM)
   XQTIME(0,0)                             RVERSION(08000001)
   RPRODUCT(MQMM)

[mqm@rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
!   ibmwebspheremqb_qm
*-  ibmwebspheremqa_qm
[mqm@rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
!   ibmwebspheremq_a_qm
*-  ibmwebspheremqb_qm
[mqm@rhel6base ssl]$

刷新安全类型（SSL）
您所看到的行为的最可能原因是在更新密钥库后不发布刷新安全性或不重新启动QMgr。例如：

echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM

要么

endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM

密钥库的安全性的一个方面是一次在内存中只有一个版本。如果一个频道可能有一个版本，而另一个频道可能有另一个版本，则不可能确定哪个是“正确的”版本以检测篡改。因此，当更新KDB时，refresh security命令使QMgr停止所有正在运行的TLS通道，从内存中转储KDB，并在其中一个通道启动时重新加载KDB。

（顺便说一句，MQ从未使用过SSL。它使用带有SSL密码的TLS，现在SSL本身已损坏，最好习惯于说TLS，因为这将有助于记住以后继续使用TLS密码。 ）

因此，在更新KDB之后，如果您没有运行刷新，则很可能是刷新没有完成，并且QMgr尚不知道为远程QMgr新添加的证书。

如果SSLCAUTH（OPTIONAL）不是可选的
TLS的另一个常见问题是对SSLCAUTH(OPTIONAL)的误解。许多人认为，这总是导致单向身份验证，因此他们设置SSLCAUTH(OPTIONAL)然后仅在一个方向上交换证书。例如，QM1具有通向QM2的TLS通道，因此显然具有其自己的个人证书。然后，我们尝试将A_QM连接到它。我们将A_QM的个人证书导入QM1的KDB，在各处刷新安全性，在两侧均DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL)并尝试启动通道。

误解是，如果启动通道的事物具有个人证书，它将在所有情况下发送该证书。要使用SSLCAUTH(OPTIONAL)进行测试，需要从启动连接一侧的密钥库中删除任何个人证书。人们通常没有意识到这一点，并且花费许多时间（在某些情况下为数周）努力了解其失败原因。

为了您的目的，请始终双向交换个人证书。

不完整的证书交换
使用自签名证书的另一个常见问题是，多次生成具有相同标签和/或CN值的证书，并且一端的个人证书与另一端的公共部分不匹配。通过查看证书详细信息并检查指纹和其他详细信息是否匹配，可以轻松地进行检查，如下所示：

[mqm@rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
    30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
    05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
    8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
    37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
    D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
    32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
    F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
    4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
    C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
    3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
    00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
    55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
    BF 16 1C 62
Fingerprint : MD5 :
    90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
    7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
    2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
    AuthorityKeyIdentifier
      keyIdentifier: 8D BC 64 AF D9 12 02 34
      authorityIdentifier:
      authorityCertSerialNumber:
    SubjectKeyIdentifier
      keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
    46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
    89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
    E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
    AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
    80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
    C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
    78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
    38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm@rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
    30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
    05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
    8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
    37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
    D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
    32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
    F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
    4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
    C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
    3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
    00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
    55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
    BF 16 1C 62
Fingerprint : MD5 :
    90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
    7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
    2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
    AuthorityKeyIdentifier
      keyIdentifier: 8D BC 64 AF D9 12 02 34
      authorityIdentifier:
      authorityCertSerialNumber:
    SubjectKeyIdentifier
      keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
    46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
    89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
    E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
    AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
    80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
    C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
    78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
    38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled

调试
检查错误日志。特别是，良好的安全性设计是使攻击者尽可能少的信息以始终检查首先接收连接的QMgr的日志。如果检测到错误，它将有详细的日志，发送方将有稀疏的日志，如“远程QMgr断开连接”，这对攻击者而言并没有太多的信息。

如果错误实际上在发送方，那么它将包含最详细的错误消息，而接收方则几乎没有或没有。例如，如果发送方找不到其隐藏文件，则不会尝试建立连接，并且接收方将没有该事件的记录。

最后，总是有可能发现使用GSKit和MQ的错误，或者尝试使用与正在处理的MQ版本无关的功能。因此，最好在问题中加入dspmqver -a。如果在上述所有步骤之后仍无法正常工作，请使用dspmqver -a输出和进一步测试的结果来更新问题。

综上所述
总结一下：


像A_QM这样的QMgr名称是完全有效的。
首先，通过重新启动QMgr或运行REFRESH SECURITY TYPE(SSL)，确保更改后QMgr拾取了新的KDB文件。
确保每次都双向交换证书。
从接收连接请求的一侧开始，检查两侧的错误日志。
请求有关GSKit，证书或TLS的帮助时，请始终包含dspmqver -a的输出，因为行为因版本和修订包而异。