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.
Related
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.
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
I have strange problem, that I could not fixed.
I have JDK 1.5 version and SSL based communication via sockets, simply send and receive string data.
try {
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(
"path_to_.jks"),
"secret_of_jks".toCharArray());
TrustManagerFactory tmf = TrustManagerFactory
.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ks);
KeyManagerFactory kmf = KeyManagerFactory
.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, "secret_of_jks".toCharArray());
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
Socket s = ctx.getSocketFactory().createSocket("address_of_server", PORT);
String jsonEx = "json text to send server";
StringBuilder sb = new StringBuilder();
sb.append(jsonEx.getBytes().length);
sb.append("\r\n");
sb.append(jsonEx);
PrintWriter writer = new PrintWriter(s.getOutputStream(), true);
writer.println(sb.toString());
BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
System.out.println(in.readLine());
writer.flush();
} catch (Exception e) {
e.printStackTrace();
}
When I use JDK 1.7+ everything works properly, but when I switch into 1.6- it throws javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
My certificates are 2048 encrypted and I also installed JCE Unlimited Strength Jurisdiction Policy
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
Here is full exception if some is interested:
javax.net.ssl.SSLException: Connection has been shutdown:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1154)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:65)
at
sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at
sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at
java.io.InputStreamReader.read(InputStreamReader.java:167) at
java.io.BufferedReader.fill(BufferedReader.java:136) at
java.io.BufferedReader.readLine(BufferedReader.java:299) at
java.io.BufferedReader.readLine(BufferedReader.java:362) at
ConnectorTest.main(ConnectorTest.java:45) Caused by:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:739)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:619)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at
java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at
java.io.BufferedWriter.flush(BufferedWriter.java:236) at
java.io.PrintWriter.newLine(PrintWriter.java:410) at
java.io.PrintWriter.println(PrintWriter.java:559) at
java.io.PrintWriter.println(PrintWriter.java:670) at
ConnectorTest.main(ConnectorTest.java:43) Caused by:
java.io.EOFException: SSL peer shut down incorrectly at
com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:321)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720)
... 13 more
ConnectorTest Line 43 is
System.out.println(in.readLine());
Updated
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1439443814 bytes = { 228, 36, 73, 128, 109, 225, 11, 36, 62, 40, 147, 150, 27, 145, 150, 163, 244, 28, 97, 56, 188, 81, 117, 31, 235, 60, 101, 224 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_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_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Update 2
I just found out that, difference between them are:
Valid from Tue Feb 16 20:07:36 GET 2016 until Thu Feb 16 20:07:36 GET
2017 1.7 Correct
Valid from Tue Feb 16 16:07:36 GMT 2016 until Thu Feb 16 16:07:36 GMT
2017 1.6 Error
After a lot of research, I found out that, there is no way to do this and of course, installing the unlimited policy is also ugly solution. Sun does not recommend us changing policy. The best way to solve that problem is, that always maintain your Java version better then this one. I had to write on 1.5 and had no other chance to simply upgrade system and decided worse but the only solution, that worked, of course. I created some kind of proxy service with Java 1.8 + Wildlfy 8.2 on the same machine with different port of Jboss and call services from there. 1.5 and 1.8 apps communicate with simple soap protocol. Problem "fixed".
Could be that the server does not support the SSL version of the client (client is offering too low SSL version).
Try adding the system property "javax.net.debug=ssl" so you get a better error description into system out. For example:
System.setProperty("javax.net.debug", "ssl");
or add command line parameter:
-Djavax.net.debug=ssl
Why would you want to use older Java? If you must use 1.6 try updating it to the latest patch version.
I'm trying to establish a secure socket connection between a Java client applet (built with JDK 1.7.0_75-b13) and a VC++ server application.
As a test vehicle, I used a VC++ client/server sample I found in the MSDN forums, modified it to use SChannel and was able to establish a socket using cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. It works with any of TLS 1.0/1.1/1.2.
When I try opening a socket from the Java applet to the same server application, the connection is rejected with the server reporting the following:
TLS 1.0 AcceptSecurityContext failed: 0x80090327
TLS 1.1 AcceptSecurityContext failed: 0x80090331
TLS 1.2 AcceptSecurityContext failed: 0x80090331
This is the Java code used to create the socket:
debugPrint("Setting up secure connection");
SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("127.0.0.1", socketnumber);
debugPrint("Starting handshake");
sslsocket.setTcpNoDelay(true);
sslsocket.setSoLinger(false, 0);
sslsocket.setKeepAlive(true);
sslsocket.setReuseAddress(true);
sslsocket.setSoTimeout(10000);
sslsocket.setUseClientMode(true);
sslsocket.setWantClientAuth(false);
sslsocket.addHandshakeCompletedListener(new HandshakeCompletedListener()
{
#Override
public void handshakeCompleted(HandshakeCompletedEvent arg0)
{
debugPrint("handshake complete!");
StealthStatus.setServiceConnected(true);
}
});
String cipherSuites[] = sslsocket.getEnabledCipherSuites();
for (int inx=0; inx < cipherSuites.length; inx++)
{
debugPrint("SSL cipher suite supported->" + cipherSuites[inx]);
}
sslsocket.setEnabledCipherSuites(cipherSuites);
sslsocket.startHandshake();
socket = sslsocket;
socketOut = sslsocket.getOutputStream();
socketIn = sslsocket.getInputStream();
Running this, the call to getEnabledCipherSuites returns the list
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
which includes the desired TLS_RSA_WITH_AES_128_CBC_SHA and is passed to setEnabledCipherSuites.
What is needed to get the VC++ server to accept a connection from the Java client?
See: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
In many cases, the log messages generated when using the -Djavax.net.debug=all flag can lead you in the right direction.
I am trying to send push notification to iPhone using Java-pns but I am getting the following error...
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
This is my code...
String token="95076d2846e8979b46efd1884206a590d99d0f3f6139d947635ac4186cdc5942";
String host = "gateway.sandbox.push.apple.com";
int port = 2195;
String payload = "{\"aps\":{\"alert\":\"Message from Java o_O\"}}";
NotificationTest.verifyKeystore("res/myFile.p12", "password", false);
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(getClass().getResourceAsStream("res/myFile.p12"), "password".toCharArray());
KeyManagerFactory keyMgrFactory = KeyManagerFactory.getInstance("SunX509");
keyMgrFactory.init(keyStore, "password".toCharArray());
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(keyMgrFactory.getKeyManagers(), null, null);
SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
SSLSocket sslSocket = (SSLSocket) sslSocketFactory.createSocket(host, port);
String[] cipherSuites = sslSocket.getSupportedCipherSuites();
sslSocket.setEnabledCipherSuites(cipherSuites);
sslSocket.startHandshake();
char[] t = token.toCharArray();
byte[] b = Hex.decodeHex(t);
OutputStream outputstream = sslSocket.getOutputStream();
outputstream.write(0);
outputstream.write(0);
outputstream.write(32);
outputstream.write(b);
outputstream.write(0);
outputstream.write(payload.length());
outputstream.write(payload.getBytes());
outputstream.flush();
outputstream.close();
System.out.println("Message sent .... ");
For NotificationTest.verifyKeystore I am getting that this valid is File and Keystore.
I am not understanding why I am getting this error.
This is my error log...
** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<empty>
[read] MD5 and SHA1 hashes: len = 10
0000: 0D 00 00 06 03 01 02 40 00 00 .......#..
** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
** Certificate chain
**
** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[write] MD5 and SHA1 hashes: len = 269
...
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
I am not understanding why Cert Authorities is empty?
I recommend that you use keytool -list to compare the keystore on the client with those known to the server. The handshake error you are getting is because the Server has done it's hello and is expecting a Client Certificate in reply. You are not sending one. To fix this the PKCS12 certificate should be converted to PEM format (using openssl is one way) and then imported into a keystore using the keytool.
I suspect if you fix this by importing a client certificate into the keystore, then you will hit a second error. The second error will be about the empty CA certs - probably because you don't have a CA cert that is known to your server in your keystore. Import your CA and try again.
Looks like you need to install "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files". This solved the issue for me.
To Send Push Notification to iPhone/ iPad I have used JavaPNS.
It is very easy to use and It worked for me.
We can simply follow This to use it.