Develop Reference

Getting SSLHandshake Exception between two Websphere Servers

There are 2 Websphere servers. First is Client and Second is Server (8.5.5.13).
An End-User makes a SOAP request to Client. Client receives the request, do some processing and then makes a REST request to the Server.
When the Server receives the request from Client it throws the below exception.
ERROR 22304 --- [ebContainer : 2]
c.i.w.s.c.impl.SSLHandshakeErrorTracker : SSLC0008E: Unable to
initialize SSL connection. Unauthorized access was denied or security
settings have expired. Exception is
javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1
not enabled or not supported
We have tested after enabling TLSv1.2 and then TLSv1 at the our Server level. We have exported the certificate from the Server and added in the Client trust store as well. But still we are not able to resolve the error.
Questions:
1. Do we need to keep the same TLS version at our Server which is present in the Client WebSphere?
2. We have deployed our application is java7. Is it due to Java version we are facing the issue?
3. Is it due to Certificate only, or something else?
When we disable the Global security at our Server then the request is processing correctly.

This error was due to the TLS version incompitability at Server. The client was sending the request using TLSv1 and server has TLSv1.2 enabled in it. For SSL handshake, the first thing is TLS compitability. The client and server should have same TLS versions.
After this if you are using one way SSL handshake, then the certificate from the server machine needs to extract and the same should be installed in the Client machine. This way SSL Handshake will happen.

TLSv1 support in embedded Jetty server

I am running embedded Jetty server with https/TLS enabled on it. It works perfectly with all modern browsers (TLSv1.2).
We have a legacy browser (.exe whose code cannot be changed/checked) which we are trying to connect to Jetty server over https, which is failing.
I debugged SSL on jetty side and came to know that this browser is connecting using TLSv1, so I did the following:
sslContextFactory.setIncludeProtocols( "TLSv1");
After this, I started getting error "no cipher suits in common" on server side. To pass this (I know this is dangeropus, but still for now), I did:
sslContextFactory.setExcludeCipherSuites();
After doing this, I don't see any error on server side, but still legacy browser is unable to connect. (It can connect to other https site though as facebook, google).
Server side logs after above change:
WRITE: TLSv1 Handshake, length = 48
called closeOutbound()
closeOutboundInternal()
SEND TLSv1 ALERT:
warning,
close_notify
WRITE: TLSv1 Alert, length = 32
Any idea what can be wrong here? I tried to do a lot of googling on it but cannot work it through. I also tried enabling SNI on server, but with no luck.
Any help would be very appreciated.
Thanks
edit1:
If I compare Jetty SSL logs with working request, I see below difference. Working request is sending application data also as below:
WRITE: TLSv1 Application Data, length = 1285
In non-working request, I see below additional line (TLS_RSA_WITH_AES_128_CBC_SHA is cipher suite name):
Cached server session: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]

There is an issue with Jetty 9.4.*
https://github.com/eclipse/jetty.project/issues/3773
https://github.com/eclipse/jetty.project/issues/2807
which blindly excludes TLS1.0 and TLS1.1.
The fix
is (a) to call setExcludeCipherSuites() after SslContextFactory is contructed as mentioned above,
or (b) just override SslContextFactory.setExcludeCipherSuites(final String... cipherSuites) to do nothing, as below:
final SslContextFactory sslContextFactory = new SslContextFactory()
{
#Override
public void setExcludeCipherSuites(final String... cipherSuites)
{
// do nothing intentionally.
}
};

HandShake Exception while connecting through rest with certificate

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)

SSL Handshake Error using Java

I am trying to connect a java client with a JMX server using SSL certificate.
But unfortunately this connection gives a SSL Handshake error. When I tried to debug this, using -Djavax.net.debug=all flag, I get the following error message on the java client.
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], READ: TLSv1.2 Alert, length = 2
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], RECV TLSv1 ALERT: fatal, handshake_failure
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], called closeSocket()
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
When I change the client to something else, like a JConsole, the connection works fine using the same SSL certificate and the truststore, which indicates that there is nothing wrong with the SSL certificate or the domain its connecting to.

It seems that the handshake was failing due to incorrect TLS version types.
My client was running on Java7 which was using TLS version 1, while the server was running Java8 which was using TLS version 1.2.
Check this oracle blog, which mentions that Java8 will default use TLS version 1.2
So, when I upgraded my client to use Java8, the issue got resolved.
Hope, this helps someone else as well.

Java SSL: "fatal error: 80: ... unwrapping net record" after adding the HTTPS EndpointIdentificationAlgorithm

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.