| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Setup for 2-way SSL for WMB WebService |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Thu Sep 18, 2014 5:16 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| zpat wrote: |
| We're using our own in-house CA, so the one signer cert should be enough. |
Don't trust should for 2 Way SSL. It should be enough for one way SSL.
For 2 way SSL any internal server with a cert signed by the internal CA could communicate. This is not enough for 2 way SSL. You need the partner's public key in your truststore... (unless you are MQ and can check SSLPEER) 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 18, 2014 5:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
For 2-way SSL, both sides need the other side's full cert chain in the trust store.
For IIB/Broker, the truststore can and usually is separate from the keystore.
So you need to export/extract/whatever the broker's cert from the keystore and put it in the other side's truststore.
Likewise you need to get the cert from the other side and put it in the broker's truststore.
Having only one cert in the keystore doesn't work - unless you've made efforts to make the keystore and truststore the same file. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 18, 2014 5:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Our keystore and truststore are the same JKS.
The problem is that the F5 can't verify the certificate being sent from the broker.
When they disable authentication in the F5 it works fine.
So the question is - what cert is the broker sending (hence my other question about client authentication key alias)?
As far as I can see - our in-house CA is a root CA. There is only one entry in the certification path.
I've tried exporting the brokers cert and putting it in the F5 - still no dice.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 18, 2014 5:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If broker is *making* the request, and you don't specify the key alias (per your other question), then Broker should present the first certificate it finds in the keystore.
As you say, this should be the only one there is.
The F5 shouldn't require the actual broker's cert. It should only require the CA, and be configured to trust all keys signed by that CA.
It's possible that the F5 is failing the cert for reasons other than the signer chain - it could think it's expired, it could think it's the wrong type of cert, it could require FIPS or etc that don't match the cert, it could require ciperspecs that Broker isn't using...
Do you have the validation error from F5?
I have never trusted F5s |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 18, 2014 6:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Thanks, I'll try to get more details of the F5 failure.
They've coded a key alias name now (as per the cert label).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 23, 2014 7:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
The cause of the problem was our CA signed certificate does not have the extended key attribute set to allow it to be used both as a server auth cert, and as a client auth cert.
However it worked with a self-signed cert (which doesn't seem to have these key attributes).
Incidentally IBM told me how to run a Java trace which does produce a nice display of the SSL handshake (in the EG JVM stdout file). Just set this for your broker id.
export IBM_JAVA_OPTIONS=-Djavax.net.debug=true
and restart your broker.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
