| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SSL Handshake Exception after upgrading from IIB 9.0.0.6 to |
« View previous topic :: View next topic » |
| Author |
Message
|
| ramesh.patil |
 Posted: Wed Jan 31, 2018 4:26 am Post subject: SSL Handshake Exception after upgrading from IIB 9.0.0.6 to |
 |
|
Newbie
Joined: 16 Dec 2015
Posts: 9
|
Hi,
We are not able to make secure web service request to Exact Target. We are encountering with SSL handshake error. We are using HTTPRequest node to invoke REST API. We have tried to change protocol to TLS as suggested by IBM support info center but the we could not get positive results. We have two obseravtions from logs.
Client key alias supplied was []. : But there was no certificate installed for IIB 9 which is working fine. and we confirmed with Endpoint and they are not validating client's certificates.
2.we could see that IIB 10 sent a much shorter list of supported ciphers and elliptic curves
nsuccessful handshake that the ClientHello occurred but the ServerHello did not occur.
ClientHello, TLSv1 Line 698: 2018-01-16 07:12:28.574
Can some one help us to resolve this issue.
Thanks. Ramesh |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jan 31, 2018 5:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You will need to be a lot more specific. And please remember that not all certificates will work with all ciphersuites...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Wed Jan 31, 2018 5:34 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
Hi Ramesh...can you please crosscheck whether the truststore settings are configured correctly for v10 (compare the same against v9 as well).
mqsireportproperties <brokername> -o BrokerRegistry -r |
|
| Back to top |
|
|
| ramesh.patil |
| Posted: Wed Jan 31, 2018 6:11 am Post subject: |
|
|
Newbie
Joined: 16 Dec 2015
Posts: 9
|
| abhi_thri wrote: |
Hi Ramesh...can you please crosscheck whether the truststore settings are configured correctly for v10 (compare the same against v9 as well).
mqsireportproperties <brokername> -o BrokerRegistry -r |
Yes, It's configured properly.. compared with IIB 9 truststore.. both looks similar. Here is the IIB 10 truststore
BrokerRegistry
uuid='BrokerRegistry'
brokerKeystoreType='JKS'
brokerKeystoreFile=''
brokerKeystorePass='brokerKeystore::***(modified for posting)'
brokerTruststoreType='JKS'
brokerTruststoreFile=''
brokerTruststorePass='brokerTruststore::***(modified for posting)'
brokerCRLFileList=''
httpConnectorPortRange=''
httpsConnectorPortRange=''
brokerKerberosConfigFile=''
brokerKerberosKeytabFile=''
allowSSLv3=''
allowSNI=''
reenableTransportAlgorithms=''
reenableCertificateAlgorithms=''
mqCCDT=''
modeExtensions=''
operationMode='advanced'
adminMessageLogging=''
productFunctionality=''
mqKeyRepository=''
dataCapturePolicyUri='URL(modified for posting)'
shortDesc=''
longDesc=''
And i believe it's not related to certificate. The endpoint doesn't require certificate from client. IIB 9 works fine without the certificate. I think it's something related to ciphers. coz IIB 10 is sending a much shorter list of supported ciphers and elliptic curves compared to IIB 10. There is something about the clientHello that the server is not compatible with, and so it terminates the handshake. Please let me know if you need any details from log.
There is one more odd line in the log
jdk.tls.client.protocols is defined as null
Last edited by ramesh.patil on Wed Jan 31, 2018 6:46 am; edited 2 times in total |
|
| Back to top |
|
|
| ramesh.patil |
| Posted: Wed Jan 31, 2018 6:25 am Post subject: |
|
|
Newbie
Joined: 16 Dec 2015
Posts: 9
|
| fjb_saper wrote: |
You will need to be a lot more specific. And please remember that not all certificates will work with all ciphersuites...
Have fun |
Hi, Can you please let me know f you need specific details. I'll try to get it. Please find the JSSE log from IIB 10
Exception: 2018-01-25 00:37:11.337 52 Thread-36, READ: TLSv1 Alert, length = 2
2018-01-25 00:37:11.338 52 Thread-36, RECV TLSv1.2 ALERT: fatal, handshake_failure
2018-01-25 00:37:11.340 52 Thread-36, called closeSocket()
2018-01-25 00:37:11.340 52 Thread-36, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
2018-01-25 00:37:11.341 52 unable to negotiate SSL connection. Client key alias supplied was [].
Exception in thread "Thread-36" 2018-01-25 00:37:11.343 52 javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
2018-01-25 00:37:11.344 52 at com.ibm.jsse2.k.a(k.java:24)
2018-01-25 00:37:11.344 52 at com.ibm.jsse2.k.a(k.java:26)
2018-01-25 00:37:11.345 52 at com.ibm.jsse2.at.b(at.java:896)
2018-01-25 00:37:11.345 52 at com.ibm.jsse2.at.a(at.java:173)
2018-01-25 00:37:11.346 52 at com.ibm.jsse2.at.i(at.java:509)
2018-01-25 00:37:11.346 52 at com.ibm.jsse2.at.a(at.java:259)
2018-01-25 00:37:11.347 52 at com.ibm.jsse2.at.startHandshake(at.java:392)
2018-01-25 00:37:11.347 52 at com.ibm.broker.imbsslsocket.MbSslSocket.connectTimeoutInternalNoProxy(MbSslSocket.java:390)
2018-01-25 00:37:11.347 52 at com.ibm.broker.imbsslsocket.MbSslSocket.connectTimeout(MbSslSocket.java:224)
IIB 10 Non working
2018-01-25 00:37:11.267 52 *** ClientHello, TLSv1
2018-01-25 00:37:11.271 52 Session ID: {}
2018-01-25 00:37:11.272 52 Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA]
2018-01-25 00:37:11.272 52 Compression Methods: { 0 }
2018-01-25 00:37:11.275 52 [write] MD5 and SHA1 hashes: len = 114
IIB 9 working
2018-01-25 00:54:46.155 30 *** ClientHello, TLSv1
2018-01-25 00:54:46.157 30 Session ID: {}
2018-01-25 00:54:46.157 30 Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA]
2018-01-25 00:54:46.157 30 Compression Methods: { 0 }
2018-01-25 00:54:46.171 30 ***
2018-01-25 00:54:46.171 30 [write] MD5 and SHA1 hashes: len = 142
I can see the difference in the ciphers supported in IIB 10 and IIB 9. We assume it's not certificate issue as the web service call is working from postman plugin without any certificate from the same toolkit where IIB 10 is installed and as well as in IIB 9 without any certificate installed.
There is one more odd line in the log
jdk.tls.client.protocols is defined as nul
Thanks,
Ramesh |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Jan 31, 2018 9:16 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
Are you sure the provider supports any of the ciphers IIB 10 uses?
We have seen issues of older configurations not working properly due to lack of newer ciphers. In these cases the providers need to be updated to better security. |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Thu Feb 01, 2018 12:40 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
Even though client certifications are not involved I think Broker will use the cacerts (default JVM truststore) to decide whether to trust the certificate presented by the remote end. So you can please crosscheck,
- whether cacerts exists and is accessible,
/opt/ibm/iib-10.0.0.x/common/jdk/jre/lib/security/cacerts
- Is Broker able to access the truststore, the start of the JSSE trace should show the exact keystore/trustore loaded by broker
- If there are no obvious issues with cacerts try restarting the Broker in case this was not done since the initial installation.
- Also you haven't mentioned the exact v10 version you are using, it is worth moving to one of the latest fixpacks
Regarding
| Quote: |
| We have tried to change protocol to TLS as suggested by IBM support info center |
don't think it is necessary to do so in later versions of v10 as 'SSL' will now only enable 'Enables TLS v1.0, v1.1, and v1.2 protocols.' while if you explicitly select 'TLS' then you are restricted to 'TLS v1.0'
https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/protocols.html |
|
| Back to top |
|
|
| prasadpav |
| Posted: Thu Feb 01, 2018 3:38 am Post subject: |
|
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
It appears that your SSL session is failing at the very first stage of protocol negotiation:
| Quote: |
Exception: 2018-01-25 00:37:11.337 52 Thread-36, READ: TLSv1 Alert, length = 2
2018-01-25 00:37:11.338 52 Thread-36, RECV TLSv1.2 ALERT: fatal, handshake_failure
2018-01-25 00:37:11.340 52 Thread-36, called closeSocket()
2018-01-25 00:37:11.340 52 Thread-36, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure |
Change the protocol to TLSv1.2 and see what happens, as that is what your broker appeared to have received from your server. |
|
| 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
|
|
|
|
