I am unable to connect from wM IS 7.1.2 to MQ Series 6.0.2.3 over SSL. I don’t think this is a factor, but interestingly, MQ SSL works fine in single node environment; but fails in multi-node environments (using Cisco load balancer as opposed to wM clustering). The error message coming back to the wM MQ Adapter is “[ADA.600.3033] Connection to Queue Manager MyQMgr could not be initialized; cc=2,rc=2009”.

I think we’ve identified that the issue is that wM is not presenting it’s cert during the SSL handshake.

After turning on SSL debugging at the JVM level, here’s something I see in wM nohup.out:
HTTP Handler 10.139.82.246, SEND SSLv3 ALERT: warning, description = no_certificate

And for the same connection attempt, here’s what the MQ Admin sees on the MQ side:
AMQ9637: Channel is lacking a certificate.
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel name is ‘MY.CHANNEL’ (if ‘???’ it is unknown at this stage in the SSL processing). The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the key repositories for both ends of the channel.

I think the issue is on the wM side as opposed to something being wrong in MQ because I am able to connect to that same target MQ server from another wM environment.

Per our MQ Admin, here’s how all channels are defined on the MQ side:
DIS CHL(MY.CHANNEL)
1 : DIS CHL(MY.CHANNEL)
AMQ8414: Display Channel details.
CHANNEL(MY.CHANNEL) CHLTYPE(SVRCONN)
ALTDATE(2009-02-09) ALTTIME(13.28.09)
COMPHDR(NONE) COMPMSG(NONE)
DESCR(Client chl for App HBINT(300)
KAINT(AUTO) MAXMSGL(4194304)
MCAUSER(a_route) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SSLCAUTH(REQUIRED) SSLCIPH(TRIPLE_DES_SHA_US)
SSLPEER(CN=myCertName) TRPTYPE(TCP)

An update to the MQ SSL issue with IS712. No word yet from wM, but my gut feeling is that it’s a bug with IS712. We’ve noticed the MQ connections work in IS65 and IS711.

Anyway, I was able to figure out a not-so-great workaround that enabled me to at least get the MQ SSL connection working in IS712. If you load these following java parameters when you start up IS, the connection works. Of course, the downside is that you’ll be exposing MQ certificates’ passwords in clear text.

JAVA_ARG5=“-Djavax.net.ssl.keyStore=config/certs/keystore.jks”
JAVA_ARG6=“-Djavax.net.ssl.keyStorePassword=changeMe”
JAVA_ARG7=“-Djavax.net.ssl.trustStore=config/certs/keystore.jks”
JAVA_ARG8=“-Djavax.net.ssl.trustStorePassword=changeMe”

Do any of you out there know how I can configure this MQ connection where the trustStore password is encrypted?

Thanks,
Rajesh

We are getting the same MQ error on IS712. if you have any open ISR with webmethod for this?

Yes, we’ve opened this SR with SAG on this issue. We’ve been working their SSL SME and MQ Adapter development team (in Bangalore) and thus far have not identified any root cause.

SR is: “1-116601951 | wM to MQ SSL connection failing with rc=2009”

Interestingly, I installed IS711 on the same server hosting the IS712 that is not connecting to MQ. Whereas the IS712 can not connect, the IS712 MQ Adapter is able to connect to the same target MQ with no problems.

Another update to this issue. We noticed that when you disable the WmMonitor package, the MQ connections are able to use the keystore passwords in the MQ Admin GUI as designed (i.e. one doesn’t have to add java arguments upon startup that contain keystore passwords in clear text).

The problem is that we need services in WmMonitor to do things like purge wM’s internal db tables. So as a workaround, I found that this works:

1 - Disable WmMonitor, update each MQ conn individually to add the keystore password and restart IS
2 - When the IS comes up, enable the MQ connections. They should enable.
3 - Re-enable the WmMonitor package.

Does anyone know of any fixes for this or perhaps understand why there could be a link between WmMonitor and MQ SSL connections? We’ve opened a subsequent SR with SAG.