My java version is 1.6 and connect to a server over ssl using axis 2 stub; all used to work fine. It seems like they did some upgrade (apache2.4) and the ssl handshake doesn't happen anymore. I receive javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake error. Just for testing purpose, I locally installed jdk 8 and tested it works fine. Is there any way to make this work using jdk1.6? It is not possible to upgrade jdk now.
It is hard to tell without more details but I guess that the server either requires a TLS version unsupported by JDK 6 (e.g. TLS 1.1 or TLS 1.2) or uses ciphers which are not supported by JDK 6 yet. Another option might be that the server needs SNI (server name indication) which is not supported by JDK 6. If the problem is any of these things you are unfortunately out of luck with JDK 6.
I suggest you check with SSLLabs to get more details about the problem. They show also compatibility information regarding various JDK versions.
You could try using a 3rd party JCE provider, Bouncy Castle comes into mind:
https://www.bouncycastle.org
Related
The message given is;
Cannot establish a connection to jdbc:sqlserver://HARSHS-PC\SQLEXPRESS;databaseName=mydb1 using com.microsoft.sqlserver.jdbc.SQLServerDriver
(The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.
Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]". ClientConnectionId:d7ef2454-53af-4f3c-995e-00c75b4d3f39)
How can I establish the connection?
What can be the possible solutions?
Your SQL server only offers TLS1.0 which is most likely disabled in your jre for security reasons.
I'd suggest that you upgrade your SQL Server to the most recent TLS version which is as of today TLS1.3 or at least to TLS1.2.
Another possibility (I would not recommend) would be to modify your java.security which is part of your java jre distribution. To reenable TLS1.0.
On October 19th, I upgraded to OpenJDK Java 1.8.0_232 and my Java processes started failing to connect to a service fronted by stunnel using an EC server certificate. I have an EC client certificate that I would present to the server if the initial handshake would succeed, but it's not getting that far.
I was unable to obtain the version number of the previous version of Java that was running -- I had a long-running process on the client that was able to connect to the service successfully. Java has been upgraded but that client hadn't been restarted since the upgrade. I restarted the client and it, too, began to fail.
I'm about to start reading the announcement to see if there is anything in there that would suggest a "fix" to something, but I believe I have everything configured correctly on both client and server. My current thinking is that this is a bug in the JVM.
Using ssltest, I have been able to confirm that I can handshake with the server using multiple cipher suites when providing the correct client certificate, as long as I use Java 1.8.0_181 or Java 11.0.3 (these are the two versions I happened to have laying around on my laptop for testing). Using the same files, command-line, etc. fails when using Java 1.8.0_232.
Has anyone seen anything like this?
UPDATE
I have downloaded x86-64 OpenJDK versions 8u222 and 8u232 from here and I can confirm that version 8u222 will connect and 8u232 will not connect.
UPDATE
Downgrading to the previous version of OpenJDK has solved my problem for the time being. I'm using Debian Stretch, and I was able to downgrade with this command:
$ sudo apt-get install openjdk-8-jdk-headless=8u222-b10-1~deb9u1 openjdk-8-jre-headless=8u222-b10-1~deb9u1
Note that I only have the "headless" packages installed, so I only downgraded the "headless" packages.
UPDATE
I can confirm that the client certificate is a red herring, here. I relaxed the requirements on my server to not require the client certificate and the initial TLS handshake still fails. I'm trying to narrow this down to the simplest test case I can get.
UPDATE
Still trying to diagnose the problem, here. I have a test server where I can launch it under various configurations and see what happens. I have determined that while Java 8u222 supports the secp256k1 curve, Java 8u232 does not, and I get the handshake failure.
The secp256k1 curve has been disabled with jdk 8u232 (see https://java.com/en/download/faq/release_changes.xml). It can be re-enabled with the java system property jdk.tls.namedGroups.
The example on the faq lists a few other Obsolete NIST EC Curves that are disabled as well. The curves listed there are sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 and secp256k1. The system property jdk.tls.namedGroups takes a comma separated list of those names.
I'm currently migrating some server software from Java 8 to Java 11. Everything works fine except for the fact that TLS connections are refused when my server runs on Java 11 (and only 11). I.e., everything works when running on up to and including Java 10. As soon as I switch to Java 11 (with absolutely no code changes inbetween, of course) I get a TLS decrypt error. My application works fine otherwise when I disable SSL/TLS or when I use IE/Edge to connect to my server (via TLS). When using Chrome 70 or Firefox 62 I get ERR_SSL_PROTOCOL_ERROR or SEC_ERROR_BAD_SIGNATURE, respectively.
I tried to analyze this using WireShark (see my dump). My conclusion is that Java 11 and Chrome/Firefox negotiate a bad cipher suite (rsa_pss_rsae_sha256), which somehow doesn't work with Java 11. Java 8 and IE/Edge seem to negotiate a different cipher suite (rsa_pkcs1_sha256), which works.
Does someone know how to fix this problem or at least work around it for the moment (other than disabling SSL/TLS or using IE/Edge, of course)? Thanks in advance.
This is likely to be a compatibility failure with the new PSS algorithms in TLS 1.3. You can read a good explanation for the reasoning behind the introduction of PSS here.
Until it's fixed you can prevent your server from negotiating TLS 1.3 by editing lib/security/java.security and adding TLSv1.3 to the jdk.tls.disabledAlgorithms property.
There is a simple scan call going to dynamo from my code which works fine in Java 6 and not in Java 7. The amazon forums mention this problem and recommend disabling certificate verification, which seems risky to me. Does anyone know what changed between Java 6 & 7 to cause this issue?
3-Jul-2012 3:51:27 PM com.amazonaws.http.AmazonHttpClient executeHelper
WARNING: Unable to execute HTTP request: peer not authenticated
If it works with one JRE and not another, the problem is likely that you don't have the correct CA cert installed in your 1.7 JRE keystore. See this post for details:
http://welocally.com/?p=1358
You can also just connect to the http:// version of the Dynamo endpoint and so avoid ssl altogether (and get a nice performance boost as a result).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0
My J2SE app uses HttpsUrlConnection to access a secure location. It used to work just fine until I updated my JRE to 1.7. Now I get the "Remote host closed connection during handshake" SSLException. After running the app using -Djavax.net.debug=ssl:handshake, both under JRE 1.6 and JRE 1.7, my impression is that under 1.7 the cached client session fails to resume.
UPDATE:
I have come to understand that under JRE 1.6 my client app uses SSLv2Hello encapsulation. However it does not do that under JRE 1.7, which is most probably what causes the exception. My question is now this: how do I enable SSLv2Hello encapsulation for clients running on JRE 1.7?
UPDATE #2:
SSLv2Hello accomplished on JRE 7 via System.setProperty("https.protocols", "TLSv1,SSLv2Hello"). However this didn't make the handshake exception go away. Turns out that the true reason for the exception is the cipher suite. On JRE 6 the server picks SSL_RSA_WITH_RC4_128_MD5 out of the client's options, while on JRE 7 it always goes with TLS_DHE_RSA_WITH_AES_128_CBC_SHA. For some reason the server can't resume cached sessions using TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Problem patched using System.setProperty("https.cipherSuites", suggestedCipherSuites) where suggestedCipherSuites always starts with SSL_RSA_WITH_RC4_128_MD5. Any downsides with this approach?
UPDATE #3:
The SNI extension of the client is what bothers the server. See "Server Name Indication (SNI) for JSSE client" at http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements7.html
In the end it turns out that the problem was related to the SNI extension in the JSSE client 1.7.
The solution is to disable sending SNI records, before any access to an https location:
System.setProperty ("jsse.enableSNIExtension", "false");
Many thanks to eckes for his solution (see SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0).