Hi Neil, Sorry but the bit I dont get is how do the other hosts communicate with the CA machine to get their signatures?
Regards Tim A -----Original Message----- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 June 2004 12:49 PM To: [EMAIL PROTECTED] Subject: Re: SSL, MQClients and Symmetric keys Hi, if you have a network card, then someone might plug a network cable into it. A CA machine is a critical security resource, and should be held a securely as possible. If it is on the network, then it is potentially vulnerable to a network based attack. If there is no network card, then there can be no network connection, and you can make your CA secure by using physical security controls, which are much more reliable than software ones. Regards, Neil Casey National Australia Bank Southern Star Technology WebSphere MQ Support 1/122 Lewis Rd Wantirna South office. +61 3 9886 2375 (x82375) mobile. +61 414 615 334 |---------+--------------------------------> | | Mike Dickinson | | | <[EMAIL PROTECTED]| | | NET.COM.AU> | | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | .AT> | | | | | | | | | 02/06/2004 12:11 | | | Please respond to | | | MQSeries List | |---------+--------------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: SSL, MQClients and Symmetric keys | >--------------------------------------------------------------------------- ---------------------------------------------------| Many thanks for this Neil. I am just confused about the instruction to not install a network card. What is the effect of having a card installed? I can't find any reference in the openSSL doco about this issue. Regards Mike Dickinson -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Neil Casey Sent: Wednesday, 2 June 2004 08:42 To: [EMAIL PROTECTED] Subject: Re: SSL, MQClients and Symmetric keys Hi Peter, I've been busy with SSL for the last few weeks as well, and this is my take on your issue. 1. SSL does use symetric keys for encryption. It generates them at session startup, and exchanges them, protected by encryption with the private/public key pair. This gets around the symetric key delivery problem. 2. While self signed certs could be used in your environment, they would be very painful. Every cert needs to be installed in every key store, especially if you want to use sslcauth(required). 3. This is where a CA helps. You generate your certificate signing requests on each host, and get the CA to sign the request. The certificate is then received into the key store for its queue manager (or client) and the public key of the CA is added as a trusted CA cert. The queue managers will then trust any cert signed by this CA where the DN matches the SSLPEER value. 4. You don't need to go out to an external CA like Thawte or Verisign and pay for certs. You can set up a private CA, which can be as simple as installing the OpenSSL (or is it OpenSSH?) package on a linux machine (don't install a network card). Then you can use the commands directly, or set up some scripts to make the syntax easier. 5. If you do it this way, then each key repository only needs to have the personal cert belonging to the queue manager or client, and the CA cert for the signer. You can add new queue managers and clients without having to touch any of the existing key repositories. If you used self signed certs, you would need to cross copy the new cert into every other key repository. 6. Be careful about the default CA certs which are installed into the repository when you create it. I always delete all of these CA certs because I don't plan to use certs signed by them. I can always add them back if I need to later. In your note, you say you want to use the same cert or key on all of your clients/servers. If you build an internal CA, put that into your repository and use it to sign all the certs, then that is in effect what you get. Only the CA cert is in the repository, but you get the trust you want, and you don't have to cross register all the different self-signed certificates. In theory, I think you could also generate one private/public key pair (self signed certificate) and export it. Then import it into the other queue managers/clients with different labels in each location. This would not be a nice thing to do, and really wouldn't help your security much. It means that you have to move your private keys around, and they are stored in multiple places, which is not goodness. Going with an internal signer works very nicely. When you get to using SSL with 3rd parties, you will need to explore external CAs, because both you and the other party need to have certificates signed by someone that you both trust. This will present a problem, as any queue manager can only present one certificate. It can't present different certificates to different channel partners. This means that when you have queue managers with certs signed by an external CA, you will need to have that CAs signer cert in the key repository of your local admin clients. Regards, Neil Casey National Australia Bank Southern Star Technology WebSphere MQ Support 1/122 Lewis Rd Wantirna South office. +61 3 9886 2375 (x82375) mobile. +61 414 615 334 |---------+------------------------------> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM> | | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 02/06/2004 06:29 | | | Please respond to | | | MQSeries List | |---------+------------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: SSL, MQClients and Symmetric keys | >--------------------------------------------------------------------------- ---------------------------------------------------| As my first attempt at SSL, I want to implement SSL on MO71, so that only my 6 teammates and myself can connect to all our QMs over the dedicated SVRCONN channel I have set up for MO71. So basically I want to implement SSL for a client application that might connect to any one of a 100 QMs (Windows / Solaris / HP-UX / z/OS), and only 6 Windows desktops will ever run this client app. I need your opinions if this design is valid. Having read a ton of stuff on SSL over the past 2 weeks, and getting an SSL tutorial completed where I have 2 QMs running with SSL on the channels between them, I am still nowhere near comfortable with this SSL stuff. (Was it Albert Einstein that said "If you can't explain something so your grandmother understands it, YOU don't understand it." Right now, Grams has no clue what I'm babbling about!) The biggest problem for me is the whole concept of getting certificates. Since the certificates for the QMs and the clients will be personally installed by me on all machines, and all the machines are internal, I don't really need to go to a CA to get certificates do I? A self signed certificate will work just fine, no? And taking it a step further, couldn't I just avoid certificates completely and just use a symmetric key? How do I get a symmetric key? Seems the only certificates I see (self signed or not) are for Public / Private key pairs. I am thinking "Wouldn't it be easy to create a symmetric key called XYZ, install XYZ on all the servers and the 6 desktops, and tell the QM or the client to use that symmetric key?" Or do I have to create a certificate, assign it to the QM, and give the public part of it to the clients (our desktops running MO71)? I want a solution where I can use the same key (or certificate) on all my QMs and MQ clients connecting to those QMs. And as I add more QMs in the future, I can just add this same key (or certificate) to them. I'll tackle SSL with outside un-trusted parties after I get this down (and the need arises.) Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material.
