| Author |
Message
|
| j.f.sorge |
 Posted: Wed Jan 06, 2016 6:50 am Post subject: WMB 8.0.0.1 HTTPRequest configure SSL client authentication |
 |
|
Master
Joined: 27 Feb 2008
Posts: 218
|
Having a look at the configuration options of HTTPRequest node at http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ac04595_.htm?lang=en is shows one option where you could configure "SSL client authentication key alias". In a WMBT 8.0.0.1 this option is not available but I was able to configure that property via WMBT 8.0.0.4
Question is which fixpack version of WMB 8 runtime is needed in order to make use of that property?
In addition I am wondering whether I could set that property via LocalEnvironment?
_________________
IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
 |
| mgk |
| Posted: Wed Jan 06, 2016 8:20 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi.
I believe it was added in 8.0.0.2, but I would recommend updating to the most recent FixPac if you can. You can also override this for the HTTPRequest and HTTPAsyncRequest nodes in the LE under:
| Code: |
| LocalEnvironment.Destination.HTTP.KeyAlias |
For the SOAP nodes you can override this in the LE under:
| Code: |
| LocalEnvironment.Destination.SOAP.[Reply | Request | Input].Transport.HTTP.KeyAlias |
making sure you set Reply or Request or Input depending on the SOAP node you are overriding this for.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Last edited by mgk on Wed Jan 06, 2016 3:48 pm; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jan 06, 2016 9:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@mgk Could you please specify the scenario for an override at the SOAP Input node? I thought the key alias was only for request / reply node. The rest would be handled with the policy? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Jan 06, 2016 11:55 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Like you say, the key alias is mainly aimed at request and reply scenarios and allows the HTTP or SOAP [Async]Request or SOAPReply nodes to use the certificate with the given alias from the keystore when using client auth. However, there is a relatively obscure scenario with the SOAPInput node it if is using WSAddressing (WSA). A message arriving at a SOAP Input node that is configured to support WSA can contain a ReplyTo and/or a FaultTo Endpoint Reference that may contain a "non-anonymous" address. This means that the ReplyTo or Fault to WSA headers can request that a response is sent to a different server to the one that send the originating request and the originating server just receives a 204 response (if HTTP). Infact, it gets more interesting - the ReplyTo and /or FaultTo can be different to each other and can also be different transports to the originating request as well. So you can receive an HTTP message and reply with JMS or vice-versa. And IIB supports all of this. Where the LocalEnvironment override comes in is for this case where the FaultTo address is a different HTTPS server to the originating request which means a new outbound HTTP request must be made to the server specified. In this scenario, if an exception happens in the flow, and makes it back to the SOAPInput node, the node must makes an outbound connection to the server specified in the FaultTo. In this case, the server may require client auth, which means the default (first) key in the keystore will be used. However, if you need to override this key then in the *first* Compute (or Database) node after the SOAPInput node you can set the required "keyAlias" in the [Input]LocalEnvironment to the name of the alias to use. Almost all the other LE overrides for HTTP can also be specified in the same way if necessary and the SOAPInput node will use these settings when sending the SOAP Fault request to the remote server. Most of the time this is not needed, but occasionally can be useful.
Note that the actual LE location for AsyncFault's is not the one I posted before as I mistyped it, it's actually:
| Code: |
| LocalEnvironment.SOAP.Input.Transport.HTTP.AsyncFault.KeyAlias |
Kind regards.
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| j.f.sorge |
| Posted: Wed Jan 06, 2016 11:39 pm Post subject: |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
Thanks a lot for your quick responses!
| mgk wrote: |
| I believe it was added in 8.0.0.2, but I would recommend updating to the most recent FixPac if you can. |
I know that we are really outdated. Problem is that only FP 6 contains all our private fixes we need but that does not work in combination with our current version of WTX. 
| mgk wrote: |
You can also override this for the HTTPRequest and HTTPAsyncRequest nodes in the LE under:
| Code: |
| LocalEnvironment.Destination.HTTP.KeyAlias |
|
How will that feature work if you do not provide the KeyAlias? Will WMB try to authenticate with the "first" key in its JKS?
_________________
IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Jan 07, 2016 2:26 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Will WMB try to authenticate with the "first" key in its JKS? |
As with other options in WMB/IIB, the precedence order is LocalEnvironment, then Node option. so if the LE is not set the node option will be used. If none of these are set (or you are using a version without the node and LE options like 8.0.0.1) then yes, we will try the "first" key in the key store. This works great if you only have one key in the store  . However it's not so good if you need more than one key so that's why we added the keyAlias options to the node and LE.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| j.f.sorge |
| Posted: Thu Jan 07, 2016 3:46 am Post subject: |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
| mgk wrote: |
| If none of these are set (or you are using a version without the node and LE options like 8.0.0.1) then yes, we will try the "first" key in the key store. This works great if you only have one key in the store |
I was quite sure that the keystore just had one single keyfile within, therefore I am wondering how to check / trace which certificate has been chosen for authentication? Is there an additional option or property to be activated in order to use client certificate?
_________________
IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 07, 2016 4:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Run a SSL trace to see the cert that was loaded. Set this environment variable and restart the broker. Look in the EG JVM log directory for the SSL trace.
| Code: |
| export IBM_JAVA_OPTIONS=-Djavax.net.debug=true |
_________________
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 |
|
|
| j.f.sorge |
| Posted: Thu Jan 07, 2016 11:52 pm Post subject: |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
| zpat wrote: |
Run a SSL trace to see the cert that was loaded. Set this environment variable and restart the broker. Look in the EG JVM log directory for the SSL trace.
| Code: |
| export IBM_JAVA_OPTIONS=-Djavax.net.debug=true |
|
Thanks a lot! That trace already helped a lot when we had SSL handshake issues...
_________________
IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
|
|
