My eclipse plugin application still gets SSLProtocolException: handshake alert: unrecognized_name on java version "1.8.0_141" although I followed some tips to disable SNI extension already.
[INFO] Property jsse.enableSNIExtension=false
[FATAL] javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
at sun.security.ssl.ClientHandshaker.handshakeAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
Please help me on this case, thanks.
The unrecognized_name alert might be sent back by the server if the name sent with SNI is unexpected. But it might also be sent back if the server requires SNI to be used and no server name was sent by the client. Disabling SNI like you do can thus trigger the second case, i.e. the server requires SNI but the client does not provide it.
The correct way to deal with this error is to use the SNI extension and set the name to the one expected by the server.
Related
I am getting "Failed to negotiate transport Component" in the log. Does anybody have any idea what can be the cause, because it doesn't seem to be any code side issue.
Thanks in advance.
Failed to negotiate a transport component [aes192-cbc] [arcfour] [Unknown cause]
at com.maverick.ssh2.TransportProtocol.B(Unknown Source)
at com.maverick.ssh2.TransportProtocol.C(Unknown Source)
at com.maverick.ssh2.TransportProtocol.processMessage(Unknown Source)
at com.maverick.ssh2.TransportProtocol.startTransportProtocol(Unknown Source)
at com.maverick.ssh2.Ssh2Client.connect(Unknown Source)
at com.maverick.ssh.SshConnector.connect(Unknown Source)
at com.maverick.ssh.SshConnector.connect(Unknown Source)
The server supports "arcfour" cipher only, while your client supports "aes192-cbc" only.
The j2ssh-maverick implements the "arcfour" too. You can enable it by using JCEComponentManager.installArcFourCiphers.
Though note that "arcfour" is a weak cipher and you should avoid it, if possible. Consider upgrading the server.
I am testing a webservice and it works fine in SOAP UI tool.
Now I am writing a webservice client in java to test same. I executed the wsimport command and generated the required classes.
The issue is when I am calling the service it displays the following message in console. It seems the server is trying to redirect but redirection is failing. I am doubting there may be issue with http/https OR GET/POST methods but not sure how to fix.
Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 302: Found
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
Please suggest.
Regards,
Arun
After more analysis and change I am able to fix this issue. As I doubted the cause was redirection from http to https.
This post helped: Calling web service that sits on a load balancer with jax-ws returns at http status of 302, but when I use SoapUI it works fine
Regards,
Arun
I have a REST service and some clients get a "Connection reset" error. But SOAP is stateless, so why doesn't it just simply reconnect and resend the request? It actually sends multiple messages in my use case, but the very first fails, and that is just to get some config data from the server. Is this something I need to configure? Should the client programmatically try to resend the message? Some users tried multiple times with the same result.
It never happened in the last years but now I get some reports of this problem.
The client uses in implementation of javax.xml.ws.Service, not just a raw socket. But even though I use JAX I get the low level error. It is wrapped by a WebServiceException, but that doesn't really help me fixing this problem.
The clients all use Java 8. It's either Update 66 or Update 74.
I am not able to reproduce the problem myself, I only have log files from users.
Here's the complete stack trace:
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
at com.sun.proxy.$Proxy31.getLimits(Unknown Source)
at xxxxxxxxxxxxx.SOAPServerAdapter.connect(Unknown Source)
at xxxxxxxxxxxxxxxxxxxx(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
... 18 more
It turned out it was about IPv4 and IPv6. I don't have enough knowledge to give a perfect answer but I can post here what they told me. Maybe this helps other devs/users who have the same problem.
So some clients have unexpected connection resets and it's not about server load as it usually is.
If the ISP of the client tries to get away from IPv4 they will give each user a unique IPv6 address (note that the ISP might do this gradually). They do not really have an IPv4 address per client any more, other than the IPv4 used locally, since most still use something like 192.168.0.0/24 for their LAN.
Instead of classic IPv4 they use some transaction mechanism (e.g. Dual-Stack Lite). Those clients to not have direct access to the IPv4 internet. So if your server only supports IPv4 then they might experience similar problems you get when they use a proxy. They encapsulate IPv4 packets within IPv6 packets for some parts of the communication. From Wikipedia: "The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet."
I don't really know what's going wrong here. Maybe the NAT runs out of addresses / ports or something like that. Or the process takes too long you the connection is reset by some node that is involved in the communication.
So there are two things to do:
Inform the ISP about those problems. They probably will help you trace the exact problem and help their clients so they can use your service. For that you need to know the ISP of the users that have the "connection reset" problem. Send them to https://www.whoismyisp.org/ or similar site.
Upgrade to IPv6 as soon as possible. Your server can use both versions of the protocol at the same time.
Check the load on your server. Looks like server is closing connections because of load - exception on web-service call
I have a web service hosted on IIS on windows machine. Everything went fine until I upgraded Java to JRE 8u65.
Now it is throwing the below exception on invoking the web service.
Exception in thread "main" java.net.SocketException: Unexpected end of
file from server at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown
Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown
Source)
Note : Previously I was using JRE 8u60. Any help in this regard is really helpful.
Thanks in advance!
The stacktrace you have shown us comes from a Java client for your web service. What is saying is that the server has closed the network connection before sending an HTTP response.
There is no evidence in this stacktrace to say why the web service did that. The evidence is probably in the service logs.
I am running a JMeter test with "Java Request" sampler which performs POST request to HTTPS service which uses TLS v1.2. The request fails with
2015/12/01 19:11:50 ERROR - jmeter.protocol.java.sampler.AbstractJavaSamplerClient: 2015-12-01T16:11:50.189Z message:**** Exception in JMeter node for Login java.lang.RuntimeException: Failed to getServerToken
at com.chrysler.loadtest.GUIMimicLogin.getServerToken(GUIMimicLogin.java:227)
at com.chrysler.loadtest.GUIMimicLogin.runTest(GUIMimicLogin.java:97)
at org.apache.jmeter.protocol.java.sampler.JavaSampler.sample(JavaSampler.java:191)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:436)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
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.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at com.chrysler.loadtest.GUIMimicLogin.getServerToken(GUIMimicLogin.java:215)
... 5 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 18 more
JMeter used to work with this server when it used TLS v1.1. Is there a setting in JMeter properties which can set the applicable protocol.
The JMeter version is 2.13, Java version is 1.7.
This is an SSL error and can mean several things. Make sure you have TLS 1.2 enabled in your application (JVM argument?)(-Dhttps.protocols=TLSv1.2). You can use openssl to check the connection and see if you are getting back a certificate. If you are then check your keystore and make sure you have the correct certificate. You may not be authorized to access that server.