| Author |
Message
|
| tgow |
 Posted: Thu Dec 02, 2004 10:45 am Post subject: setup SSL sdr/rcvr with 3rd party cert + another cert |
 |
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
Hi.
I am attempting to set up my 2nd SSL channel set for a client of mine, and am having some difficulties getting some answers on certificate questions.
I have one QM (let's call it qm1) running on websphere MQ 5.3 cd07 on a sunOS / solaris 2.8 server.
I currently have one set of SSL channels up and running for clientA. The channels are SVR / RQSTR and all is running ok. I have the cert installed in the personal cert key repository (I used the Java GUI GSK tool) gsk6ikm. I set up the cert to have the label ibmwebsphereqm1. The client can connect, pull and push data with no problems. The current client supplied me with a self signed cert to install since they are actively connecting to my server.
My issue is i'd like to set up another client using SDR/ RCVR on the same QM1. This client (clientB) requires we use a 3rd party cert (entrust) which I have succesfully (after sending a request to entrust) received and installed into the personal cert repository. I have also installed entrust's CA successfully into the signer cert store. I currently have the self signed cert installed as the default. I have the 3rd party entrust cert in the same store as not default labeled as ibmwebsphereclientb.
Is there a way I can get clientB's channel set (sdr/rcvr) to use the non-default cert without disrupting clientA's svr/rqster setup? Perhaps through a channel defn or something? Is each QM limited to one active personal certificate?
I guess it might be possible to force clientA to use the entrust cert, but I'd rather let sleeping dogs lie, so to speak.
I am not able to set up a seperate QM or a seperate server due to cost and license restrictions.
Any thoughts or comments would be greatly appreciated.
Thanks,
-Seth |
|
| Back to top |
|
 |
| tgow |
| Posted: Thu Dec 02, 2004 10:53 am Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| btw, this is an MQ server to server connection |
|
| Back to top |
|
|
| Anirud |
| Posted: Thu Dec 02, 2004 1:21 pm Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
First of all you got the label wrong.
| Quote: |
| I set up the cert to have the label ibmwebsphereqm1 |
It should be ibmwebspheremqqm1
I am not sure how you were able to set-up the communication even though you got the label wrong unless it is a typo in your post.
| Quote: |
| Is each QM limited to one active personal certificate? |
Yes.
| Quote: |
| Is there a way I can get clientB's channel set (sdr/rcvr) to use the non-default cert without disrupting clientA's svr/rqster setup? |
I don't think so. It would be a NO.
| Quote: |
| I am not able to set up a seperate QM or a seperate server due to cost and license restrictions. |
You don't need a seperate QM. You can make this happen with your existing set-up as well, provided you make little changes to your SVR/RQSTR pair.
All you have to do is store the 3rd party certificate in the key database of QM1 and add CA root certificates as Signer Certificates on the RQSTR side of your channel and recycle your channel initiators. It's that simple and you can proceed with your SDR/RCVR channel set-up.
Let us know if you have more questions.
Regards,
Anirud. |
|
| Back to top |
|
|
| tgow |
| Posted: Thu Dec 02, 2004 2:18 pm Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| Quote: |
First of all you got the label wrong.
It should be ibmwebspheremqqm1
I am not sure how you were able to set-up the communication even though you got the label wrong unless it is a typo in your post. |
These are just made up examples of actual objects, in the QM i have it typed correctly. In the post I must have typo'd.
| Quote: |
All you have to do is store the 3rd party certificate in the key database of QM1 and add CA root certificates as Signer Certificates on the RQSTR side of your channel and recycle your channel initiators. It's that simple and you can proceed with your SDR/RCVR channel set-up.
|
I have the 3rd party entrust "personal" cert (which is specifically for the sdr/rcvr pair) stored in the personal cert store. does putting it in the key database mean installing it or putting it somewhere else than where it currently is? I have the CA root cert for Entrust installed in the "signer certificate" "area/store"
I want the SVR/RQSTR for clientA (for which my side is the SVR) to continue to use the self signed cert, if that can be done. Otherwise it means disrupting a "production" set up. If I have to disrupt it, then that's how it goes. I imagine using 3rd party is better anyway.
For some more clarification, the current SVR/RQSTR is like this (for lack of a 'whiteboard'):
SVR(ME)----RQSTR(clientA)
RCVR(ME)----SDR(clientA)
We are totally passive for this client.
The new setup (clientB) is a typical SDR/RCVR install. This is the setup that requires 3rd party cert + 3rd party CA. We use Entrust, and they use Verisign. As long as we both have CAs from the other side's Root Auth. I believe we should be fine (again correct me if I am wrong):
SDR(ME)---(RCVR)clientB
RCVR(ME)---(SDR)clientB
I apologize in advance for my lack of knowledge in SSL/cert terminology. I am quite new to SSL w/ MQ.
Thanks,
-Seth |
|
| Back to top |
|
|
| Anirud |
| Posted: Thu Dec 02, 2004 9:50 pm Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
Did you receive the Personal Certificate into the key database of QM1 (certificate sent by Entrust)?
If Yes, what is the label?
I would say that you will have to disrupt your existing SVR/RQSTR pair because you cannot have a Self Signed Certificate and a 3rd Party Personal Certificate for the same queue manager. On UNIX, label is very important as you cannot assign a certificate to a queue manager. This is how MQ knows who the certificate belongs to and you cannot have two certificates with the same label at the same time.
| Quote: |
| We use Entrust, and they use Verisign. As long as we both have CAs from the other side's Root Auth. I believe we should be fine |
Yes. That's correct. You need to add the CA root certificate(s) of Verisign and your client will have to add the CA root certificate(s) of Entrust. |
|
| Back to top |
|
|
| tgow |
| Posted: Fri Dec 03, 2004 7:57 am Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| Anirud wrote: |
Did you receive the Personal Certificate into the key database of QM1 (certificate sent by Entrust)?
If Yes, what is the label? |
I did receive the personal cert into the kdb. I made up a label originally of something along the lines of 'ibmwebspheremqclientB' not realizing that I was only allowed one personal cert per QM. I did not however make it default, therefore still using the self signed cert as the default cert for QM1.
| Anirud wrote: |
I would say that you will have to disrupt your existing SVR/RQSTR pair because you cannot have a Self Signed Certificate and a 3rd Party Personal Certificate for the same queue manager. On UNIX, label is very important as you cannot assign a certificate to a queue manager. This is how MQ knows who the certificate belongs to and you cannot have two certificates with the same label at the same time. |
I get the same feeling. I will have to get together with clientA and have them use the same cert as I want clientB to use. The only dilemma I can think of is that this move might cause clientA to have the same issue I'm currently having now, but with other partners.
I guess this is a matter of working all this out with several partners so that they all match up (at least on our side).
I appreciate your help, and I will keep this thread up to date with any new findings.
Thank you.
-Seth |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 03, 2004 8:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Just as a point of information, as far as I know there are no licensing restrictions that prevent you from creating more than one queue manager on a machine for which you have sufficient processor licenses.
So you should be able to set up an additional queue manager on the same machine, listening on a different port, and give it the other certificate.
But you may have special circumstances, or the licensing may have changed.
Check with your IBM sales representative to be sure.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tgow |
| Posted: Fri Dec 03, 2004 8:16 am Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| jefflowrey wrote: |
| So you should be able to set up an additional queue manager on the same machine, listening on a different port, and give it the other certificate. |
This is true. I think it's more of a limitation on my backend system that is pulling from the QM than the licenses. The perl scripts + C programs made by our R&D group only have room, unfortunately, to pull from one qmgr. Yes, I know this isn't the greatest design.. but I am forced to work within the design... as per usual. 
Either I get this working as is, or perhaps I'll have to push back to allow for more QMs. Imma do some testing, and see what I can come up with.
Thanks!
-Seth |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 03, 2004 8:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can set up the second queue manager as a gateway.
This won't require changes in your apps.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tgow |
| Posted: Fri Dec 03, 2004 8:34 am Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| jefflowrey wrote: |
You can set up the second queue manager as a gateway.
This won't require changes in your apps. |
Is this something that would accept messages from a client, and then pass them on to the previously existing QM?
Could you point me in the right direction so I can look into the potential details of this idea? Seems like it could be promising. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 03, 2004 8:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Just set up server to server communication between the two queue managers.
On your existing QM, define local queues for the queues that your applications need to GET from and define remote queues for the queues that your clients need to GET from.
On the new QM, define remote queues for the queues that your applications need to get from, and define local queues for the queues that your clients need to GET from.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tgow |
| Posted: Fri Dec 03, 2004 8:52 am Post subject: |
|
|
Novice
Joined: 02 Dec 2004
Posts: 15
Location: Reston, VA
|
| jefflowrey wrote: |
Just set up server to server communication between the two queue managers.
On your existing QM, define local queues for the queues that your applications need to GET from and define remote queues for the queues that your clients need to GET from.
On the new QM, define remote queues for the queues that your applications need to get from, and define local queues for the queues that your clients need to GET from. |
So simple, yet so elegant... and here I thought we were going to be doing something complicated.
So simple I could have thought of it 
I appreciate your patience. |
|
| Back to top |
|
|
|
|
