How to resolve following issue in Netapp
Caused by: javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.
Please see NetApp article:
https://library.netapp.com/ecmdocs/ECMP1155684/html/GUID-3E07D3F8-6A05-49C0-BF92-9C88BA252E1F.html
All you need is:
options tls.enable on
Be sure to do all cluster nodes.
Good luck.
Related
I'm using nifi in version 1.14.0 and facing a very weird situation.
I have a loadbalanced connection and after disconnection in the cluster (due to out of memory errors)
I'm getting the following error:
Error load balance server -
standartLoadBalanceProtocol attempted to receive flowfile from peer for connection with id xxx but no connection exists with that ID
Did anyone experience anything familiar? Thanks for the help!
I think it relates to this ticket https://issues.apache.org/jira/plugins/servlet/mobile#issue/NIFI-9695. Please upgrade to NiFi version 1.16 and see if this error happens again.
We have a single installation of WAS(8.5.5.10), with multiple clusters(JVMs). We enabled TLS1.2 on one of the JVMs, (say JVM1). But when I run the code sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0. My application runs on Java 1.7.
When I check in Security > SSL certificate and key management, and under Related Items, click SSL configurations. ( such as CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig), it shows 'TLS' as the protocol, under QoP settings.
But when I check in SSL certificate and key management > Manage endpoint security configurations > jvm1_cluster, it shows 'TLS1.2' as SSL configuration.
From IBM forums, I came to understand that it is possible to enable TLSV1.2 at only one cluster. and need to use jssehelper to specify an outbound ssl configuration.
Tried following the link on how to programmatically specifying an outbound SSL configuration using JSSEHelper API. https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_ssloutconfiguseJSSE.html
but I still could not get it to work. When I print the properties, I can see protocol as TLSV1.2 (com.ibm.ssl.protocol = TLSv1.2). Application uses com.ibm.jsse2.SSLSocketFactoryImpl for ssl socket provider.
To give you some background, am trying to connect to APNS using okhttp3 library. Am adding these properties, at the place where I create the socket connection. And after the socket is created, when I do sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0.
Since it tries to connect via TLS1, it gives javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure, when trying to establish connection to APNS. I have the certificate added to was store already and the firewall rules are in place as well, to allow the connection.
Error:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.j.a(j.java:23)
at com.ibm.jsse2.j.a(j.java:21)
at com.ibm.jsse2.qc.b(qc.java:465)
at com.ibm.jsse2.qc.a(qc.java:451)
at com.ibm.jsse2.qc.h(qc.java:759)
at com.ibm.jsse2.qc.a(qc.java:353)
at com.ibm.jsse2.qc.startHandshake(qc.java:800)
Pls guide me on how to fix the issue. Thanks.
Guys I am trying to connect to MQ Hub from WAS Liberty application. Our MQ Hub supports only SSL certificate authentication. I have created QCF, Keystore with JKS file and with certificate inside it. Then I created defaultSSLConfig and pointed to that keystore.
But I could not find anyway to specify the SSLConfig in the QCF and read on some page that it was not possible. The only way was to use defaultSSLConfig and specify keystore from there which I did. So now I am here and MQ connection does not work. On the MQ Hub logs I see the error saying that "The channel is lacking a certificate to use for the SSL handshake."
This is how my QCF looks like, no parameter to specify an SSL config
<jmsConnectionFactory connectionManagerRef="ConMgr" jndiName="jms/wmqCF">
<properties.wmqJms channel="TEST_CHANNEL" hostName="REMOVED" port="1415" queueManager="ALQ.TEST" transportType="CLIENT" sslCipherSuite="SSL_RSA_WITH_AES_128_CBC_SHA"/>
</jmsConnectionFactory>
Full error on MQ side
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The
channel
name is 'XXX.ADM.SVRCONN' (if '????' it is unknown at this stage in the
SSL
processing).
The remote host is 'XXX (10.xx.xx.x)'.
The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the
key
repositories for both ends of the channel.
----- amqccisa.c : 7355
02/14/17 15:07:44 - Process(7510.304808) User(mqm) Program(amqrmppa)
Host(xxx) Installation(Installation1)
VRMF(7.5.0.6) QMgr(XXXXX)
AMQ9999: Channel 'XXX.ADM.SVRCONN' to host 'xxx (10.xx.xx.xx)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 7510 for channel 'XX.ADM.
SVRCONN'
ended abnormally. The host name is 'xx (10.xx.xx.xx)'; in some
cases the
host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error
logs to
determine the cause of the failure. Note that this message can be
excluded
completely or suppressed by tuning the "ExcludeMessage" or
"SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information
can be
found in the System Administration Guide.
It is working now :) What we think was the cause of the problem is this bug http://www-01.ibm.com/support/docview.wss?uid=swg1IT16056
Although the error in APAR above is not the same I was getting. I was seeing this error on the Liberty (client side)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with
compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.
java:203)
I was using this resource adapter when the problem was manifesting itself: 9.0.1.0-IBM-MQ-Java-InstallRA.jar
Then we decided to try lower version of the adapter which had that APAR/fix in it and thus used this one: 8.0.0.6-WS-MQ-Java-InstallRA.jar
So that solved the problem.
I was pretty sure that the above bugfix was included in Ver 9.X of the resource adapter but as it turns out it is not the case.
I checked with IBM and they confirmed that APAR IT16056 is not included in the 9.0.1.0 CD release. They are working to correct the APAR to show the right target release for the fix.
Quote from IBM support is below.
I can confirm that the APAR in question, "IT16056" is NOT included in
the 9.0.1.0 CD release, and is currently targeted to be included in
the 9.0.2.0 CD release.
Based on this if you want you use a version of the RA higher than 8.0 you would need to do one of the following:
Wait until the 9.0 LTS (Long Term Support) 9.0.0.1 fixpack is released (IBM has a site where they list they are targeting 1Q 2017).
Wait until the 9.0 CD (Continuous Delivery) 9.0.2.0 release is out (IBM does not publish a target for CD)
Open a PMR to IBM and ask them for a IFIX to apply the 9.0.0.1 LTS or 9.0.1.0 CD release.
I enabled "Decrypt HTTPS traffic" and "Ignore server certificate errors" in Fiddler but the traffic of one website is not being showed.
This is the error that Fiddler is returning:
[Fiddler] The connection to '...' failed. System.Security.SecurityException Failed to negotiate HTTPS
connection with server.fiddler.network.https> HTTPS handshake to
... failed. System.IO.IOException Received an unexpected EOF
or 0 bytes from the transport stream.
I remember that I could ignore this error in Fiddler script, but I really don't remember.
Does anyone know what's going on?
Thanks! =)
What is the site's URL?
It is probably caused by either of these two issues: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx or http://blogs.msdn.com/b/fiddler/archive/2012/03/29/https-request-hangs-.net-application-connection-on-tls-server-name-indicator-warning.aspx
The old workaround is to configure Fiddler to only use SSL3 when talking to the host in question. The newer workaround is to either use Fiddler4 with the latest .NET4.5.2 framework, or if you're using Fiddler 2.5.1, see the "SNI Hack" section of http://www.telerik.com/blogs/what-s-new-in-fiddler-4-5-1
In your OnBeforeRequest event handler, add the following code to fix the issue for certain sites:
if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("BuggySite.com"))
{
oSession["https-DropSNIAlerts"] = "yup";
FiddlerApplication.Log.LogString("Legacy compat applied for request to BuggySite.com");
}
A bit late for the poster unfortunately but I just needed to add tls1.2:
Tools
Options
HTTPS
Protocols
Add tls1.2 to the end of the list and click ok
I was seeing the following exception:
System.Security.SecurityException Failed to negotiate HTTPS connection
with server.fiddler.network.https. HTTPS handshake to
api.etadirect.com (for #9) failed. System.IO.IOException Unable to
read data from the transport connection: An existing connection was
forcibly closed by the remote host. An existing connection was
forcibly closed by the remote host
I was able to fix it by enabling the TLS1.2 protocol which is not enabled by default for outgoing connections
Tools -> Options -> HTTPS -> click on protocols list
I have following situation:
there is some Jmeter test. I run it from different locations. I get below error for some requests.
org.apache.http.NoHttpResponseException', 'Non HTTP response message:
The target server failed to respond'
Error is not permanent, it happens from time to time.
The weird thing here is that for some location this error happened and for some not.
Jmeter configuration (jmeter.properties) is identical for all locations, however mentioned error occurred only for some of them.
I've searched regarding that error and find a post about problem with HttpClient4 (which is default for HttpSampler implementation).
When I change implementation to 'Java' - problem gone.
However I can't understand why does the test works from one location and failed from another. Does somebody have any ideas regarding that? The only idea I have is some kind of firewall that has some connections limitation from some specific address.
p.s. All URL that fails where accessible from all locations with the browser, if any.
Read this:
https://wiki.apache.org/jmeter/JMeterSocketClosed
It explains why issue happens with HTTP Client.
Browsers by default do stale check and retries which may explain why you don't reproduce in Browsers.
I was getting the same problem when trying to get a token from WSO2
org.apache.http.NoHttpResponseException: The target server failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Changing the Protocol to https worked for me.