| 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 2009
Posts: 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 2003
Posts: 20756
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 2006
Posts: 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 2008
Posts: 17447
|
|
| Back to top |
|
|
| jmmcdowell |
| Posted: Thu Nov 08, 2012 8:52 am Post subject: |
|
|
Newbie
Joined: 05 Jan 2009
Posts: 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 2009
Posts: 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 2003
Posts: 20756
Location: LI,NY
|
And remember it's way easier to script your channels than to script with certs...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
