ibm mq - WMQ self-signed SSL mutual authentication fails when QM has special character -

i have 2 queue manager servers running on 2 boxes. qm1 has sender channel defined , , qm2 has receiver channel same name. have created self signed certificate each qm , extracted , added public part of each certificate other qm's key db. altered each channel use cipherspec triple_des_sha_us.

this setup works fine, if qm names don't contain special character. if name of sender qm a_qm , other 1 b_qm , sender channel never comes , in retrying state.

while creating self-signed certificate using label ibmwebspheremqa_qm in case of a_qm , ibmwebspheremqqm1 when queue manager qm1. when adding public part of certificate preserving other qm's label. difference in whole setup.

is there restriction in defining qm names if want configure ssl or tls ?

i had no trouble creating pair of qmgrs , channels described , getting them run:

[mqm@rhel6base scripts]$ runmqsc a_qm 5724-h72 (c) copyright ibm corp. 1994, 2014. starting mqsc queue manager a_qm.   dis chs(*)      1 : dis chs(*) 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]$  

refresh security type(ssl)
cause behavior seeing not issuing refresh security or restarting qmgrs after updating keystores. example:

echo "refresh security type(ssl)" | runmqsc a_qm echo "refresh security type(ssl)" | runmqsc b_qm 

or

endmqm -i a_qm; strmqm a_qm endmqm -i b_qm; strmqm b_qm 

one aspect of security keystore there ever 1 version of in memory @ time. if possible 1 channel have 1 version , channel have version, become impossible determine "right" 1 in order detect tampering. when kdb updated, refresh security command causes qmgr stop running tls channels, dump kdb memory, , reload kdb when 1 of channels starts.

(mq doesn't use ssl, way, never has. uses tls ssl ciphers , ssl broken, best used saying tls because remember use tls ciphers exclusively going forward.)

so after updating kdb if did not run refresh, refresh not done , qmgr doesn't yet know newly added certificate remote qmgr.

when sslcauth(optional) not optional
common problem tls misunderstanding of sslcauth(optional). many people believe always results in one-way authentication set sslcauth(optional) , exchange certs in 1 direction. example, qm1 has tls channels qm2 has own personal certificate. try connect a_qm it. import a_qm's personal cert qm1's kdb, refresh security everywhere, def chl(a_qm.qm1) ... sslcauth(optional) on both sides , try start channel.

the misunderstanding if thing initiating channel has personal cert will send in cases. test sslcauth(optional) requires removing personal cert keystore on side initiating connection. people not realize , spend many hours (in cases weeks) struggling understand why fails.

for purposes exchange personal certs in both directions.

incomplete cert exchange
other common problem working self-signed certs when cert generated multiple times same label and/or cn value , there's mismatch between personal cert on 1 end versus public portion on other. checked viewing cert details , checking fingerprint , other details match so:

[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 edt not after : march 31, 2016 10:54:42 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 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 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 edt not after : march 31, 2016 10:54:42 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 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 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 

debugging
check error logs. in particular, security design give attacker little information possible check logs of qmgr receiving connection first. if has detected error have detailed logs , sending side have sparse logs "the remote qmgr disconnected" doesn't reveal attacker.

if error on sending side, have detailed error messages , receiving side have little or none. example, if sending side can't find stash file connection isn't ever attempted , receiving side have no record of event.

finally, there possibility may discover bug working gskit , mq, or trying use features not relevant version of mq working on. reason, best include dspmqver -a in question. if after of this, still can't work, please update question dspmqver -a output , results of further testing.

in summary
sum up:

• qmgr names a_qm valid.
• first make sure qmgrs have picked new kdb files after changes restarting qmgrs or running refresh security type(ssl).
• make sure exchange certs in both directions every time.
• check error logs on both sides starting side receiving connection request.
• always include output dspmqver -a when requesting gskit, certs or tls since behavior varies version , fix pack.