Author |
Message
|
PeterPotkay |
Posted: Tue Nov 19, 2013 1:44 pm Post subject: SSL for Executon Group HTTPSConnector or ComIbmJVMManager |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
mqjeff |
Posted: Wed Nov 20, 2013 3:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I'd guess that the file locations and passwords can be set using either component, and they both change the same thing...
but that's just a guess.
If that's not true, then my tendency would be to use the HTTPSConnector for everything.
But I'd still open a PMR and clarify.
On second consideration, it might be for the case where you need to have a different keystore/truststore for HTTP SSL than you have for other SSL. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 20, 2013 6:35 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Setting the cert store location, password, etc for one doesn't reflect in the other's mqsireport output, so it seems this allows you to use different certificate details in different scenarios. Unclear yet on why you might want to set these to different values.
I opened a PMR. Will let y'all know what I find out. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Nov 20, 2013 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
you receive TCP/IP messages from internal networks using a private CA, and you want to ensure that you only accept connections that are trusted by that private CA.
You receive HTTP from a more customer-facing side and need to accept connections that are trusted by more public CAs.
Different keystores/truststores let you keep that separate. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 20, 2013 6:45 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
mqjeff wrote: |
you receive TCP/IP messages from internal networks using a private CA, and you want to ensure that you only accept connections that are trusted by that private CA.
You receive HTTP from a more customer-facing side and need to accept connections that are trusted by more public CAs.
Different keystores/truststores let you keep that separate. |
Exactly what I was thinking earlier this week. With the lack of SSLPEER like functionality in WMB I wish I was able to have a front side truststore with very limited trust (i.e. only have my private CA certs in there) and a backside trust store for when the execution group was acting the role of the SSL Client, and so it would be easiest to have all the public CAs in THAT trust store.
However, the problem would remain on how you would tell Message Flow A in Execution Group1 to use Trust Store A and tell Message Flow B in Execution Group 1 to use Trust Store B.
I am hoping that the PMR comes back with something obvious that explains:
When do we set the cert store details for HTTPSConnector.
When do we instead set it for ComIbmJVMManager.
Why is clientAuth and explicitlySetPortNumber only available for HTTPSConnector. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
ghoshly |
Posted: Sun Mar 22, 2015 8:24 am Post subject: Could you please share the outcome of PMR |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 333
|
I am trying to dig this old post because would be interested to know the result/ response from IBM for the PMR.
I am trying to enable clientAuth for some execution group / port for specific clients however allow traffic via https through a different port without authenticating their client certs.
Thanks in advance. |
|
Back to top |
|
 |
IIB_Intel |
Posted: Thu Jan 17, 2019 8:03 am Post subject: Invoking this old thread. |
|
|
Acolyte
Joined: 07 May 2015 Posts: 64
|
Trying to clarify few this on this.
1. For inbound connections to IIB (httpInput & SoapInput nodes) using mutual auth which command should we use to set the KS & TS at the EG/Integration server level?
mqsichangeproperties BRK -e EG1 -o HTTPSConnector -n keystoreFile -v <path to keystore file>
OR
mqsichangeproperties BRK -e EG1 -o ComIbmJVMManager -n keystoreFile -v <path to keystore file>
2. What advantage one command (as mentioned above) over the other?
My understanding is that we should use the first command as 2nd command can be used to set different KS (having different keys) for other outbound connections from IIB which needs mutual Auths.
The scenario that I am trying to address is:
A client sends a request message to a message flow containing SOAPInput/HTTPInput node using https with mutual authentication. The message flow is deployed to execution group EG1 under broker BRK. It processes and sends the message downstream into the flow. The message is propagated to the SOAPRequest/HTTPRequest node in the same message flow that sends a request using https with mutual authentication to a third party service provider (which uses a self signed cert for mutual auth).
In this case If I use command 1 for setting the KS for inbound connections and command 2 for setting the KS for outbound connections. I may be able to address it. |
|
Back to top |
|
 |
|