The error you see is that your keystore does not have CA signing certificates and / or intermediate signatures. When you receive a signed certificate from a certification authority, it must be verified before adding it to the keystore. Very many could intercept your request for signature and signed the certificate. The step of checking it upon receipt ensures that it has been signed by a CA that you really trust, and not some kind of anonymous person in the middle.
The way to verify the certificate is to verify the CA signature on the CA public key that is in your KDB. To do this, the CA certificate must already be in KDB when you try to get a signed certificate. If the CA uses an intermediate certificate of the signer (and for a variety of reasons, any commercial CA will use intermediate certificates), then you must also import the intermediate certificate and the root certificate. This creates a certificate chain or certificate path from the CA root certificate through any intermediate certificates to your signed certificate. Every thing in the chain authenticates above it until you get to the root. Your KDB must have the whole chain, and because each certificate is checked one on it, you must import them with the root and work down.
Typically, your CA will post its signatory certificates on its website, where you will receive them using SSL. Run them and import, and you can get a signed certificate.
How this happens, the Sphere Online Journal published an article in which you review this process using Verisign as an example, as well as screenshots of the import of root and intermediate signer certificates. 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 certificates and the signed certificate.
Let me also take you to the right InfoCenter. Please see the Infocenter WMQ v7.0 section on Using Certificates with CA Certificate . The one you were looking for is for Message Broker, and frankly, the article related to you is a bit messy. I will see how to fix it. Firstly, this bit about creating a certificate in one kdb, subscribing it, then exporting it, deleting it and importing it into QMgr KDB is pure rubbish. Just create a CSR in your own KDB QMgr file and get a signed certificate directly to it. This is much simpler and the process is illustrated in the above article.
Finally, if you go to t-rob.net and download the WMQ Security Lab from IMPACT 2011, you will find a lab guide and some scripts there. They use self-signed certificates, but the scripts can easily be converted to use certificates signed by CA, and then adapted for use on your network WMQ.
UPDATE:
Answering additional questions in the comments:
I actually plan on using a self-signed certificate, so I think I only need to extract it and add it to the client trust store?
Yes this is correct. But here is the problem on the WMB Infocenter page, which was originally related to asking you to create a certificate with the qmgrname tag instead of ibmwebspheremqqmgrname . QMgr finds its certificate based on the label and therefore must conform to the specified format. Therefore, when you create your self-signed certificate, make sure the label is a literal ibmwebspheremq with the name QMgr folded in lowercase. If you made a certificate with the wrong label, you can always export it to a P12 file and then import it into a new KDB with the right label.
I used the WMQ SSL wizard mentioned in the WMQ Security Lab to create the correct configuration. The configuration went smoothly, but when I run the JMS sample included in the SSL wizard, I get the error message MQJE001: Completion Code '2', Reason '2397' , SSL logs show 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 several reasons why this could happen. Instead of going through all of them, I suggest some diagnostic methods. When I configure SSL channels, I always use the following procedure:
- Get a channel without SSL. This proves that the main communication channel is working (listener operation, port correspondence, correspondence of channel object descriptions, etc.).
- If this is the first time QMgr is using SSL, or if kdb has been modified, be sure to issue the
REFRESH SECURITY TYPE(SSL) command. - Enable SSL by specifying the same ciphersuite in QMgr and the client, but make sure the QRCG SVRCONN channel is set to
SSLCAUTH(OPTINAL) SSLPEER() . This confirms that the client accepts the QMgr certificate. Only after that proceed to the next step. - Now change the QMgr SVRCONN to
SSLCAUTH(REQUIRED) SSLPEER() . This causes QMgr to request a client certificate. - If you are using
SSLPEER , set it to the desired value.
This process isolates potential problems, so at any time you know where to look. If the process failed at step 3, then there is a problem with the configuration of the SSL application or it cannot verify the QMgr certificate. If the process failed in step 4, then we know that the SSL configuration for the application sounds and he likes the QMgr bu certificate, which QMgr does not like the application certificate. If we go to step # 5, it’s just a matter of valid SSLPEER .
Since you got a handshake error that seems to be related to QMgr closing the TCP connection, I assume that you have SSLCAUTH(REQUIRED) (by the way, this is the default), and that QMgr does not have an application certificate or that you tried to use an anonymous connection if the client does not require a personal certificate. If so, setting SSLCAUTH(OPTIONAL) will lead you to a point of failure - although possibly a completely new point of failure.