| Author |
Message
|
| ajaymohini |
 Posted: Wed Aug 19, 2015 1:39 am Post subject: SSL Handshake Issue In Message Broker |
 |
|
Novice
Joined: 27 Sep 2014
Posts: 10
|
Hi All,
Need your help regaarding an SSL hanshake issue that we are seeing. To give some info the same flow is deployed in 2 EG on seperate brokers while one of them is working fine we are getting sslHandshake on the other.
We have a HTTP Request node that invokes a WebService both the flows were working fine until now, but since last night we are starting to see SSl Handshake error on one the flows. Following is the stackTrace that our admin team Provided.
Exception in thread "Thread-31" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.n.a(n.java:3)
at com.ibm.jsse2.n.a(n.java:23)
at com.ibm.jsse2.jc.b(jc.java:6)
at com.ibm.jsse2.jc.a(jc.java:222)
at com.ibm.jsse2.jc.g(jc.java:17)
at com.ibm.jsse2.jc.a(jc.java:165)
at com.ibm.jsse2.jc.startHandshake(jc.java:35)
at com.ibm.broker.imbsslsocket.MbSslSocket.connectTimeoutInternalNoProxy(MbSslSocket.java:263)
at com.ibm.broker.imbsslsocket.MbSslSocket.connectTimeout(MbSslSocket.java:109)
at com.ibm.broker.plugin.MbOutputTerminal._propagate(Native Method)
at com.ibm.broker.plugin.MbOutputTerminal.propagate(MbOutputTerminal.java:103)
at com.ibm.broker.soap.SoapWrapperNode.evaluate(SoapWrapperNode.java:122)
at com.ibm.broker.plugin.MbNode.evaluate(MbNode.java:1476)
at com.ibm.broker.plugin.MbOutputTerminal._propagate(Native Method)
at com.ibm.broker.plugin.MbOutputTerminal.propagate(MbOutputTerminal.java:103)
at com.ibm.sr.mb.nodes.SRRetrieveITServiceNode.evaluate(SRRetrieveITServiceNode.java:473)
at com.ibm.broker.plugin.MbNode.evaluate(MbNode.java:1476)
at com.ibm.broker.plugin.MbOutputTerminal._propagate(Native Method)
at com.ibm.broker.plugin.MbOutputTerminal.propagate(MbOutputTerminal.java:103)
at com.xxxx.xx.xx.document.xx.Lookup.evaluate(Lookup.java:147)
at com.ibm.broker.javacompute.MbRuntimeJavaComputeNode.evaluate(MbRuntimeJavaComputeNode.java:180)
at com.ibm.broker.plugin.MbNode.evaluate(MbNode.java:1476) |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Aug 19, 2015 3:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Moved to the Broker forum...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 19, 2015 4:26 am Post subject: Re: SSL Handshake Issue In Message Broker |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ajaymohini wrote: |
| the same flow is deployed in 2 EG on seperate brokers while one of them is working fine we are getting sslHandshake on the other. |
Do the 2 EG / brokers have the same SSL set up? To the level of detail where they're using the same certificate chain?
| ajaymohini wrote: |
| We have a HTTP Request node that invokes a WebService both the flows were working fine until now, but since last night we are starting to see SSl Handshake error on one the flows. |
Ask whoever owns the web service that you're invoking what maintenance they performed between the last time the failing instance worked and the first failure. With specific reference to any changes to their SSL, e.g. renewed their personal certificate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 19, 2015 4:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
SSL errors are usually deliberately cryptic.
Enable JSSE trace with this environment variable
export IBM_JAVA_OPTIONS=-Djavax.net.debug=true
Then restart broker to pick this up, and then reproduce the issue
Then look at the execution groups JVM folder for the stdout/stderr files.
The SSL handshake will be listed in great detail and you can work out what the cause is from that.
Turn SSL trace off when finished.
_________________
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: Wed Aug 19, 2015 5:51 am Post subject: Re: SSL Handshake Issue In Message Broker |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| Ask whoever owns the web service that you're invoking what maintenance they performed between the last time the failing instance worked and the first failure. With specific reference to any changes to their SSL, e.g. renewed their personal certificate. |
No reason to expect that this is your configuration - especially if your configuration didn't change.. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Wed Aug 19, 2015 9:00 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Are the keystore and Truststore used by the 2 EGs on the 2 brokers containing the same certificates ? Is the one-way or 2 way authentication ? As far as the target is concern they just look at certificates. Since both brokers are talking to the same target , the certificate received from the target should most likely be the same. If the keystores of your 2 brokers contains that same certificates, most likely the target will be reading the same certificates from you. In that case there is no reason why it works on one and not the other. I use the term most likely is because there could other factors affecting the presentation of certificates. Does your target environment has any better (clearer) diagnostic message ? |
|
| Back to top |
|
|
| ajaymohini |
| Posted: Thu Aug 20, 2015 12:17 am Post subject: |
|
|
Novice
Joined: 27 Sep 2014
Posts: 10
|
| Thank you all for your help. We are currently using MB 6108 is JSSE debug applicable to this version? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 20, 2015 12:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Try it and see (I didn't say that it wouldn't work, as it probably will).
Why are you using a broker version that is long out of support?
_________________
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.
Last edited by zpat on Thu Aug 20, 2015 2:54 am; edited 1 time in total |
|
| Back to top |
|
|
| ajaymohini |
| Posted: Thu Aug 20, 2015 1:27 am Post subject: |
|
|
Novice
Joined: 27 Sep 2014
Posts: 10
|
| Thanks for your prompt reply, will a service trace have more detailed information if that is what i can have on version 6108 |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 20, 2015 1:30 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Not for SSL handshake issues.
Try it and see what happens.
(I didn't say that it wouldn't work, in fact it probably will work).
_________________
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 |
|
|
| Vitor |
| Posted: Thu Aug 20, 2015 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ajaymohini wrote: |
| Thank you all for your help. We are currently using MB 6108 is JSSE debug applicable to this version? |
I repeat my earlier comments that this sounds like something's changed on the provider side, so you can take all the trace you want and not find much that's probative.
One very real possibility is that the provider is now or will shortly be using a key length or cipher spec that v6.1.0.8 doesn't support because it's too old.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 20, 2015 5:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Or a TLS algorithm to ensure they aren't vulnerable to the basic flaws in SSL...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 20, 2015 6:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The JSSE debug log will usually pinpoint the issue. Although sometimes you need the other end to trace as well.
_________________
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 |
|
|
|
|
