| Author |
Message
|
| kordi |
 Posted: Thu Oct 29, 2015 6:50 am Post subject: The same kdb form multiple mq client installations |
 |
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Hi,
Providing I have tool which operates on 30 hosts under the same username everywhere connecting the same QMGR. Is it right to use the same kdb for all of these mq clients on these 30 hosts? |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Oct 29, 2015 7:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
My feeling is no as irrespective of the fact of compromise, should the key store be corrupted in any way, or deleted 'accidentally', then all clients stop working.
Watch this space for other's ideas...
_________________
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 |
|
|
| kordi |
| Posted: Thu Oct 29, 2015 7:53 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
In fact, I would have 30 copies of the key database. If one would get damaged, I could use one of remaining 29 copies located on different 29 servers  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 29, 2015 8:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kordi wrote: |
| In fact, I would have 30 copies of the key database. If one would get damaged, I could use one of remaining 29 copies located on different 29 servers |
I hope you've got a really good SSL management system for when the certificates expire.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 29, 2015 8:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Each client / user should have it's own Keystore/truststore.
Each app should have its own channel.
You only need the signer cert chain on the qmgr. If this is internal have them all signed by the internal CA (no cost). 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kordi |
| Posted: Fri Oct 30, 2015 12:04 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Gentelmen, I think I have been misunderstood.
Each mq client would have its own kdb obviously. I am not talking about shared key.kdb.
What I am not sure about is if I can use the same certificate for many mq clients if those clients are operating using the same user id?
So I would copy key.kdb to temp folder, delete old certificate with label ibmwebspheremq<userID>, create signing request for ibmwebspheremq<userID> with the same DN as old one, sent to sign, receive newly signed certificate and add CA certs. After that I would replace all 30 kdb stores with this new one having new certificate for userID.
I guess it should work assuming all clients are using the same userID but maybe there is something which I don't know and would cause problems. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 30, 2015 1:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kordi wrote: |
Gentelmen, I think I have been misunderstood.
Each mq client would have its own kdb obviously. I am not talking about shared key.kdb... |
Whether it's one key store file or thirty copies of the same key store, it's not a good idea. What happens if the certificate is revoked?
_________________
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 |
|
|
| kordi |
| Posted: Fri Oct 30, 2015 1:22 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
| Yes, this is possible threat which may impact all client connections however we are using internal CA, so I think that will not happen. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 30, 2015 1:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kordi wrote: |
| Yes, this is possible threat which may impact all client connections however we are using internal CA, so I think that will not happen. |
So the internal CA doesn't revoke any 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 |
|
|
| kordi |
| Posted: Fri Oct 30, 2015 2:01 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
| Does not have any reason to do that. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 30, 2015 4:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kordi wrote: |
| Does not have any reason to do that. |
So there's no chance at all that a security breach (someone being phished) will result in a certificate being stolen? Or a certificate being fraudulently obtained in some other way?
I admire your security standards and staff training procedures. That's a proud statement you're making.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kordi |
| Posted: Fri Oct 30, 2015 5:30 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
| All of the connections are within internal network, to all servers limited staff have access. Of course we can assume that certificate can be stolen but in the same way we may assume Queue Managers can be deleted, servers wiped out, data base droped etc. We have to trust administrators having access to certain resources that they won't do any harm to the system they maintain. Otherwise administrators work would be impossible. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 30, 2015 6:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kordi wrote: |
| We have to trust administrators having access to certain resources that they won't do any harm to the system they maintain. Otherwise administrators work would be impossible. |
So you trust administrators not to do any harm, including accidentally? So you don't take backups because you trust the administrators not to delete queue managers or dismount servers?
Of course you take backups because sometimes accidents happen and you use backups as a remediation. In the same way an administrator can accidently click on a link they shouldn't and bang goes your security. The remediation is revocation.
I repeat my comments about cert management. Even if you do never revoke a certificate, sooner or later they'll expire.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kordi |
| Posted: Wed Nov 04, 2015 6:21 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Of course we do make backups because problem may be caused not only by us but also by hardware failure or SA's mistake.
Maybe my knowledge is limited but can you please describe me a scenario which may force us to revoke certificate issued for internal purpose, inside intranet network? I would appreciate it. I am just curious how likely this situation is.
Yes, all certificates have expatriation date, regardless if you are using the same on hundreds of servers or hundreds on the same server. This have to be maintain anyway. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 04, 2015 6:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kordi wrote: |
| can you please describe me a scenario which may force us to revoke certificate issued for internal purpose, inside intranet network? |
One of the administrators falls victim to a phising or spear phising email, granting an attacker access to the internal certificates and hence the ability to impersonate or otherwise access your network.
Other attack vectors are of course possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
