| Author |
Message
|
| bbburson |
 Posted: Fri May 13, 2005 9:38 am Post subject: SSL certificate requests |
 |
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Please forgive me if this has been asked and answered; I haven't found it if it has.
We will soon start implementing SSL for SVRCONN connections, which means all my queue managers will need certificates. Can I generate all the certificate requests on a single server using gsk6ikm and then import the resulting certificates into the individual key.kdb files for the queue managers? Or do I have to run gsk6ikm on each server to generate the cert request for that server's queue manager?
All the queue managers involved are version 5.3 (*finally*), and run on Sun, HP or AIX.
Any info/pointers/tips will be appreciated. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri May 13, 2005 11:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should be able to create one master keydb with all the certs in it, and then distribute that to each machine.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Anirud |
| Posted: Mon May 16, 2005 6:12 am Post subject: Re: SSL certificate requests |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
| bbburson wrote: |
| Can I generate all the certificate requests on a single server using gsk6ikm and then import the resulting certificates into the individual key.kdb files for the queue managers? |
Yes.
I think this is a good thing to do as we will have a backup of the certificate, just in case. I know we can get a new certificate without any additional charges from the CA, but, that's time consuming. |
|
| Back to top |
|
|
| bbburson |
| Posted: Mon May 16, 2005 8:04 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Thanks for the info. We should be setting up our ssl stuff soon, and this will be a big help to me. |
|
| Back to top |
|
|
| pbmsmit |
| Posted: Mon May 16, 2005 12:18 pm Post subject: |
|
|
Apprentice
Joined: 11 Jul 2003
Posts: 42
Location: Chicago
|
If you use this procedure, you have to ship the private key in the export file and protect that file with a password. Our Auditors do not like that because of the weakness of the password protection. Our rule is that we use the keydb on the same machine as the MQserver (and of course the keydb must be protected for authorized users only) to prevent shipping of the private key.
It might also be more difficult  to generate multiple requestfiles for different qmanagers at the same time and import the CA signed certificates.
_________________
Peter Smit
LaSalle Bank Corporation, member of ABN AMRO NV Group |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 16, 2005 12:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You certainly have to ship the private key - for values of "ship" that mean "transfer across the internal network, once".
The rest of your claims I'm a little less clear on. He's talking about replacing the keydb on each machine with a common keydb.
The one problem with this is that any machine can be breached to give access to all machines private keys.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Tue May 31, 2005 1:45 pm Post subject: Updates to my knowledge |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
First of all, thanks for the responses to my initial question. Sorry I haven't had time to reply yet; there's this lake with these alligators. . . 
Anyway, I've learned a few things from trial and error that I thought I'd pass along. Plus I can clarify our requirements a bit.
-- We already have a key.kdb file in place for each queue manager; it is initially installed with no personal certificates, just the few signer certificates we need in our environment. So the suggestion to build one master key.kdb and ship it around is interesting but a bit beside the point.
-- I created a script of gsk6cmd's to build cert requests in a single database on one of our machines. So far so good.
-- There was some confusion and disagreement about what our Organization string should be, so I re-ran my script to generate new cert requests. NOT a good idea; I got new cert request FILES, but the cert request entries in the database were not updated. When I got my first certificate back I was not able to "receive" it into the database.
-- Fortunately I only requested one cert at first so when the problem above became apparent, I completely blew away the database and all the cert request files and started fresh with the correct O= value in the new requests. I got our cert administrator to cancel the one cert I had received and I re-submitted the request to the CA. This time I can "receive" it into the database with no problem.
-- Now what I'm going to end up with is all my certs in one master database, and I need to get the individual certs moved around to the queue manager databases. I found out from trying that I *cannot* use gsk6cmd -receive command to bring in the cert I received from the CA. Note that this was the intent of my original question: could I *request* from one database and *receive* into another. Sigh... So instead I will have to use gsk6cmd -export to create .p12 files that will then be distributed to the queue manager machines and imported there into the key.kdb for each queue manager.
Thanks again for the help and tips here. I hope the info I've given above can be helpful to someone else in a similar situation. |
|
| Back to top |
|
|
|
|
