| Author | Message | 
		
		  | jmmcdowell | 
			  
				|  Posted: Wed Nov 07, 2012 2:38 pm Post subject: Strategy Around Using SSL in a Centralized Client Env |   |  | 
		
		  | Newbie
 
 
 Joined: 05 Jan 2009Posts: 6
 
 
 | 
			  
				| Hello All-- We were recently debating strategies internally and I wanted to get some feedback. Thanks ahead of time for reading.
 
 Let’s say we have a centralized queue manager that will be accessed from multiple applications on a variety of hosts, all accessed via client connections.  There is a strong desire to implement SSL on this host, as an authentication mechanism for connecting applications. All certificates are signed by standard CA.
 
 Option 1:  Trust the Signer Cert:  Authenticate instead with the SSLPeer feature of the SVRCONN channels
 • Add the CA signer certificate to the key-ring on the centralized queue manager, strip everything else out of this key-ring.
 • All connecting client applications will present a host-specific cert signed by the same signer cert, and thus be able to handshake with the queue manager.
 • Since we are trusting somewhat generically at the cert level, we will instead rely heavily on the “SSLPEER” filter on the incoming SVRCONN channels.
 • Connecting applications will all be given a unique (per host) SVRCONN channel to connect to, which will have a DN filter specific to the host-based cert that they will presenting.
 • This will ensure that only connections from that host will be allowed to connect to that specific channel.
 • The side effect will be a proliferation of SVRCONN channels on the shared centralized queue manager (and a need to create them whenever a new connecting host is provisioned).
 • The good side of this is that we don’t have to constantly be adding/removing certs from the keyring.
 
 Option 2:  Trust only host specific certs, genericize the SSLPeer feature of the SVRCONN channels to filter on less specific DN qualifiers
 • Do NOT add ANY CA signer certificate to the key-ring on the centralized queue manager
 • Instead, add the host-specific cert for all incoming clients apps into the key-ring on the queue manager.
 • All connecting client applications will present their host-specific cert, and be able to handshake (since their actual cert is in the keyring).
 • Since we are trusting specifically at the cert level, we can genericize the “SSLPEER” filter on the incoming SVRCONN channels.
 • Connecting applications can potentially utilized shared SVRCONN channels (perhaps grouped by app needs), which will have a somewhat generic DN filter that will accept any host provisioned in our environment. (not too generic to allow ANYTHING, but certainly not host specific)
 • The side effect will be a that we are required to constantly be adding/removing certs from the keyring.
 
 Which method is preferred?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Wed Nov 07, 2012 6:58 pm Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| The question is how many qmgrs do you have? 
 If you have only very few qmgrs ... but with many qmgrs the first solution is preferable...
  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | exerk | 
			  
				|  Posted: Thu Nov 08, 2012 1:05 am Post subject: |   |  | 
		
		  |  Jedi Council
 
 
 Joined: 02 Nov 2006Posts: 6339
 
 
 | 
			  
				| My personal preference would be for Option 1 in all cases - it's easier to manage channels than certificates. _________________
 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 |  | 
		
		  |  | 
		
		  | mqjeff | 
			  
				|  Posted: Thu Nov 08, 2012 4:29 am Post subject: |   |  | 
		
		  | Grand Master
 
 
 Joined: 25 Jun 2008Posts: 17447
 
 
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | jmmcdowell | 
			  
				|  Posted: Thu Nov 08, 2012 8:52 am Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 05 Jan 2009Posts: 6
 
 
 | 
			  
				| 
   
	| fjb_saper wrote: |  
	| The question is how many qmgrs do you have? 
 If you have only very few qmgrs ... but with many qmgrs the first solution is preferable...
  |  
 We will probably have dozens of different apps (from different servers) client connecting into just a few (less than 4) queue managers.
 
 The current plan is to load balance between the queue managers using a either client channel table, or perhaps an F5 load balancer...
 
 I am leaning towards the first option as well...
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | jmmcdowell | 
			  
				|  Posted: Thu Nov 08, 2012 8:54 am Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 05 Jan 2009Posts: 6
 
 
 | 
			  
				| 
 I had heard T-Rob mention that this was in development.
 Thank you so much for the link!
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Thu Nov 08, 2012 5:01 pm Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| And remember it's way easier to script your channels than to script with certs...  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |