| Author |
Message
|
| Vitor |
 Posted: Tue Sep 22, 2015 3:28 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Remember that all I want to do is send SOAP/HTTPS to a broker flow without specifying any keys. The target responds to SOAP-UP OOTB. I can also get the ?wsdl returned using a browser. |
As has been commented before in this forum, tools like web browsers and SoapUI come with a PKI where broker does not. You'll find a wealth of posts from people trying to make or establish HTTPS connections who point out "I can reach it with SoapUI" or "I don't need to do anything with Firefox to reach my bank".
Sad yet true. It's a cross we bear.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Sep 22, 2015 3:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Remember that all I want to do is send SOAP/HTTPS to a broker flow without specifying any keys. |
That's tautological. You can't use SSL (HTTPS) with no certificates (keys) in play. As a bare minimum you need something on the broker side to process and accept the certificate presented by the end point you're calling, so broker knows how to encrypt the traffic.
| smdavies99 wrote: |
| The target responds to SOAP-UP OOTB. I can also get the ?wsdl returned using a browser. |
Because both of those tools have a default PKI OOTB that will accept certificates signed by the usual suspects. As your endpoint almost certainly is.
| smdavies99 wrote: |
SO I defined a key/trust store.
| Code: |
set SHARED_DRIVE=C:
set KEYSTORE_DIR=SSL_Keystore
set PWD=Numpty1066
set KEYDIR=%SHARED_DRIVE%\%KEYSTORE_DIR%
set KEYSTORE=MYSTORE
%MQSI_JREPATH%\bin\ikeycmd -keydb -create -db %KEYDIR%\%KEYSTORE%.jks -type jks -pw %PWD%
|
and then did the following to the broker.
| Code: |
SET BKR=TESTBRKR
mqsichangeproperties %BKR% -o BrokerRegistry -n brokerKeystoreFile -v %KEYDIR%\%KEYSTORE%.jks
mqsichangeproperties %BKR% -o BrokerRegistry -n brokerTruststoreFile -v %KEYDIR%\%KEYSTORE%.jks
mqsistop %BKR%
mqsisetdbparms %BKR% -n brokerKeystore::password -u na -p %PWD%
mqsisetdbparms %BKR% -n brokerTruststore::password -u na -p %PWD%
mqsistart %BKR%
|
{the above steps were done using a single script} |
The key store and trust store are used for different things. For what it costs you (a few more lines of script) define two.
| smdavies99 wrote: |
| This is where I am at present. If only the customer wanted to use a proper key for the connection to the endpoint, life would be a lot simpler. |
Maybe.
Even with a single file (as you have) you have a trust store that doesn't trust anything. You should at least ensure that you trust the usual suspects (Thwaite, VeriSign, et al). Given the behavior of SoapUI and the web browser I would be surprised if you needed anything else.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Sep 22, 2015 3:39 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Ok. The system that connects to me in Production is a .Net application. It works fine with no keys specified.
It looks like I will have to revert to LOAD-UI to do these tests.
But something like this could be made a lot simpler within the tool.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Sep 22, 2015 3:42 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
| smdavies99 wrote: |
| Remember that all I want to do is send SOAP/HTTPS to a broker flow without specifying any keys. |
That's tautological. You can't use SSL (HTTPS) with no certificates (keys) in play. As a bare minimum you need something on the broker side to process and accept the certificate presented by the end point you're calling, so broker knows how to encrypt the traffic.
|
I should have said, "No explicitly defined certificates"
That ok?
The WebService I am trying to call is on a V9 broker. no specific keys have been defined there. I wish that trying to make the request was as easy as receiving it.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 22, 2015 4:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
I should have said, "No explicitly defined certificates"
That ok? |
Entirely. I'd also accept "anonymous connection".
| smdavies99 wrote: |
| The WebService I am trying to call is on a V9 broker. no specific keys have been defined there. |
Was this hosting the endpoint when it worked from the v7 broker and, at the risk of annoying you further, are you sure it has no PKI in place? Not even a default that's snuck in?
As I said, I'd be surprised if you got even an anonymous SSL link working with no PKI at either side.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Sep 22, 2015 4:20 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
Was this hosting the endpoint when it worked from the v7 broker and, at the risk of annoying you further, are you sure it has no PKI in place? Not even a default that's snuck in?
As I said, I'd be surprised if you got even an anonymous SSL link working with no PKI at either side. |
sorry to dissapoint you. There are no PKI keys defined in the system. That said, I guess that the set of keys that are in something like SOAPUI are embedded somewhere inside broker and the SOAP Input node uses them but this does not apply to the SOAP-Request node.
Perhaps it is time for an RFE?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 22, 2015 4:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
You're showing an alarming newbie behavior for SSL.
What you are after is a one way SSL.
This means the requester does not send any particular key.
However the requester has the full certificate signer chain in its truststore (mandatory). Usually browsers and stuff like maybe SOAPUI have those by default.
If they didn't https browsing on the internet would be impossible.
IIB does not come with a filled trustore by default, and there are good reasons for that. You can choose to create the truststore with the -populated option. This will fill it with the usual suspects public signer certs. However if your 3rd party uses something fancy, or has a more recent signer cert (not present at time of latest fixpack being applied) you will have to get and import the signer cert chain manually. This should be relatively trivial for a public CA. (Just go to the website and ask for the signer certs, download them and import them).
You mentioned something like .net not having any certs. WRONG! .NET will use the certs in the windows certificate store by default ....
As for your V9 broker, remember there are a lot of ways to define a keystore / truststore... broker default level, broker explicit, eg explicit etc... If a store does not exist at the eg level, it doesn't mean that the eg does not have the option to fall back to a broker default level store.
Have fun (and maybe talk to TRob) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Sep 22, 2015 5:27 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1647
|
| Quote: |
| IIB does not come with a filled trustore by default |
Actually it does. The JVM shipped with IIB has a file called "cacerts" and that is the default java truststore used by the JVM in IIB and includes quite a lot of certs for providers it will trust. You can see this in action by having a flow that is MQIn -> xxx -> HTTPRequest and configure the HTTPRequest node to use SSL to GET from any well known HTTPS web site (https://www.google.com for example) and you will see it succeed and return data as the cert is signed with a key that is in the cacerts file. To see the contents of the cacerts file run this command:
| Code: |
| C:\Program Files\IBM\IIB\10.x.y.z\common\jdk\jre\bin>keytool.exe -list -keystore "C:\Program Files\IBM\IIB\10.x.y.z\common\jdk\jre\lib\security\cacerts" |
This shows 103 entries in my setup here.
In this case, because you set the truststore in the "brokerRegistry" this means that cacerts is not used, and it can only trust certs signed by keys in the replacement store you provided. And in this case that store does not include the key for the site you are connecting to. I think, if you try the same test again, but do NOT set the "brokerTruststoreFile" at all it should hopefully work as it will default to cacerts instead.
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 |
|
|
| fjb_saper |
| Posted: Tue Sep 22, 2015 6:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
I stand corrected...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Sep 22, 2015 10:54 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mgk wrote: |
You can see this in action by having a flow that is MQIn -> xxx -> HTTPRequest and configure the HTTPRequest node to use SSL to GET from any well known HTTPS web site (https://www.google.com for example) and you will see it succeed and return data as the cert is signed with a key that is in the cacerts file. To see the contents of the cacerts file run this command: |
Interesting...
I replaced the SOAPRequest Node with an HTTPS request and pointed it at www.google.com whereupon it returned a 400 error. At least the SSL Part isn't throwing an error.[1]
Pointing the HTTP request back to my webService it fails with
| Code: |
An error occurred whilst performing an SSL socket operation | connect | javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
|
I think I will have to rely on LOAD-UI for these tests. I have an important benchmark coming up on Monday and really can't spend any more time on this. Sadly LOAD-UI is no longer a free tool. 4489Euros????
[1] This was on a totally clean broker. i.e. no property changes to the brokerRegistry or the EG ComIBMJVMManager etc etc.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Sep 23, 2015 4:15 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| smdavies99 wrote: |
Interesting...
I replaced the SOAPRequest Node with an HTTPS request and pointed it at www.google.com whereupon it returned a 400 error. At least the SSL Part isn't throwing an error.[1]
Pointing the HTTP request back to my webService it fails with
| Code: |
An error occurred whilst performing an SSL socket operation | connect | javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
|
...
[1] This was on a totally clean broker. i.e. no property changes to the brokerRegistry or the EG ComIBMJVMManager etc etc. |
Sounds like your WebService is not signed by one of the common CA's that would be in the default truststore.
I know that in many of the test environments where I work that we use self-signed certs to save on cert fees and therefore have to add them to our truststore to enable HTTPS calls to them to work.
The last time I had to deal with this (either v6 or v7) you had to restart the broker TWICE for changes to the cacerts file to be picked up. Never understood that. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 23, 2015 4:43 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| joebuckeye wrote: |
Sounds like your WebService is not signed by one of the common CA's that would be in the default truststore.
|
The WebService is actually running on a V9.0.0.3 broker and is working in Production.
I have to do some benchmarking so I tried to create a test flow that takes MQ messages and calls the Webservice. Harder than I envisaged.
I just got the ok to run the benchmark with HTTP and not HTTPS. Now I can push 150K messages through it easily.
Still it was a good learning exercise. A case where NOT using an SSL/TLS Key proved harder to implement that it would be when using one.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Sep 23, 2015 4:48 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1647
|
| Quote: |
| The last time I had to deal with this (either v6 or v7) you had to restart the broker TWICE for changes to the cacerts file to be picked up. Never understood that |
Thankfully this very away around V9 and is no longer necessary. Actually the double restart was only required when changing an HTTPInput nodes URI, rather than for cacerts, but nevertheless it was a pain.
| Quote: |
| I replaced the SOAPRequest Node with an HTTPS request and pointed it at www.google.com whereupon it returned a 400 error |
So I've just tried this as well and it works fine for me as long as you check "Follow HTTP(S) Redirection", se the "HTTP Method" to GET and send an empty message body into the node you will get back a "200 OK".
As I said above, once you set (change) the Broker Registry "brokerTruststoreFile" to your own store, you then have to put the correct public key for the server(s) you are talking to into that store as cacerts is no longer used.
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 |
|
|
| fjb_saper |
| Posted: Wed Sep 23, 2015 5:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| smdavies99 wrote: |
I replaced the SOAPRequest Node with an HTTPS request and pointed it at www.google.com whereupon it returned a 400 error. At least the SSL Part isn't throwing an error.[1]
Pointing the HTTP request back to my webService it fails with
| Code: |
An error occurred whilst performing an SSL socket operation | connect | javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
|
[1] This was on a totally clean broker. i.e. no property changes to the brokerRegistry or the EG ComIBMJVMManager etc etc. |
Well it depends on the date of your last cert...
This points to either some certs used by your destination not being in your truststore. It could be an intermediate signer cert or a private CA / CA Chain, or a self signed cert...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 23, 2015 6:21 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| fjb_saper wrote: |
This points to either some certs used by your destination not being in your truststore. It could be an intermediate signer cert or a private CA / CA Chain, or a self signed cert... |
There was no Keystore or truststore defined for this broker as suggested by MGK.
Anyway, we are going to do the load test with HTTP rather than HTTPS.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
