Develop Reference

SSLHandshakeException: Received fatal alert: handshake_failure - 2Way SSL

I wrote an Http Client using Apache HttpClient 4.1.13 which call a remote HTTP service using 2way-ssl.
I configured:
keystore.jks : contains the private key and the client certificate
keystore password: the password of keystore.jks
truststore.jks: contains the certificate of CA e intermediate CA of the server
truststore password: the password of truststore.jks
the code:
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
FileInputStream instream = new FileInputStream(new File(keystore));
try {
keyStore.load(instream, keyStorePassword.toCharArray());
} finally {
instream.close();
}
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
instream = new FileInputStream(new File(trustore));
try {
trustStore.load(instream, trustorePassword.toCharArray());
} finally {
instream.close();
}
SSLContext sslContext = SSLContexts.custom()
.loadKeyMaterial(keyStore, keyStorePassword.toCharArray())
.loadTrustMaterial(trustStore, new TrustSelfSignedStrategy())
.build();
SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(
sslContext,
new String[] {"TLSv1.1","TLSv1.2"},
null,
SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
poolingConnManager = new PoolingHttpClientConnectionManager(
RegistryBuilder.<ConnectionSocketFactory>create()
.register("http", PlainConnectionSocketFactory.INSTANCE)
.register("https", sslsf)
.build());
If I run a java main (JDK Java(TM) SE Runtime Environment (build 1.8.0_231-b11) which does the call, I got a successful connection and I see in the logs
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - Secure session established
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - negotiated protocol: TLSv1.2
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - peer principal: XXXXX
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - peer alternative names: [YYYYY]
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - issuer principal: XXXXX
If I run the same code with the same keystores and passwords in Docker OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)) I got the following handshake error
http-nio-8080-exec-1, READ: TLSv1.2 Alert, length = 2
http-nio-8080-exec-1, RECV TLSv1.2 ALERT: fatal, handshake_failure
%% Invalidated: [Session-1, SSL_NULL_WITH_NULL_NULL]
%% Invalidated: [Session-2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
http-nio-8080-exec-1, called closeSocket()
http-nio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
[2022-01-25 16:47:45][SESSION_NOT_INITIALIZED][10.60.168.202][http-nio-8080-exec-1] [DEBUG]o.a.h.i.c.DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown connection
[2022-01-25 16:47:45][SESSION_NOT_INITIALIZED][10.60.168.202][http-nio-8080-exec-1] [DEBUG]o.a.h.impl.execchain.MainClientExec - Connection discarded
What should I search ? Any hints?
UPDATE:
The keystore contains the private key and the certificate chain : certificate -> intermediate CA -> Root CA; I don't understand why the client doesn't find the right certificate to send to the server.
In the working test I got this log
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
matching alias: 1
*** Certificate chain
In the failed test I got:
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain

It was my mistake and the problem was in totally different point.
The above code was right.

IBM java 6 Attempting to Connect SQL Server 2012 using TLS1.2

I am having a problem connecting to SQL Server 2012 using TLS1.2. Below is the code,network trace and output from NMap. From the trace and Nmap output I think it looks like there is a cipher problem but I am not sure. The trace tells me the handshake starts with TLS 1.2 but then the connection gets closed and don't know why. If it is a cipher problem, how does the handshake determine which cipher to use and where are the possible ciphers stored?
Using: IBM Java 6, SQL Server 2012, sqljdbc4.jar
Thanks
public static void doConnect2()
{
try
{
System.setProperty("javax.net.debug", "all");
System.setProperty("javax.net.debug","ssl:handshake:verbose");
System.setProperty("com.ibm.jsse2.overrideDefaultTLS","true");
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver").newInstance();
Connection conn = DriverManager.getConnection(
"jdbc:sqlserver://MIMV-DBTE02;databaseName=CMS",
"userid",
"password");
}
catch(Exception e)
{
System.out.println(e.getMessage());
}
}
Network Trace:
IBMJSSE2 will not allow protocol SSLv3 per com.ibm.jsse2.disableSSLv3 set to TRUE or default
IBMJSSEProvider2 Build-Level: -20171020
IBMJSSE2 will set SSLContext per com.ibm.jsse2.overrideDefaultTLS set to true
Installed Providers =
IBMPKCS11Impl
IBMJCE
IBMJSSE2
IBMJGSSProvider
IBMCertPath
IBMCMSProvider
IBMSPNEGO
IBMSASL
IBMXMLCRYPTO
IBMXMLEnc
Policy
keyStore is: C:\IBM\WebSphere85\AppServer\java\jre\lib\security\cacerts
keyStore type is: jks
keyStore provider is:
init keystore
SSLContextImpl: Using X509ExtendedKeyManager com.ibm.jsse2.id
SSLContextImpl: Using X509TrustManager com.microsoft.sqlserver.jdbc.TDSChannel$PermissiveX509TrustManager
JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
trigger seeding of SecureRandom
done seeding SecureRandom
IBMJSSE2 will enable CBC protection
IBMJSSE2 to send SCSV Cipher Suite on initial ClientHello
JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
jdk.tls.client.protocols is defined as null
SSLv3 protocol was requested but was not enabled
SSLv3 protocol was requested but was not enabled
SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]
SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set to none or default
IBMJSSE2 will not require renegotiation indicator during initial handshake per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default taken
IBMJSSE2 will not perform identity checking against the peer cert check during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check set to OFF or default
IBMJSSE2 will not allow unsafe server certificate change during renegotiation per jdk.tls.allowUnsafeServerCertChange set to FALSE or default
Is initial handshake: true
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1505038140 bytes = { 3, 147, 184, 179, 43, 30, 167, 241, 216, 122, 188, 126, 82, 179, 249, 106, 59, 94, 84, 130, 211, 236, 170, 210, 180, 91, 234, 57 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RENEGO_PROTECTION_REQUEST]
Compression Methods: { 0 }
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA256withDSA, SHA1withDSA, MD5withRSA
***
main, WRITE: TLSv1.2 Handshake, length = 101
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket(selfInitiated)
main, waiting for close_notify or alert: state 5
main, received EOFException: ignored
main, called closeInternal(false)
main, close invoked again; state = 5
main, handling exception: java.io.IOException: SQL Server did not return a response. The connection has been closed. ClientConnectionId:8d6d75fb-67d7-4114-9f62-cd6886be0557
main, SEND TLSv1 ALERT: fatal, description = unexpected_message
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Mar 23, 2018 10:29:17 AM com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
INFO: java.security path: C:\IBM\WebSphere85\AppServer\java\jre\lib\security
Security providers: [IBMPKCS11Impl version 1.6, IBMJCE version 1.2, IBMJSSE2 version 1.6, IBMJGSSProvider version 1.6, IBMCertPath version 1.1, IBMCMSProvider version 59.0, IBMSPNEGO version 1.0, IBMSASL version 1.5, IBMXMLCRYPTO version 1.0, IBMXMLEnc version 1.0, Policy version 1.0]
SSLContext provider info: IBM JSSE provider2 (implements IbmX509 key/trust factories, SSLv3, TLSv1)
SSLContext provider services:
[Provider IBMJSSE2 Service SSLContext.SSL com.ibm.jsse2.uc
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.SSL_TLSv2 com.ibm.jsse2.wc
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1 com.ibm.jsse2.zc
Aliases []
Attributes {}, Provider IBMJSSE2 Service KeyManagerFactory.NewIbmX509 com.ibm.jsse2.rc$b_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.SSL_TLS com.ibm.jsse2.vc
Aliases []
Attributes {}, Provider IBMJSSE2 Service TrustManagerFactory.IbmX509 com.ibm.jsse2.fd$b_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1.1 com.ibm.jsse2.ad
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLS com.ibm.jsse2.yc
Aliases []
Attributes {}, Provider IBMJSSE2 Service KeyManagerFactory.IbmX509 com.ibm.jsse2.rc$a_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1.2 com.ibm.jsse2.bd
Aliases []
Attributes {}, Provider IBMJSSE2 Service TrustManagerFactory.PKIX com.ibm.jsse2.fd$a_
Aliases [IbmPKIX, X509, X.509]
Attributes {}, Provider IBMJSSE2 Service SSLContext.Default com.ibm.jsse2.tc
Aliases []
Attributes {}]
java.ext.dirs: C:\IBM\WebSphere85\AppServer\java\jre\lib\ext
NMap:
1433/tcp open ms-sql-s
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Weak certificate signature: SHA1
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Weak certificate signature: SHA1
|_ least strength: A

OpenJDK 8 (1.8.0_151) in Docker HTTPS connection issue to IIS server

I'am trying to invoke SOAP service, hosted on IIS server (version unknown) from java application inside Docker container. Added CE certificate to JDK cert store. Also there is a proxy server in our corporate network. IIS server located in private network, so I added JDK proxy CLI parameters to go through proxy to internet and bypass proxy for private network. Communication with internet over HTTPS is fine, but invoking IIS server I always receive such error:
Telegram Executor, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 179, 239, 20, 68, 62, 114, 149, 9, 213, 8, 166, 3 }
***
Telegram Executor, WRITE: TLSv1.2 Handshake, length = 40
Telegram Executor, READ: TLSv1.2 Change Cipher Spec, length = 1
Telegram Executor, READ: TLSv1.2 Handshake, length = 40
*** Finished
verify_data: { 188, 169, 41, 148, 80, 6, 90, 100, 144, 226, 166, 42 }
***
%% Cached client session: [Session-6, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
Telegram Executor, WRITE: TLSv1.2 Application Data, length = 676
Telegram Executor, WRITE: TLSv1.2 Application Data, length = 772
Telegram Executor, handling exception: java.net.SocketException: Connection reset
%% Invalidated: [Session-6, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
Telegram Executor, SEND TLSv1.2 ALERT: fatal, description = unexpected_message
Telegram Executor, WRITE: TLSv1.2 Alert, length = 26
Telegram Executor, Exception sending alert: java.net.SocketException: Broken pipe (Write failed)
Telegram Executor, called closeSocket()
Telegram Executor, called close()
Telegram Executor, called closeInternal(true)
Mar 19, 2018 9:26:13 AM org.telegram.telegrambots.logging.BotLogger severe
SEVERE: BOTSESSION
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:195)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:226)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:217)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:124)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
at com.sun.proxy.$Proxy46.getUserInfo(Unknown Source)
at isd.bot.commands.TimeClockSecureCommand.timeClockLoginHandler(TimeClockSecureCommand.java:89)
at isd.bot.commands.TimeClockSecureCommand.execute(TimeClockSecureCommand.java:59)
at isd.bot.DefaultUpdateHandler.accept(DefaultUpdateHandler.java:49)
at isd.bot.DefaultUpdateHandler.accept(DefaultUpdateHandler.java:16)
at isd.bot.IsdTelegramLongPollingBotImpl.onUpdateReceived(IsdTelegramLongPollingBotImpl.java:43)
at java.util.ArrayList.forEach(ArrayList.java:1255)
at org.telegram.telegrambots.generics.LongPollingBot.onUpdatesReceived(LongPollingBot.java:27)
at org.telegram.telegrambots.updatesreceivers.DefaultBotSession$HandlerThread.run(DefaultBotSession.java:311)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:706)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:191)
... 22 more
The same service works fine from .NET application.
Could you please advice what can be the problem?
Java side code:
ITimeClockServer service = new TimeClockServer().getWSHttpBindingITimeClockServer();
((BindingProvider)result).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, BotProperties.getInstance().getTimeClockEndpoint());
((BindingProvider)result).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, BotProperties.getInstance().getUserLogin());
((BindingProvider)result).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, BotProperties.getInstance().getUserPassword());
TimeClockUserInfo userInfo = service.getUserInfo(login);

Thread-6, RECV TLSv1 ALERT: fatal, handshake_failure

what is wrong with this code, it is supposed to trust all hosts, but it doesn't..
It works fine with for example google.com but not with an API Gateway service running locally on my machine, why?
SSL DEBUG OUTPUT
trigger seeding of SecureRandom done seeding SecureRandom Ignoring
unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 ...
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false Allow legacy hello messages: true Is
initial handshake: true Is secure renegotiation: false Thread-6,
setSoTimeout(0) called %% No cached client session
*** ClientHello, TLSv1 RandomCookie: GMT: 1434280256 bytes = { 216 ... 40 } Session ID: {} Cipher Suites:
[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, ....
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1 .. secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Thread-6, WRITE: TLSv1 Handshake, length = 163 Thread-6, READ: TLSv1
Alert, length = 2 Thread-6, RECV TLSv1 ALERT: fatal,
handshake_failure Thread-6, called closeSocket() Thread-6, handling
exception: javax.net.ssl.SSLHandshakeException: **
Received fatal alert: handshake_failure
**
import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URL;
import java.net.URLConnection;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.security.cert.X509Certificate;
public class ConnectHttps {
public static void main(String[] args) throws Exception {
/*
* fix for
* Exception in thread "main" javax.net.ssl.SSLHandshakeException:
* sun.security.validator.ValidatorException:
* PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
* unable to find valid certification path to requested target
*/
TrustManager[] trustAllCerts = [
[ getAcceptedIssuers: { -> null },
checkClientTrusted: { X509Certificate[] certs, String authType -> },
checkServerTrusted: { X509Certificate[] certs, String authType -> } ] as X509TrustManager
]
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
// Create all-trusting host name verifier
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
// Install the all-trusting host verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
/*
* end of the fix
*/
//URL url = new URL("https://google.com"); //WORKS
URL url = new URL("https://localhost:8090"); // DOES NOT WORK, WHY?
URLConnection con = url.openConnection();
Reader reader = new InputStreamReader(con.getInputStream());
while (true) {
int ch = reader.read();
if (ch==-1) {
break;
}
System.out.print((char)ch);
}
}
}
Running the code found here it shows that TLSv1.2 is not enabled on the client side:
Supported Protocols: 5
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2
Enabled Protocols: 2
SSLv3
TLSv1

.. it is supposed to trust all hosts, but it doesn't..
.. RECV TLSv1 ALERT: fatal, handshake_failure Thread-6
A handshake failure alert from the server is unrelated to the validation of the servers certificate on the client and can thus not stopped by disabling certificate validation. Lots of things can cause such a failure, like no common ciphers, unsupported protocol version, missing SNI extension (only supported starting with JDK7). Since the error is issued by the server you might find more details about the problem in the servers log messages.
EDIT: from the server logs the cause of the problem is visible:
error handling connection: SSL protocol error error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
This means that there is no common cipher between client and server.
A typical cause for this is a wrong setup of the certificates at the server. If you don't configure any certificates the server might require anonymous authentication with ADH ciphers, which are usually not enabled on the client side. I suggest that you check if you could connect with a browser.
Another common misconfiguration is disabling all SSLv3 ciphers at the server in the believe that this is necessary to disable the SSL3.0 protocol (it is not). This effectively disables all ciphers except some new ciphers introduced with TLS 1.2. Modern browsers will be still able to connect but older clients not. This misconfiguration can be seen in this case (from the comment):
From server log,, interface ciphers: FIPS:!SSLv3:!aNULL,,
!SSLv3 disables all ciphers available for version SSL3.0 and higher. This in effect leaves only the TLS1.2 ciphers because there are no new ciphers with TLS1.0 and TLS1.1. Since the client seems to be only support TLS1.0 there will be no shared ciphers:
...WRITE: TLSv1 Handshake
Use of !SSLv3 in the ciphers is usually caused by a lack of understanding of the difference between protocol version and ciphers. To disable SSLv3 you should only set the protocol accordingly but not the ciphers.

Connection refused after SSL handshake

I'm trying to connect to a WCF server that needs a client cert. I've imported the client cert into a JKS file locally and provided the cert location to the JAXWS client using the -Djavax.net.ssl*** options. The SSL debug prints the below information before it finally gets a Connection refused exception. Apparently the handshake seems to successful but then a closeInternal(true) is called and then the exception. Any clues/ideas are much appreciated. Thanks in advance.
... no IV used for this cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 17
*** Finished
verify_data: { 68, 26, 22, 198, 55, 196, 10, 167, 6, 30, 206, 143 }
***
main, WRITE: TLSv1 Handshake, length = 32
main, READ: TLSv1 Change Cipher Spec, length = 17
main, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data: { 233, 31, 138, 146, 138, 210, 137, 249, 81, 126, 169, 166 }
***
%% Cached client session: [Session-3, SSL_RSA_WITH_RC4_128_MD5]
main, READ: TLSv1 Application Data, length = 469
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 18
Exception in thread "main" com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.net.ConnectException: Connection refused: connect
java.net.ConnectException: Connection refused: connect
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:161)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:133)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.acs.echo.gen.EchoService.<init>(EchoService.java:46)
at com.acs.echo.client.EchoClient.invokeWebService(EchoClient.java:43)
at com.acs.echo.client.EchoClient.main(EchoClient.java:17)

The SSL handshake and TCP connection to the server are succeeding, but the retrieval of the WSDL is failing. It appears to be coming from a non-SSL host that is giving you 'connection refused', which means that nothing is listened at the port specified in the WSDL RL, or maybe an intervening firewall has vetoed the connect attempt.