I have a problem connecting from my .Net client to Java server, both were changed from TLS1 to TLS1.2.
Both client and server in the same machine, Windows10 64bits.
.Net client created under .Net Framework 4.5, using HttpWebRequest.
Previous the request call I set
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
.Net Error "The request was aborted: Could not create SSL/TLS secure channel."
Java using jdk1.8.0_25
Java Error log:
P-86, received EOFException: error
P-86, handling exception: javax.net.ssl.SSLHandshakeException: Remote host
closed connection during handshake
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA256]
P-86, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
P-86, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
P-86, called closeSocket()
P-86, called close()
P-86, called closeInternal(true)
I have changed to different ciphers with no success. Any suggestion to follow ?
thanks
My problem was the certificate.I was using a very old one, I changed it and It works. I'm not clear why, I'm investigating.
Thanks to all.
Related
On server I've got a certificate which I am using to connect to other webservice.
Certificate is correctly installed on server, because when I am using curl to make a request, everything works fine. The problem is when I am using rest request through my webservice in Spring.
I've got exception:
handling exception: javax.net.ssl.SSLHandshakeException:
I was trying changing tls protocols and it didn't help.
What may cause the problem?
There is a code of a debugger:
https-jsse-nio-8080-exec-4, WRITE: TLSv1 Handshake, length = 120
https-jsse-nio-8080-exec-4, received EOFException: error
https-jsse-nio-8080-exec-4, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
https-jsse-nio-8080-exec-4, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
https-jsse-nio-8080-exec-4, WRITE: TLSv1.2 Alert, length = 2
https-jsse-nio-8080-exec-4, called closeSocket()
https-jsse-nio-8080-exec-4, called close()
https-jsse-nio-8080-exec-4, called closeInternal(true)
I have an application running on Jetty 6 which is accessed over HTTPS. Connecting with IE 11 works but not Firefox 43 or Google 40.
The SSL trace shows that Jetty and browser fail to find a common cipher:
%% Initialized: [Session-13, SSL_NULL_WITH_NULL_NULL]
%% Invalidated: [Session-13, SSL_NULL_WITH_NULL_NULL]
783842035#qtp-1833323686-4, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
783842035#qtp-1833323686-4, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
783842035#qtp-1833323686-4, called closeSocket()
783842035#qtp-1833323686-4, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common
However, when IE 11 is used the selected cipher is TLS_DHE_DSS_WITH_AES_128_CBC_SHA256:
%% Initialized: [Session-30, SSL_NULL_WITH_NULL_NULL]
%% Negotiating: [Session-30, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256]
*** ServerHello, TLSv1.2
Since Chrome warns about RC4 ciphers when it fails to connect:
A secure connection cannot be established because this site uses an >>unsupported protocol or cipher suite. This is likely to be caused when the >>server needs RC4, which is no longer considered secure.
I have excluded RC4 in java.security by adding the following property
jdk.tls.disabledAlgorithms=RC4
but to no avail, Chrome and FF still fail to connect.
I've ran out of ideas. Any suggestions? TIA.
Jetty 6 is long ago EOL (End of Life).
If you stick with Jetty 6, know that the level of SSL/TLS tweaking you need is not present in that version of Jetty.
You'll either have to stick with JVM level tweaks, or write a custom SslSelectChannelConnector (sorry, the easier SslContextFactory concepts were introduced in Jetty 7) implementation of your own to accomplish the necessary includes and excludes of ciphers and protocols, along with the new TLS ciphers ordering requirements to pull this off reliably.
Jetty 9.3.7.v20160115 is almost up to date with the recent and upcoming browser changes. The next release, likely 9.3.8, will have the remaining tweaks necessary to support the recent browser changes, but only under Java 8u72 (or newer).
Also of note, since you have SSL/TLS enabled on Jetty, you have to keep your version of Java up to date, if for no other reason then to keep up with the changes in SSL/TLS over the past few years.
I have a CXF web services server running with embedded jetty.
A client connects and send several successful requests to the server.
After 5-10 seconds suddenly the client hangs.
The client / server reuse the same connection for all requests.
After running the server with -Djavax.net.debug=all I've noticed the following message before the connection hangs.
Keep-Alive-Timer, called close()
Keep-Alive-Timer, called closeInternal(true)
Keep-Alive-Timer, SEND TLSv1 ALERT: warning, description = close_notify
Keep-Alive-Timer, WRITE: TLSv1 Alert, length = 22
Any idea what should be fixed to disable this Keep-Alive-Timer to close the connection?
After upgrading to cxf 3.1.0 the problem disappeared.
Java 7u9
Error msg in title is: "fatal error: 80: problem unwrapping net record". SO wouldn't let me put "problem" in the title.
I am building a Java HTTPS client against Netty. The SSL handshake was working until I added added the "HTTPS" endpoint identification algorithm to enable server hostname verification:
SSLEngine engine = tcpHelper.getSSLContext().createSSLEngine();
SSLParameters sslParameters = engine.getSSLParameters();
sslParameters.setEndpointIdentificationAlgorithm("HTTPS");
engine.setSSLParameters(sslParameters);
engine.setUseClientMode(true);
After adding the algorithm, the SSL handshake hangs and the connection eventually times out. With SSL debugging enabled (javax.net.debug=all), I can see that the handshake now fails after ServerHello, after the server sends it's cert chain, after
*** ServerHelloDone
1761586552#qtp-1653588482-2, WRITE: TLSv1.2 Handshake, length = 3294
on the server. The client receives and displays the cert chain, and then fails with:
New I/O worker #3, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: Delegated task threw Exception/Error
%% Invalidated: [Session-1, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256]
New I/O worker #3, SEND TLSv1.2 ALERT: fatal, description = internal_error
New I/O worker #3, WRITE: TLSv1.2 Alert, length = 2
Java 7u9
First, thanks to Bruno for his help on this related question which lead me to final answer.
Answering my own question. Hard won knowledge.
The solution is to add the host and port of the request target to the constructor when you create the SSL Engine:
SSLEngine engine = tcpHelper.getSSLContext().createSSLEngine(targetHost, targetPort);
Without this, Java will ultimately throw a NullPointerException way down deep in the SSL libs (IPAddressUtil.textToNumericFormatV4), which results in the not-very-helpful error message in the SSL debug output.
I'm trying web sevice security with Java and Glassfish 3.1: I configured an Hello World web service to run on https listener of Glassfish (on port 8181) by setting "Transport Guarantee" of endpoint of web service to CONFIDENTIAL.
After this I edited web service Attributes and I enabled Secure Service with Transport Security (SSL) Mechanism. I'm using a trusted certificate signed by Comodo.
In web service client creation I have no errors, but when I launch my test application, I get this error:
%% Cached client session: [Session-1, TLS_DHE_RSA_WITH_AES_128_CBC_SHA]
main, WRITE: TLSv1 Application Data, length = 320
main, WRITE: TLSv1 Application Data, length = 32
main, WRITE: TLSv1 Application Data, length = 1328
main, READ: TLSv1 Application Data, length = 768
main, READ: TLSv1 Application Data, length = 32
main, READ: TLSv1 Application Data, length = 320
main, READ: TLSv1 Application Data, length = 32
main, READ: TLSv1 Application Data, length = 32
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 32
main, called closeSocket(selfInitiated)
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Invalid Security Header
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.helloWorld(Unknown Source)
at wss_test.WSS_Test.helloWorld(WSS_Test.java:31)
at wss_test.WSS_Test.main(WSS_Test.java:19)
Java Result: 1
I tried to manage urls and certificate but the result doesn't change. Which is my error? How can I resolve my issue?
Thanks in advance.
Mephysto