MQ

I don't know the answer, but I wonder if it could have to do with need to set both passwords? I saw odd behaviour when working with JKS (after being prompted to check because of the way PKCS#12 works), which I wrote about here. Might be nothing of course.

Are you providing the passwords as part of the MQ Explorer config or as Java system properties (-D flags)? Does it behave differently if you do?

Cheers,
Morag

Hi Luc-Michel,

Are you setting the keystore information for MQ Explorer in the Preferences ->MQ Explorer -> Client Connection->SSL Key Repositories?

Is your key password the same as the store password?
Is any password using the default?

Did you try running with trace and especially with -Djavax.net.ssl="Debug"

You need to check if the keystore you defined is really getting used...or if the open attempt is for a different keystore...

Hope it helps

I've tried both methods: 
- entering the password via Preferences
- entering the password when prompted upon opening the store
Otherwise: 
- both passwords are identical; there is only one Key Repository
- I don't use a default password

This is a very surprising situation because:
- I created several versions of the JKS using different tools --> same problem
- I tested with 4 or 5 versions of MQ Explorer --> same problem
The only constants are:
- the TLS certificate and its root (but already used without issue in PKCS12 stores)
- the JRE version on the workstation where MQ Explorer is installed
It's too bad MQ Explorer doesn't support PKCS12—it would be so much more convenient!

Does it work if you import the pkcs12 keystore into a JKS keystore? (runmqktool)

It sounds like running MQExplorer with -Djavax.net.debug=all (JSSE trace) would be helpful here to get more details on why this is failing. Please also note this thread below that goes into some tips on how to capture a JSSE trace for MQExplorer.

https://community.ibm.com/community/user/discussion/mqexplorer-runwithtracecmd-and-javaxnetdebugsslhandshake

Side suggestion - use the MQ Web Console UI. An improving utility IBM has started to focus on.

Is the Key and jks password different? is there a password for the key?

Hello,

Over the past few days, I've spent a lot of time working on this issue.
On my laptop, I ran cross-checks on certificates, store formats, creation syntax, MQ Explorer versions, and more.
The goal was to create a documented, reproducible process.
Environment:
- Windows 11 Pro 35 H2
- IBM MQ version 9.4.2
- MQ Explorer versions 9.4.0.0, 9.4.4, 9.4.5

Here is a summary of my findings:
If you create a JKS keystore directly using runmqktool, the password is not recognized in MQ Explorer.
However, if you create a PKCS12 keystore using runmqakm and then convert that keystore to JKS using runmqktool, there are no longer any password issues with MQ Explorer.

Example 1: Direct JKS
runmqktool -importcert -keystore magcli1b.jks -storepass Pangolin19 -alias “CA_OFDC_A” -file CA_OFDC_A.crt -storetype JKS
(the storetype parameter is important; otherwise, by default a PKCS12 keystore is created)

runmqktool -importkeystore -srckeystore CLIS1.p12 -srcstoretype PKCS12 -srcstorepass mqseries -destkeystore magcli1b.jks -deststorepass Pangolin19 -deststoretype jks 

runmqktool -list -storetype jks -keystore magcli1b.jks -storepass Pangolin19
Certificates detected
* default, - personal, ! secure, # secret key
!       CA_OFDC_A
-       clientmq1

--> The keystore password is therefore: Pangolin19

Using this keystore in MQ Explorer:
The keystore file could not be opened using the specified password (AMQ4508).

Example 2: PKCS12 -> JKS
runmqakm -keydb -create -db magcli1a.p12 -pw Pangolin19 -type pkcs12
runmqakm -cert -add -db magcli1a.p12 -pw Pangolin19 -label “CA_OFDC_A” -file CA_OFDC_A.crt -format ascii -fips
runmqakm -cert -import -file CLIS1.p12 -pw mqseries -type pkcs12 -target magcli1a.p12 -target_pw Pangolin19 -target_type pkcs12 
runmqakm -cert -list -db magcli1a.p12 -pw Pangolin19

Certificates detected
* default, - personal, ! secure, # secret key
!       CA_OFDC_A
-       clientmq1

runmqktool -importkeystore -srckeystore magcli1a.p12 -srcstoretype pkcs12 -srcstorepass Pangolin19 -destkeystore magcli1a.jks  -deststoretype jks -deststorepass Pangolin19

Using this keystore in MQ Explorer: ok

--> These tests are fully reproducible (on my laptop and on a Windows administration workstation)

I have a feeling that the way runmqktool (and therefore keytool) encrypts passwords isn't compatible with MQ Explorer.

Any ideas ?
Thanks in advance.

Luc Michel,

Your are doing it all wrong. MQ Explorer has a default password for things like that. To use your own password you will have to go to the client section in the (Windows) Preferences menu.
Check out the SSL key repository sub menu and set the key repository, and set the password for the key repository

Don't expect to be prompted for the key repository password.

Also which versions of Java did you check it with? Did you check to list the certs using the Keytool key from the JRE that comes with MQ Explorer?
I believe the key encryption might not be the same at different levels of Java (Java 8 vs Java 17)...

Password length and password rules matter. Try with a password length between 6 and 12 chars.