当QM具有特殊字符时，WMQ自签名SSL相互认证失败

时间：2015-03-28 15:40:15

标签： ssl ibm-mq mq

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

如果QM名称不包含任何特殊字符，则此设置完全正常。如果发件人QM的名称是A_QM而另一个是B_QM，则发件人通道永远不会出现并处于RETRYING状态。

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

如果我想配置SSL或TLS，是否有限制QM名称的限制？

1 个答案:

答案 0 :(得分：3)

我按照描述创建一对QMgrs和频道并让它们运行时没有问题：

[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）
您看到的行为的最可能原因是在更新其密钥库后不发出刷新安全性或重新启动QMgrs。例如：

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时，刷新安全性命令会导致QMgr停止所有正在运行的TLS通道，从内存中转储KDB，并在其中一个通道启动时重新加载KDB。

（顺便说一句，MQ不使用SSL，从来没有。它使用带有SSL密码的TLS，现在SSL本身已损坏，最好习惯说TLS，因为这有助于记住使用TLS密码专门用于向前发展。）

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

当SSLCAUTH（可选）不可选时 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名称完全有效。
  • 首先确保QMgrs在更改后通过重新启动QMgrs或运行REFRESH SECURITY TYPE(SSL)来获取新的KDB文件。
  • 确保每次都双向交换证书。
  • 从接收连接请求的一方开始检查双方的错误日志。
  • 在请求GSKit，证书或TLS帮助时始终包含dspmqver -a的输出，因为行为因版本和修订包而异。
相关问题
最新问题