| Author |
Message
|
| J.D |
 Posted: Tue May 11, 2010 9:48 am Post subject: Encryption of data using SSL |
 |
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
Hi Folks,
My Client is planning to secure the server connection channel using SSL between 5000+ MQ Cleints 6.x and 10 MQ Servers 6.x. Client application using C++. I know what to do on Server side but need some suggestions for setup on client side. Do they have to use Client Channel table or any other method? All the 10 Queue Managers are in single Cluster.
Thank You!! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 11, 2010 9:50 am Post subject: Re: Encryption of data using SSL |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| J.D wrote: |
| Do they have to use Client Channel table |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Tue May 11, 2010 11:41 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
I don't think they have to use CCDTs. It is definitely recommended that they use CCDTs in this case.
p.s: 5000 clients is a lot! Have you considered which tools to use for certificate management ? There is nothing out-of-the-box from MQ for this. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 11, 2010 11:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sridhsri wrote: |
| I don't think they have to use CCDTs |
What other client connection method supports the use of SSL?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Tue May 11, 2010 12:03 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| I thought it could be done with MQCONNX - maybe I got it wrong. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 11, 2010 12:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sridhsri wrote: |
| I thought it could be done with MQCONNX - maybe I got it wrong. |
No, you might be right at that.
I've never had much time for MQCONNX; too much infrastructure in the application for my taste.
But at least we can agree CCDT is the recommended course of action. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| J.D |
| Posted: Tue May 11, 2010 12:21 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
My Client has been using 5000+ clients across the country to send live transactions to MQ Queue Managers from the past 10 years. We never had a performance issue. We are going to have one-way authentication not the mutual one. So, the Client will need to manage only trust certificate.
All the MQ Clients and Servers are on Windows. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Tue May 11, 2010 12:49 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| You'll still have to deal with 5010 kdbs. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Wed May 12, 2010 12:02 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| Vitor wrote: |
| sridhsri wrote: |
| I thought it could be done with MQCONNX - maybe I got it wrong. |
No, you might be right at that. |
He is right.
| Vitor wrote: |
| I've never had much time for MQCONNX; too much infrastructure in the application for my taste. |
Interesting point this. In some ways I agree about there being too much knowledge of infrastructure in the application code but on the other hand you don't have to worry about managing the 5000 channel tab files.
Anyone else got any views on this?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 12, 2010 12:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
5000 clients to 10 servers - no real problem as I see it if you are not using discrete channel names for each client, e.g. blank or wild-carded queue manager name. Even I would consider allowing the use of MQCONNX if every client had to have it's own channel (x10 if 'fail-over' was needed).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 12:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Put the CCDT on a shared LAN drive and point the AMQCHLLIB environment variable to it, do not copy it 5000 times! |
|
| Back to top |
|
|
| fatherjack |
| Posted: Wed May 12, 2010 12:53 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| zpat wrote: |
| Put the CCDT on a shared LAN drive |
Assuming all the clients are on that LAN.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 1:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Even 10 different LAN copies is better than 5000 copies.
If the PCs are isolated (e.g. branches) then automate some regular replication from a central source using your company's software distribution technology. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 12, 2010 1:14 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I wasn't advocating 5000 copies! If all clients do the same thing, then yes, a concurrently accessible central location is desirable; if the clients are grouped by function, then still centralise (it's only the 'local' MQCHLTAB variable that may change). The question is, would you also have one centralised key store for all those client?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Wed May 12, 2010 1:25 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| exerk wrote: |
| Even I would consider allowing the use of MQCONNX if every client had to have it's own channel |
So I guess you're in Vitor's camp on this one.
Interesting though that almost all application vendors whose products use MQ that I've come across use MQCONNX. I wonder what their thinking is.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
|
|
