| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How risky are self-signed certificates? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jsware |
 Posted: Thu Jun 05, 2008 6:14 am Post subject: How risky are self-signed certificates? |
 |
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I have been playing around with SSL to enable an MQClient application to connect via a secured SVRCONN channel to a queue manager. I am using this as a mechanism to authenticate a client to ensure that it is who it claims to be. The svrconn channel has the mcauser set to a restricted user only allowing them access to the relevant application queues.
I have been using self-signed certificates for my own testing and everything is working great. I create a qmgr certificate on the qmgr server and also client certificate on the MQClient machine, extract and exchange the certificates between the client/qmgr key.kdb repositories.
All of this works fine and also fails when I expect. If I try to use the client certificate from a different user ID, the connection fails (as I would expect). If I try to create another client certificate that matches the other user ID, and has not been added to the qmgr key.kdb file, a connection fails (as I would expect).
I would not intend to use self-signed certificates for connects between 3rd parties, business parties etc. This is for my applications accessing my qmgrs only.
My question is what problems could I encounter using self-signed certificates for internal authentication? I did a search on mqseries.net but couldn't find anything relating to how (un)risky they are.
I can only think of one and that is that the client's key.kdb needs to be protected from theft otherwise somebody take that key.kdb file, create a local user id with the same name and then connect as that user. But somebody with a certificate signed by a root CA could have the key.kdb file stolen too so it doesn't look any worse. Protecting client key store files is documented in the mq security manual.
I also noted that Java clients don't use the kdb ssl repository format and a key.sth password stash file. They use the JKS key database type and you have to specify the password as a
-Djavax.net.ssl.keyStorePassword=mypassword or leave it as the default password of "changit" 
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
 |
| sami.stormrage |
| Posted: Fri Aug 01, 2008 12:42 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Low-level encryption, 40 or 56 bits, is acceptable for sites with low-value information. High-level encryption, at 128 bits, can calculate 288 times as many combinations as 40-bit encryption. That’s over a trillion times a trillion times stronger.
A hacker would not have so much of resources to crack a Verisign signed certificate. So, if u use a self singed one there isnt a problem until someone hacks ur network.
_________________
*forgetting everything * |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 01, 2008 1:46 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If you have a lot of 'internal' infrastructure, ensuring all certificates have been added to all relevant keyrings could become something of a management and maintenance nightmare, especially when a certificate comes up for renewal.
Also, if you use self signed and someone generates a self signed certificate and can get it into a keyring (paranoia rules!) then you have a problem that you may not become aware of.
Have you thought about an 'internal' CA as an option? The initial work would involve certificate requests and CA certificate distribution, but would eventually manage down to a trickle flow of maintenance.
_________________
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 |
|
|
| zhanghz |
| Posted: Sun Aug 03, 2008 7:56 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| I feel that scott's concern is not much related to ssl, but change management process and internal control kind of thing. If someone who is not supposed to get your source code or run sciprts managed to get them, really nothing technical can help here. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
