The error that you are seeing is because your keystore does not have the signing CA's root and/or intermediate signer certificates. When you get a signed certificate back from the Certificate Authority it must be validated before adding it to the keystore. Pretty much anyone could have intercepted your signing request and signed the certificate. The step of validating it when received insures that it was signed by a CA that you actually trust and not some anonymous man-in-the-middle.
The way the cert is validated is by checking the CA signature against the public key of the CA that is in your KDB. For that the CA's certificate must already be in the KDB when you attempt to receive your signed cert. If the CA uses an intermediate signer certificate (and for a variety of reasons any commercial CA will use intermediate certs) then you must also have imported the intermediate cert and the root cert. This forms a certificate chain or certificate path from the CA's root cert through any intermediate certs to your signed certificate. Each thing in the chain is authenticated by the thing above it until you get to the root. Your KDB must have the entire chain and because each cert is validated by the one above it, you must import these beginning with the root and working your way down.
Typically your CA will have posted their signer certs on their web site where you retrieve them using SSL. Fetch those and import them and you will be able to receive your signed cert.
As it happens, The Sphere Online Journal just published an article that walks you through this process using Verisign as an example, and with screen shots of importing the root and intermediate signer certs. The article is about Renewing WebSphere MQ Certificates but the first part of the article creates a kdb file and a signing request, then imports the CA certs and the signed cert.
Let's also get you to the correct Infocenter. Please look at the WMQ v7.0 Infocenter's section on Using CA Signed Certificates. The one you were looking at is for Message Broker and quite frankly the article you linked to is a bit of a mess. I'll see about getting it fixed. For starters, that bit about creating the cert in one kdb, getting it signed, then exporting it, deleting it and importing it to the QMgr's KDB is pure rubbish. Just generate the CSR in the QMgr's own KDB file and receive the signed cert directly to it. This is much easier and is the process illustrated in the article mentioned above.
Finally, if you go to t-rob.net and download the WMQ Security Lab from IMPACT 2011 you will find there a lab guide and some scripts. These use self-signed certificates but the scripts can easily be converted to use CA signed certificates and then tailored for use in your WMQ network.
UPDATE:
Responding to he additional questions in the comments:
I'm actually planning to use a self-signed certificate, so I guess I only need to extract it and adding it to the client's trust store?
Yes, that is correct. But here's a problem in the WMB Infocenter page that was originally linked in that it asks you to create a cert with the label qmgrname instead of ibmwebspheremqqmgrname. The QMgr finds its cert based on the label and so it must match the specified format. So when you create your self-signed cert, mke sure that the label is the literalibmwebspheremq with the QMgr name folded to lower case appended. If you have made a cert with the wrong label, you can always export it to a P12 file and then import it to a new KDB with the right label.
I used the WMQ SSL Wizard mentioned in the WMQ Security Lab to create the proper configuration. The configuration went smoothly, but when I run the JMS sample included with the SSL Wizard I get the error MQJE001: Completion Code '2', Reason '2397', the SSL logs shows the following error main, received EOFException: error main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake main, SEND TLSv1 ALERT: fatal, description = handshake_failure
There are a few reasons why that might occur. Rather than going through all of them, I'll suggest some diagnostic techniques. When I set up SSL channels, I always use the following procedure:
- Get the channel running without SSL. This proves that the basic communication path is working (listener running, ports match, channel object definitions match, etc.).
- If this is the first time that the QMgr is using SSL, or if the kdb has changed, be sure to issue the
REFRESH SECURITY TYPE(SSL) command.
- Enable SSL by specifying the same ciphersuite at the QMgr and client but be sure that the QMgr's SVRCONN channel is set to
SSLCAUTH(OPTINAL) SSLPEER(). This verifies that the client accepts the QMgr's certificate. Only when this works, go to the next step.
- Now change the QMgr's SVRCONN to
SSLCAUTH(REQUIRED) SSLPEER(). This causes the QMgr to request the client's certificate.
- If using
SSLPEER set it to the desired value.
This process isolates the possible problems so that at any point you know where to look. If the process fails in Step #3 then there is either an issue with the SSL configuration of the application, or it cannot validate the QMgr's cert. If the process fails in Step #4 then we know the application's SSL configuration is sound and that it likes the QMgr's cert bu that the QMgr doesn't like the application cert. If we get to Step #5 then it's just a matter of getting the SSLPEER value correct.
Because you got a handshake failure that appears to be due to the QMgr closing the TCP connection, I am assuming that you have SSLCAUTH(REQUIRED) (which is the default, by the way) and that either the QMgr doesn't have the application's certificate or that you were attempting to use an anonymous connection where the client doesn't require a personal cert. If that is the case, setting SSLCAUTH(OPTIONAL) will get you past the point of failure - although possibly to an entirely new point of failure.
