Author |
Message
|
Tibor |
Posted: Wed Oct 11, 2006 6:14 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
tudsz dobni mélt vagy szkájpon a tntkukac fedőnevű usert keressed
Last edited by Tibor on Thu Oct 12, 2006 12:42 am; edited 1 time in total |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Oct 11, 2006 8:39 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Tibor wrote: |
tudsz dobni mélt vagy szkájpon a tntkukac fedõnevû usert keressed |
What? _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
Tibor |
Posted: Thu Oct 12, 2006 12:20 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
Roger,
It was only a post in hungarian because the previous post seems to me a fellow countryman. I have to say sorry  |
|
Back to top |
|
 |
Tibor |
Posted: Thu Oct 12, 2006 12:42 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
simi wrote: |
...
HashMap h1 = new HashMap();
h1.put("javax.net.ssl.trustStore","D:/MQSSL/kliens.jks");
h1.put("javax.net.ssl.trustStorePassword", "kliens");
h1.put("javax.net.ssl.keyStore", "D:/MQSSL/kliens.jks");
h1.put("javax.net.ssl.keyStorePassword", "kliens");
Collection c = h1.entrySet();
MQEnvironment.sslCertStores = c ;
|
The MQEnvironment.sslCertStores is a list of CRLs as well as the manual writes here, that's why the JSSE provider need the settings of system properties. |
|
Back to top |
|
 |
guy4286 |
Posted: Mon Nov 06, 2006 4:55 pm Post subject: |
|
|
Newbie
Joined: 06 Nov 2006 Posts: 3
|
Wow, this is a great thread. I'd like to extend it a bit.
I'm having trouble understanding something somewhat higher-level about MQ SSL setup, and I'm hoping I can get the clarification I'm looking for here. I've been reading tons of MQ documentation, but there doesn't seem to be a definitive explanation containing the information I'm looking for.
In all MQ SSL setup, there doesn't seem to be any clarification between setup for client-side SSL, or server-side (MQ-side) SSL, or both. Client-side SSL meaning that MQ authenticates the client with the client's public cert. MQ-side SSL meaning that the client authenticates (verifies) the Queue manager it is talking to.
Let's assume (for now) that I'm only interested in MQ-side SSL (having the client verify the MQ-server with the MQ-server's public key)
Typically, MQ-side SSL means the server (MQ) needs a private key, and the client needs a public key to decide whether or not to trust the server. The QueueManager in MQ Explorer has a field to specify a Key repository. I would assume this is where to point the MQ server to a keystore containing a private key with which to prove itself to other clients. I'm concerned that I'm misunderstanding things however, because how does the MQ server know the keystore password in order to use the private key?
Secondly, why do I need to specify a keystore on the client side using the referenced (in previous posts) System properties? I would think that as long as the client's JSSE knows where to find the trust-store, and the trust-store has the public key that should be used to verify the MQ-server, then only a trust-store is required. Is this wrong?
I don't feel like I have a high-level understanding of what is needed to setup the MQ SSL connection if I am only doing server-side SSL. I'll need to eventually setup client-side SSL as well, but once I have this higher-level understanding I'm sure I'll be o.k.
Hopefully somebody can set me straight.
Thanks
-guy |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Nov 06, 2006 6:04 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Consider Alice and Bob.
Alice has a private key and a public key. She also has Bob's public key.
Bob has a private key and a public key. He also has Alice's public key.
Alice opens a connection to Bob. Bob sends her a piece of data. He has encrypted it with Alice's public key, and signed it with his private key.
Alice verifies that the message came from Bob by decrypting the signature with Bob's public key. She verifies the message data by decrypting it with her private key.
Alice then sends Bob a piece of data, using the same method. Once Bob is able to decrypt and verify the message, then they both know that Eve is not involved.
Now who's the server and who's the client? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
guy4286 |
Posted: Mon Nov 06, 2006 6:18 pm Post subject: |
|
|
Newbie
Joined: 06 Nov 2006 Posts: 3
|
Assume that we arbitrarily state that Alice is the client and Bob is the server.
With Server-side SSL I'm defining that Alice can never use her private key. only Bob can use his private key, and alice has Bob's public key to decrypt the signature made by Bob.
Anyway, I can't tell if you were kidding or not, but just wanted to clarify that this didn't help much.  |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Nov 07, 2006 4:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I'm not entirely sure that MQ SSL provisions will let you configure Alice without a private key.
The MO04 Support Pack is a very handy tool for playing around with this stuff. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
guy4286 |
Posted: Tue Nov 07, 2006 2:58 pm Post subject: |
|
|
Newbie
Joined: 06 Nov 2006 Posts: 3
|
Still looking into this... I've made some progress, but now I'm really stuck.
The queue manager seems to be unable to use the keystore I've specified in the queue manager properties. I get the following errors depending on how I name the keystore repository.
Quote: |
11/7/2006 14:37:48 - Process(10680.6) User(MUSR_MQADMIN) Program(amqrmppa.exe)
AMQ9647: I/O error on SSL key repository.
EXPLANATION:
An I/O error was encountered when attempting to read the SSL key repository.
The channel is '????'; in some cases its name cannot be determined and so is
shown as '????'. The channel did not start.
ACTION:
Analyse why there is a I/O problem when reading the key repository. Fix the
error if one is found, or it may be a temporary problem. Restart the channel.
----- amqrssqa.c : 1044 -------------------------------------------------------
11/7/2006 14:37:48 - Process(10680.6) User(MUSR_MQADMIN) Program(amqrmppa.exe)
AMQ9647: I/O error on SSL key repository.
EXPLANATION:
An I/O error was encountered when attempting to read the SSL key repository.
The channel is '????'; in some cases its name cannot be determined and so is
shown as '????'. The channel did not start.
ACTION:
Analyse why there is a I/O problem when reading the key repository. Fix the
error if one is found, or it may be a temporary problem. Restart the channel.
----- amqccisa.c : 1213 -------------------------------------------------------
11/7/2006 14:37:48 - Process(10680.6) User(MUSR_MQADMIN) Program(amqrmppa.exe)
AMQ9492: The TCP/IP responder program encountered an error.
EXPLANATION:
The responder program was started but detected an error.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 459 --------------------------------------------------------
|
I get this when the keystore repository file is just "keystore".
If I name the keystore repository keystore.kdb, I get this:
Quote: |
11/7/2006 14:19:37 - Process(10680.5) User(MUSR_MQADMIN) Program(amqrmppa.exe)
AMQ9660: SSL key repository: password stash file absent or unusable.
EXPLANATION:
The SSL key repository cannot be used because MQ cannot obtain a password to
access it. Reasons giving rise to this error include:
(a) the key database file and password stash file are not present in the
location configured for the key repository,
(b) the key database file exists in the correct place but that no password
stash file has been created for it,
(c) the files are present in the correct place but the userid under which MQ is
running does not have permission to read them,
(d) one or both of the files are corrupt.
The channel is '????'; in some cases its name cannot be determined and so is
shown as '????'. The channel did not start.
ACTION:
Ensure that the key repository variable is set to where the key database file
is. Ensure that a password stash file has been associated with the key database
file in the same directory, and that the userid under which MQ is running has
read access to both files. If both are already present and readable in the
correct place, delete and recreate them. Restart the channel.
----- amqccisa.c : 1213 -------------------------------------------------------
11/7/2006 14:19:37 - Process(10680.5) User(MUSR_MQADMIN) Program(amqrmppa.exe)
AMQ9492: The TCP/IP responder program encountered an error.
EXPLANATION:
The responder program was started but detected an error.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 459 --------------------------------------------------------
|
Does anybody have any idea what's going on here? Note that in the same directory where I have my keystore repository, I also have the password stash file (.sth) |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Nov 07, 2006 3:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The MO04 Support Pack (that's Emm-Oh-Zero-Four) is a very handy tool for playing with this kind of stuff. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
tony4ever |
Posted: Mon Feb 12, 2007 12:15 am Post subject: |
|
|
Newbie
Joined: 19 Dec 2006 Posts: 7
|
Tibor wrote: |
mqmike,
Steps:
(1) creating a JKS keystore
- if you have a PKCS12 certfile you can use the GSKit when creating keystore:
Code: |
gsk6cmd -keydb -create -db key.jks -type jks -pw mq123
gsk6cmd -cert -import -file test.p12 -type pkcs12 -pw test123 -target key.jks -target_type jks -target_pw mq123 |
- or any other like keytool, etc
(2) handling of keystore and truststore is depending on your JSSE provider. In the simplest way these are runtime properties:
java -Djavax.net.ssl.keyStore=key.jks -Djavax.net.ssl.keyStorePassword=mQ1234 -Djavax.net.ssl.trustStore=key.jks -Djavax.net.ssl.trustStorePassword=mQ1234 ...
But in this case your stores' password are visible in the process list My recommendation: place it into the source or a config file:
Code: |
System.setProperty( "javax.net.ssl.keyStore", "key.jks");
System.setProperty( "javax.net.ssl.keyStorePassword", "mq123" );
System.setProperty( "javax.net.ssl.trustStore", "key.jks");
System.setProperty( "javax.net.ssl.trustStorePassword", "mq123"); |
(3) selecting a cipher:
Code: |
MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_RC4_128_MD5";
|
The full list of cipherspecs is in the "MQ for Java" manual.
HTH,
Tibor |
Hi, guys
If the keys are generated from Unix, can I copy the keys to Windows directly? many thanks! _________________ Tony
____________
SAP HSBC |
|
Back to top |
|
 |
|