| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Client and mutual auth within the same Integration Server |
« View previous topic :: View next topic » |
| Author |
Message
|
| mattynorm |
 Posted: Thu Jan 18, 2018 2:04 am Post subject: Client and mutual auth within the same Integration Server |
 |
|
Acolyte
Joined: 06 Jun 2003
Posts: 52
|
Apologies if this has been covered off before, I did a search but couldn't find this exact problem
I have an application, that consists of several flows logically linked. On Flow A I Take in a message via MQ, transform it and send it to a 3rd party using a SOAP Request node. The client requires mutual authentication, so I have imported a .pfx file into my keystore (created using our internal trusted CA), and given the thumbprint to the 3rd party, which they are using to allocate to a user. So far so good
However on Flow B I need to use Client authentication, but it seems that the Integration Server uses the cert created for Flow A by default / as priority, and any attempt to hit the url is met by a ERR_CERT_INVALID issue, and in the details of the invalid cert is the .pfx one we created. On a different server (where the pfx isn't installed but other certs are) , no problem, i.e.
https://otherserver:28202/ - GET method unsupported (expected behaviour)
https://myserver:28202/ - NET_CERT_INVALID
(we use the same Integration Servers and ports for https across estate)
One thing I have noticed is that the keystore and truststore are in the same location - could splitting them out mean the Integration Server could treat client and mutual auth as separate requests, and allocate certs accordingly? I don't really want to split the flows out into different applications and Integration Servers if possible. Also it should be said that for us all http listeners \https connectors are set at the Integration server level |
|
| Back to top |
|
 |
| mattynorm |
| Posted: Thu Jan 18, 2018 2:40 am Post subject: |
|
|
Acolyte
Joined: 06 Jun 2003
Posts: 52
|
| I should add that the version of IIB is 10 fix pack 10 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 18, 2018 5:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
On the request, you need to specify the cert label to be used for the call. This means that you need to have both certs present in the key store...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mattynorm |
| Posted: Thu Jan 18, 2018 8:53 am Post subject: |
|
|
Acolyte
Joined: 06 Jun 2003
Posts: 52
|
We do have the specific cert set on the request, and the request is working fine
The issue is when we are the WS provider, any attempt to connect over HTTPS (e.g hitting the url in the browser) fails with an invalid cert, and the details show that it is the same cert being explicitly set in the WS mutual auth request, which is invalid for client auth
I'm wondering if IB favours heirarchically a mutual auth cert, and if so whether splitting the trust and keystores, and putting (or trying to) the relevant certs in the separate stores may sort this issue |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 19, 2018 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The question here is if you are doing client authentication or not.
If you are doing client authentication you probably need the client cert in your truststore. You also need your broker cert to be valid i.e. have the correct cn for your "website" name. I.e. you url is https://mybroker.mycomp.com/pathtoflow you need the broker cert to have cn=mybroker.mycomp.com ...
Hope this helps
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
