| Author |
Message
|
| crossland |
 Posted: Thu Mar 04, 2004 6:01 am Post subject: SSL Channel is lacking a certificate |
 |
|
Master
Joined: 26 Jun 2001
Posts: 248
|
I am attempting to get a MQ client on Windows to connect to a MQ Server on hp unix with SSL.
Based on another posting, it looks as if the following are required:
QMGRA
private key A
root CA + intermediate CAs for key B
QMGRB
private key B
root CA + intermediate CAs for Key A
So, using gsk 6.0.5.39, I created certificates for the client CA and the UNIX QMGR CA:
gsk6cmd –keydb –create –db key.kdb –type cms -stash –pw password
gsk6cmd –cert –create –db key.kdb –pw password –label clientCA –dn “CN=clientCA,O=ORG,C=UK” –expire 1024
gsk6cmd –cert –create –db key.kdb –pw password –label QMGRCA –dn “CN=QMGRCA,O=ORG,C=UK” –expire 1024
I then generated private key and Certificate Signing Request for QMGR:
gsk6cmd –certreq –create –db key.kdb –pw password –label ibmWebSphereMQQMGR –dn “CN=ibmWebspheremqQMGR,O=ORG,C=UK” –file QMGRreq
gsk6cmd –cert –sign –file QMGRreq –db key.kdb –pw password –label QMGRCA –target QMGRcert.pem
and added it to the Unix repository:
gsk6cmd –cert –receive –file QMGRcert.pem –db key.kdb –pw password
and assigned the repository to the queue manager:
ALTER QMGR SSLKEYR(/Mqdev/QMGR/data/qmgrs/QMGR/ssl/key)
There is a file key.kdb in /Mqdev/QMGR/data/qmgrs/QMGR/ssl/key.
Then, I generated a private key and Certificate Signing Request for the client:
gsk6cmd –certreq –create –db key.kdb –pw password –label ibmWebSphereMQclient –dn “CN=ibmWebSphereMQclient,O=ORG,C=UK” –file clientreq
gsk6cmd –cert –sign –file clientreq –db key.kdb –pw password –label clientCA –target clientcert.pem
This was then exported to Windows:
gsk6cmd –cert –receive –file clientcert.pem –db key.kdb –pw password
gsk6cmd –cert –export –db key.kdb –pw password –label ibmWebSphereMQclient –target client.p12 –target_type pkcs12
ftp clientcert.p12 from unix to Windows (binary)
amqmcert –a –s clientcert.pem
import clientcert.p12 using IE. It showed clientCA as the CA on the certification path. Export the certificate, ticking “Yes, export the private key”. Tick “Include all certificates in certification path if possible”.
Displayed local certificate with amqmcert –k MY –l
Added the certificate with amqmcert –k MY –a xxxxx
and added the CA certificates on Windows:
amqmcert –a –s hpCA.cer
amqmcert –a –s QMGRCA.cer
When I use a MQ Java client to connect, the following is produced:
03/04/04 13:14:46
AMQ9637: Channel is lacking a certificate.
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel
name is '????' (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.
Can anyone help please? |
|
| Back to top |
|
 |
| crossland |
| Posted: Thu Mar 04, 2004 6:25 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
| That's weird - the '-' character has been replaced with – |
|
| Back to top |
|
|
| crossland |
| Posted: Thu Mar 04, 2004 6:40 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Let me try and repost without the weird characters:
I am attempting to get a MQ client on Windows to connect to a MQ Server on hp unix with SSL.
Based on another posting, it looks as if the following are required:
QMGRA
private key A
root CA + intermediate CAs for key B
QMGRB
private key B
root CA + intermediate CAs for Key A
So, using gsk 6.0.5.39, I created certificates for the client CA and the UNIX QMGR CA:
gsk6cmd -keydb -create -db key.kdb -type cms -stash -pw password
gsk6cmd -cert -create -db key.kdb -pw password -label clientCA -dn 'CN=clientCA,O=ORG,C=UK' -expire 1024
gsk6cmd -cert -create -db key.kdb -pw password -label QMGRCA -dn 'CN=QMGRCA,O=ORG,C=UK' -expire 1024
I then generated private key and Certificate Signing Request for QMGR:
gsk6cmd -certreq -create -db key.kdb -pw password -label ibmWebSphereMQQMGR -dn 'CN=ibmWebspheremqQMGR,O=ORG,C=UK' -file QMGRreq
gsk6cmd -cert -sign -file QMGRreq -db key.kdb -pw password -label QMGRCA -target QMGRcert.pem
and added it to the Unix repository:
gsk6cmd -cert -receive -file QMGRcert.pem -db key.kdb -pw password
and assigned the repository to the queue manager:
ALTER QMGR SSLKEYR(/Mqdev/QMGR/data/qmgrs/QMGR/ssl/key)
There is a file key.kdb in /Mqdev/QMGR/data/qmgrs/QMGR/ssl/key.
Then, I generated a private key and Certificate Signing Request for the client:
gsk6cmd -certreq -create -db key.kdb -pw password -label ibmWebSphereMQclient -dn 'CN=ibmWebSphereMQclient,O=ORG,C=UK' -file clientreq
gsk6cmd -cert -sign -file clientreq -db key.kdb -pw password -label clientCA -target clientcert.pem
This was then exported to Windows:
gsk6cmd -cert -receive -file clientcert.pem -db key.kdb -pw password
gsk6cmd -cert -export -db key.kdb -pw password -label ibmWebSphereMQclient -target client.p12 -target_type pkcs12
ftp clientcert.p12 from unix to Windows (binary)
amqmcert -a -s clientcert.pem
import clientcert.p12 using IE. It showed clientCA as the CA on the certification path. Export the certificate, ticking 'Yes, export the private key'. Tick 'Include all certificates in certification path if possible'.
Displayed local certificate with amqmcert -k MY -l
Added the certificate with amqmcert -k MY -a xxxxx
and added the CA certificates on Windows:
amqmcert -a -s hpCA.cer
amqmcert -a -s QMGRCA.cer
When I use a MQ Java client to connect, the following is produced:
03/04/04 13:14:46
AMQ9637: Channel is lacking a certificate.
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel
name is '????' (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.
Can anyone help please? |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Mar 04, 2004 9:58 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
The amqmcert side of things if for native client only. If you are coming in from a java client then its a different thing altogether
No idea how this will come out, but example:
| Quote: |
Set up a Java client so that it can connect to a Qmgr without SSL involved.
On the UNIX Queue Manager side:
Create a key repository for the Qmgr:
gsk6cmd -keydb -create -db key.kdb -pw passw0rd -type cms -expire 365 -stash
Add the CA certificate to the QMgrs key repository:
gsk6cmd -cert -add -db key.kdb -label MYCA -file ca.cer -pw passw0rd
Add the personal certificate to the QMgrs key repository:
gsk6cmd -cert -import -file SignedQmgrCert.p12 -type pkcs12 -pw certificate_passw0rd -target key.kdb -target_pw passw0rd
Use runmqsc to alter the appropriate server channel to specify an SSLCIPH which the Java client will also use. Also ensure SSLCAUTH(OPTIONAL) is specified.
Recycle the QMgr to ensure the changes to the key repository are pick up.
On the Client side (platform independant):
Locate the 'cacerts' file, normally found in JAVA_HOME/jre/lib/security and copy it to a separate location. ALTER IT'S NAME TO 'trustStore'
Add the ca certificate to the trust store using 'keytool', a Java utility supplied with a JRE which is used to administer certificates for use with Java applications:
keytool -import -keystore trustStore -file ca.cer -alias "My CA Certificate" -storepass changeit
Note: By default the password for the trustStore will be 'changeit'. This can be modified using the keytool program, but for the purposes of this prb I will leave it as 'changeit'.
At this stage test the connection is working by altering the application to use the appropriate CIPHER SPEC and then invoke the application using the following syntax:
java -Djavax.net.ssl.trustStore=\location\of\trustStore sslConn
This should complete with no problems. If required you can download this simple java client to test this, but note you will need to modify it to specify the correct channel name, cipher spec, QMgr name and so on....
Back on the UNIX Queue Manager side...
Alter the SVRCONN channel to specify 'SSLCAUTH(REQUIRED)'
Back to the Client side....
Create a certificate request and a keystore using keytool. This certificate will be used by the Java client to authenticate itself to the Qmgr. NOTE that the country code (c) MUST be the same as that of the CA if using OpenSSL to sign the certificate later.
keytool -genkey -keystore keyStore -storepass changeit -keypass changeit -dname "cn=JavaCertName, ou=Department, o=Company, c=GB, st=StateOrCounty" -alias myclient -keyalg RSA -keysize 2048
Export the Java client's certificate request from the keyStore (for signing by the CA certificate):
keytool -certreq -keystore keyStore -storepass changeit -keypass changeit -alias myclient -file client.crs
Copy the certificate request generated (client.crs) to the CA directory where the CA certficate and Qmgr certificate were previously generated. Sign the certificate using OpenSSL:
openssl ca -in client.crs -out client.pem -keyfile ca.key -cert ca.cer
Then convert the certificate from PEM format into X509 format for importing back into the keyStore....
openssl x509 -in client.pem -out client.der -outform DER
Import the CA certificate into the client's keyStore:
keytool -import -keystore keyStore -storepass changeit -alias myclient -keypass changeit -import -file ca.cer
Import the signed certificate back into the client's keyStore:
keytool -import -keystore keyStore -storepass changeit -alias myclient -keypass changeit -import -file client.der
Run your test program again, specifying these two options:
-Djavax.net.ssl.trustStore=/location/of/trustStore
-Djavax.net.ssl.keyStore=/location/of/keyStore
Eg: java -Djavax.net.ssl.trustStore=/location/of/trustStore -Djavax.net.ssl.keyStore=/location/of/keyStore sslConn
|
I make no guarantees this will work, but let us know...  |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Mar 04, 2004 10:00 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
That uses openssl to sign the certificate, but I think GSKit can do it (from another article:)
| Quote: |
Create a certificate in a Java keyStore.
e.g. keytool -genkey -dname "CN=MyClient" –alias MyClient -storepass changeit -keypass changeit –keyStore keyStore
Create a certificate request file from the newly created certificate.
e.g. keytool -certreq -keystore keyStore -storepass changeit -keypass changeit -alias MyClient -file MyClient.crs
Sign the certificate request with the servers certificate (acting CA)
NOTE: The expire value must be less than that of the servers certificate.
e.g. gsk6cmd -cert -sign -file MyClient.crs -db /var/mqm/qmgrs/qm/ssl/Mykey.kdb -pw changeit -label ibmwebspheremqqm -target MyClient.cer -format binary -expire 300
Import the signed certificate into the Java KeyStore.
e.g. keytool -import -keystore keyStore -storepass changeit -alias MySignedClient -keypass changeit -import -file MyClient.cer
Copy Java KeyStore to your client.
|
|
|
| Back to top |
|
|
| crossland |
| Posted: Fri Mar 05, 2004 3:08 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Thanks for the information. I copied C:\Program Files\IBM\Java14\jre\lib\security\cacerts to c:\stuff and renamed it to trustStore. I then imported the two CA files created previously as follows:
keytool -import -keystore trustStore -file QMGRCA.cer -alias "QMGR CA"
and
keytool -import -keystore trustStore -file hpCA.cer -alias "Client CA"
I then ran my Java client:
C:\stuff>java -Djavax.net.ssl.trustStore=c:\stuff\certs\trustStore MQGetClientSSL
Create a connection to the queue manager
MQJE001: An MQException occurred: Completion Code 2, Reason 2397
MQJE056: Initial negotiation failure
MQJE001: Completion Code 2, Reason 2397
An MQ error occurred : Completion code 2 Reason code 2397 getCause javax.net.ssl
.SSLProtocolException: end of file
The following output was produced in Unix:
AMQ9637: Channel is lacking a certificate.
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel name is '????' (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.
Importing QMGR.cer and client.cer to trustStore didn't result in any difference.
The Java program contains the following:
MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_NULL_MD5";
An identical program that does not specify sslCipherSuite works file. |
|
| Back to top |
|
|
| gunter |
| Posted: Wed Mar 10, 2004 5:40 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
Your problem is the label. Please read "Websphere MQ Security", page 98.
| Quote: |
| Note: These digital certificates have labels. ....On UNIX systems, WebSphere MQ uses the ibmwebspheremq prefix on a label....The prefix is followed by the name of the queue manager .... Ensure that you specify the entire certificate label in lower case. |
I tried it only for channels between queue managers, but I'm sure the problem is the same. It' s only needed to create the repository in the right place and add both certificates. It's easier to use gsk6ikm.
| Code: |
gsk6cmd -keydb -create -db key.kdb -type cms -stash -pw password
gsk6cmd -cert -create -db key.kdb -pw password -label ibmwebspheremqclient -dn 'CN=clientCA,O=ORG,C=UK' -expire 1024
gsk6cmd -cert -create -db key.kdb -pw password -label ibmwebspheremqqmgr -dn 'CN=QMGRCA,O=ORG,C=UK' -expire 1024
|
Maybe I'm partially wrong. I'm sure, I didn't catch the whole thing. I'm still learning.
[/code] |
|
| Back to top |
|
|
| crossland |
| Posted: Thu Mar 11, 2004 2:43 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
The unclear bit is:
| Quote: |
| On UNIX systems, WebSphere MQ uses the ibmwebspheremq prefix on a label to avoid confusion with certificates for other products. The prefix is followed by the name of the queue manager or WebSphere MQ client, folded to lower case. |
For clients, is this saying that the ibmwebspheremq prefix is followed by webspheremqclient ie ibmwebspheremqwebspheremqclient???! |
|
| Back to top |
|
|
| gunter |
| Posted: Thu Mar 11, 2004 6:59 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
For clients, the documentation says:
ibmwebspheremq - default certificate
or
ibmwebspheremq<userid in lower letter>
But it doesn't work in my environment, I don't know what I do wrong. Manager to manager works fine. |
|
| Back to top |
|
|
| crossland |
| Posted: Thu Mar 11, 2004 7:16 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Page 133 of the Security manual states:
| Quote: |
On UNIX systems and on z/OS, the SSL client sends a certificate only if it has either of the following:
* A certificate labelled in the correct WebSphere MQ format:
- For a queue manager on UNIX systems, ibmwebspheremq followed by the name of your queue manager folded to lower case. For example, for QM1, ibmwebspheremqqm1
- For a queue manager on z/OS, ibmWebSphereMQ followed by the name of your queue manager, for example ibmWebSphereMQQM1
- For a WebSphere MQ client on UNIX systems, ibmwebspheremq followed by your logon user ID folded to lower case, for example
ibmwebspheremqmyuserid.
* A default certificate (which might be the ibmwebspheremq or ibmWebSphereMQ certificate).
On Windows systems, the SSL client sends a certificate only if a certificate has been added to the queue manager or WebSphere MQ client certificate store, and then assigned |
As I understand it you use amqmcert for MQ clients. However, I have been told that this is not necessary for Java clients. Does this mean that the label is not relevant for Java clients on Windows? |
|
| Back to top |
|
|
| gunter |
| Posted: Thu Mar 11, 2004 8:01 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
My understanding is, that on UNIX the label assigned a certificate to an application.
On windows, you must assign the certificate to a manager in the Management Tool, for clients you must use
amqmcert -d 123
123 is a handle, that is assigned to the interactive user.
I only read it in the manual, page 122. |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Mar 12, 2004 4:22 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Java clients dont use the MQ windows keystores, they have their own mechanism. The label is not important either (although I am not sure how it is decided which of multiple personal keys are used from the keystore).
Native C clients (including eg. .net applications) do use the MQ keystore so in that case you would need amqmcert to set up a private assigned key. |
|
| Back to top |
|
|
| VivekG |
| Posted: Thu Mar 25, 2004 1:51 pm Post subject: SSl Setup |
|
|
Newbie
Joined: 25 Mar 2004
Posts: 1
|
I am learning the SSL encryption in MQSeries and came across this posting. I went through most of the literature available on this topic but still couldn't succed in getting the MQSeries Server - Client SSL encrypted communication working. As per JasonE's instructions when I try to execute the
gsk6cmd -cert -import -file SignedQmgrCert.12 -type pkcs12 -pw certificate_passw0rd -target key.kdb -target_pw passw0rd
It spits out the error message that the Signer Certificate not in the Key Repository. So, I am guessing there are some missing. Can someone explain?
I used the paper by Vaclav Danhelka and OpenSSL to generate the newcert.p12 certificate. Also used it to generate the ca.cer required in the step
gsk6cmd -cert -add -db key.kdb -label MYCA -file ca.cer -pw passw0rd
Thanks for your help. |
|
| Back to top |
|
|
| techno |
| Posted: Tue Aug 24, 2004 1:40 pm Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
Is this problem solved? If so, how?
Thanks |
|
| Back to top |
|
|
|
|
