Hello Peter,
0. I do not think it became any worse after you got many clients. All every client
needs a certificate of the authority who signed the key of the QM registered as
trusted in its database.
1. This I don't know. I mean to say: it must work, but I am not sure how
cryptographically sound the key exchange will be if PKI keypairs on both ends are
same. Not sure if I have read anything about it and the common sense is not the best
advisor in this particular area.
2. Well, if you are determined to use self-signed certificates, you do not have to
uninstall anything. Assuming QMA has self-signed certificate and private key for 'QMA'
and QMX has a certificate and private key for 'QMX' signed by 'EXTERNALCA' all you
need is to add the certificate for 'EXTERNALCA' to QMA's keystore as trusted and the
certificate of 'QMA' to QMX' store also as trusted. In fact, you may even only need
one of those if the channel does not require peer authentication (in actual SSL
parlance this is 'Client Authentication') -- but I am not 100% sure about that (do not
remember if I tested it with MQ). The only advantage of using some single CA
everywhere is that you would possibly already had it in your QMA store so you wouldn't
have to change it at all.
The only avantage of using EXTERNALCA is that it would probably be so even if QMX
comes from an unknown and untrusted organization who does not wish to share any CA
with you (read: does not trust you or does not want to bother). The disadvantages are
plenty.
3. Well, QM's keystorage can have a lot of private keys, as well. The one that will be
picked up though is the one that has a label
'ibmwebspheremq<your_queue_manager_name_in_lower_case>'
4. The classic way is to have 100 different keys for 100 QMs but sign them with the
same CA and add the only one certificate of this CA (this can be and usually is
self-signed) to the client's keystores. But you can use a single self-signed
certificate and key on all QMs (unless you want it to be used in QM to QM
communication for which see #1 above) and add this certificate to all the client's
databases. Your second approach (to have 100 different keys and add 100 certificates
to each client's storage) is theoretically also possible, but might be difficult
(especially to support).
Hope this will help,
Pavel
"Potkay, Peter M
(PLC, IT)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: Re: SSL, MQClients and
Symmetric keys
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/04/2004 10:08 AM
Please respond to
MQSeries List
Pavel,Neil
When I first started thinking about this, I was only thinking of the one
client group talking to all the QMs, and kinda thought that 1 private self
signed cert for all QMs would be fine. Now that I expand the idea that any
/all of these QMs may now need to SSL with another MQClient group, another
QM from another company, or even each other, I wonder, since a QM can only
have 1 private cert, is this now a bad idea?
1.) Will QMA and QMB be able to SSL each other if they both have the same
keys?
2.) If QMC (my QM) now all of the sudden needs to talk to QMX (outside
company), and QMC is already running the self-signed cert, that's not such a
hot idea. QMC would need a cert signed by an outside CA, and I would then to
uninstall my private self signed cert, install the new private cert from the
outside CA, and then have to export the new public key to any and all
clients/QMs that SSL with QMC. I guess with a little careful planning I can
insure the EdgeQM (QMC) from day 1 has a real cert from an outside CA.
3.) I went through the manuals, and couldn't really find anywhere where it
said a QM can only have 1 private cert. But I guess it makes sense. A QM's
personal private cert is its "signature" of who it is. It can have many of
these in its store, but you can assign one and only one at a particular time
for that QM. Meanwhile the QM's store will contain many CA certs (signer
certs?), to be used in authenticating incoming certs from other QMs and/or
Clients. Is what I laid out in this step all true?
4.) So when this thread started, I was going to give each of the 100 QMs the
same cert, so that each of my MQClients would only need the one same public
key (from the QM side) on their side. What would you guys do in light of the
above points? Same cert for all QMs, or make 100 unique certs for each QM,
and then assign 100 public keys to each MQ client (THAT sames very tedious).
(It is highly unlikley that all my internal QMs will need to SSL each other,
but it is very likley that I will have a second MQClient group coming soon
that will need a separate SSL connection to all the QMs, and I will have 1
dedicated QM that will SSL with outside companies).
-----Original Message-----
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 6:47 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL, MQClients and Symmetric keys
Hello Peter,
1. Yes. And which sometimes is more difficult that it sounds :-). The book I
mentioned has some insights on this subject, too.
2. For example, try this somewhere on any Linux box in a clean directory (or
other *nix if openssl is installed and in the path):
$ openssl req -x509 -newkey rsa:2048 -keyout ca.private.pem -out ca.cert.pem
# answer all questions and remember your passwphrase
# this created self-signed root certificate for ca
$ openssl req -newkey rsa:1024 -keyout qm.private.pem -out qm.request.pem
# answer all questions till "Extra" attributes (just press <Enter> on
those). remember your other passphrase
$ openssl x509 -req -in qm.request.pem -CA ca.cert.pem -CAkey ca.private.pem
-CAcreateserial -days 3660 >qm.cert.pem
$ ls
ca.cert.pem ca.private.pem ca.srl qm.cert.pem qm.private.pem
qm.request.pem
$
Now, you have all certificates you needed for ca and qm. Do same for the
client and you are almost done. You will need gsk6cmd to import certificates
and keys to CMS database though. That's why the suggestion of Neil about
keeping a copy of an empty .kdb database (in CMS format) is worth.
For your last question, I thought you wanted a single key! The answer is
'yes', anyway, with these comments:
a) QMs must have not just public keys, but certificates, signed with the
authority whom client trusts (CA certificate must be in the client's
database)
b) Client's certificate must be sign by the authority that QMs trust
c) you do not use SSLPEER on the channel (i.e. QMs do not authenticate
client). If they do authenticate, Client's common name in certificate must
match SSLPEER for client to get access.
d) I forgot something -- that's for sure.. :-)
Hope this will help,
Pavel
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: Re: SSL,
MQClients and Symmetric keys
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/03/2004 04:55 PM
Please respond to
MQSeries List
Pavel, thanks for taking the time to answer these questions for me.
1.) So the important things is that the MQClient peoples keep their Private
Key private, which is something that all the SSL docs keep pointing out.
2.)OK, so maybe its well documented, but it sure would be nice to have some
examples to follow along with. I learn by doing I guess. I can't even get
started - keeps barking at me about a config file missing, yet nowhere that
I can find is an example of this config file or what needs to be in it. I am
hoping the book will have this. I am trying to set up openssl on a Windows
box. Maybe I should just try and commandline it from my Solaris box.
3.) I will have to get the book you mentioned as well. Actually, Amazon
recommended I get it when I ordered the openssl one!
One last scenario:
Based on the set up laid out in the last email:
What if MQClientA123, B123 and C123 had PrivateKey123 (this MQClient group's
Private Key) and PublicKeyA123 (a second MQQueuemanager Public Key).
QueueManager1, 2, ..., 99 would have PrivateKeyA123 (a second
MQQueueManagerKey Private Key) and PublicKey123 (the second MQClient's
Public Key).
In this case, is it true that either MQClient group could connect to either
SVRCONN channel, even though they both are protected by SSL?!?! (assuming
they both knew the other SVRCONN channel name and what CipherSpec to
specify)
Is the second MQQueueManager key pair even necessary?
-----Original Message-----
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 3:54 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL, MQClients and Symmetric keys
Hello Peter,
1. I would say "yes" for all 3, but with the warning (:-)) that getting
PublicKeyA will be extermely simple for any moderately dedicated attacker
(it is always sent in the certificate by the queue manager at the
non-encrypted stage of SSL handshake (actually, in response to "Client
Hello")).
2. Open SSL (command line) is really well documented. It has a great man and
it is available in nice colors here:
http://www.openssl.org/docs/apps/openssl.html. From there, follow links for
'x509' and 'ca' subcommands. I have nothing against gsk6cmd except that it
is unbearable slow. I have never used that other product (makecert). I am
not sure how to make CMS database with openssl or anything other than
gsk6cmd (I remember there was CMS format for keydatabases of Netscape, while
ago, but I am not sure if it is the same that is used by IBM).
3. I have never read a book for OpenSSL but I suspect it will be mostly
devoted to using the library, not the command line -- although it is just my
guess. To me, 'the book' about SSL is SSL and TLS: Designing and Building
Secure Systems by Eric Rescorla (one of the author of TLS and the Java
implementation of SSL/TLS). It is good in being not really tied to any
particular implementation (and it does not even oversell you SSL itself, it
shows what it is and, most important, what it is not). It does not say
anything of using openSSL command line though (you will have to use the link
before) but discusses the use of OpenSSL API a little bit.
Hope this will help,
Pavel
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: Re: SSL,
MQClients and Symmetric keys
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/03/2004 03:11 PM
Please respond to
MQSeries List
So MQClientA, B and C would have PrivateKey1 (the MQClient Private Key) and
PublicKeyA (the MQQueuemanager Public Key).
QueueManager1, 2, ..., 99 would have PrivateKeyA (the MQQueueManagerKey
Private Key) and PublicKey1 (the MQClient Public Key).
Assume that MQClientA, B and C will be the only machines ever to have
PrivateKey1, as I will hand deliver them and be in total control. And assume
PrivateKeyA will only ever be on the QMs I personally install it on. All
machines in question are internal behind the firewall.
If the above is true:
1.) Self signed certificates will be adequate.
2.) MQClientX, not having BOTH PublicKeyA AND PrivateKey1 will not be able
to connect to any of these QMs over a SVRCONN channel with SSL turned on.
That even if they somehow managed to get PublicKeyA OR PrivateKey1 (but not
both), they would not be able to connect over a SVRCONN channel with SSL
turned on (and SSLClientAuth set to REQUIRED).
3.)To create self signed certs myself, to be my own CA, I have one of 3
methods: openssl, makecert and gsk6cmd. Which is the best, and why? openssl
seems to have a lot of fans based on what I have trolled from the web, but
there's better/more documentation on how to turn bat guano to gold than on
how to use openssl. Same goes for makecert. I ordered the O'Reilly book on
openssl today, hopefully the fact that it is 2 years old wont matter.
Geez, this SSL stuff has put me in my place.
-----Original Message-----
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 02, 2004 5:16 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL, MQClients and Symmetric keys
Hello Peter,
Even if you are only interested in securing SVRCONN channels, you will still
need a secret on every server (a server is always authenticated in SSL). For
clients -- yes, you can use the same private key if distributing it is not a
problem in your setup. But remember that both client and server must have
public and private keys for recovering secrets during SSL handshake. By the
way, I am not sure it is safe to have same keys on both server and client.
In this degenerate case RSA key exchange may become vulnerable for some type
of attack (not that I knew exactly which, but I would do some googling
before using it).
Again, PKI with CAs and whatever is written in the books is a pretty
convenient thing, specially intended to solve key distribution problem. From
my experience, except for one concept there (certificate expiration date) it
does not introduce more troubles than it solves.
IBM's gsk6cmd tool is kind of slow though. I would recommend using openssl
wherever possible and then only import results into CMS databases with
gsk6cmd.
BTW, does anyone know any other (preferably free :-)) tool than gsk6cmd
(iKeycmd) for working with those CMS databases?
Hope this will help,
Pavel
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: Re: SSL,
MQClients and Symmetric keys
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/02/2004 03:55 PM
Please respond to
MQSeries List
Neil, if I make a self-signed certificate, I assume I will get a
Private/Public key pair included, correct?
And if so, could I not put the public key half on all my QMs, and keep the
private key on my desktop. Then configure the SVRCONN channel to use SSL.
Then give the private key to my teammates. So all 6 of us are running the
same private key, all QMs (current and future) have the same public key, and
the only MQClients that can use this SVRCONN channel will be ones that have
this particular private key?
-----Original Message-----
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 01, 2004 6:42 PM
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]|
| | 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
--
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
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 e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
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 e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
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 e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
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
