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.
Related
Starting which version of mssql-jdbc- jre8 is TLS 1.2 supported? Is a special configuration needed to use TLS 1.2? or it works out of the box)MSSQL server is set up to accept only TLS 1.2 connections)?
Starting which version of mssql-jdbc- jre8 is TLS 1.2 supported?
Java 8 supports TLS1.0 through TLS1.2, and TLS1.2 is the default; see Transport Level Security (TLS) and Java. The MSSQL JDBC drivers will use the JVM's SSL libraries.
Is a special configuration needed to use TLS 1.2?
No. Not on the client side.
or it works out of the box.
Yes.
MSSQL server is set up to accept only TLS 1.2 connections?
That would depend on how the database server itself is configured. According to "TLS 1.2 support for Microsoft SQL Server", SQL Server 2016 supports TLS 1.0 through 1.2, but you can configure it to disable versions that you don't want.
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.
Setting up the context:
In java 8 (precisely 8b98), in order to deal with Client-Initiated Renegotiation causing vulnerability to Denial of Service attack, an un-documented flag was rolled out named jdk.tls.rejectClientInitiatedRenegotiation as a part of Transport Layer Security which could disable client initiated renegotiations.
jdk.tls.rejectClientInitiatedRenegotiation = true
Server which i'm using is JBoss 7.1.1 which supports 7. However java 8 supporting servers are JBoss EAP & Wildfly. I'm reluctant to switch to these new server.
Now My challenge is to implement this property somehow in Java 7. Any sort of guidance will be highly appreciated.
Indeed Java 7 doesn't support this option. Maybe an acceptable behavior could be the Interoperable mode as in Description of Phase 2 Fix of the JSSE 7, which means enabling renegotiation for "good" clients ?
My exact answer is to switch to OpenSSL implementation, particularly the one with the hard-coded renegotiation denial, then you get rid of the JSSE implementation which doesn't support your hard-to-find option.
First, you need OpenSSL 0.9.8l which just denies all client renegotiations.
After that enable the Native Connectors on JBOSS 7.1 and configure as said in this documentation.
web archive links :
http://web.archive.org/web/20201019212829/https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html
http://web.archive.org/web/20201027040002/https://www.openssl.org/news/secadv/20091111.txt
http://web.archive.org/web/20201123225554/https://docs.jboss.org/author/display/AS71/Admin%20Guide.html
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
Using jtds 1.2.5 I have this error when I stablish a connection: "No message resource found for message property prop.sokeepalive"
At first, I was using 1.2.2 version but I have this error message. "Error getting jdbc connection: The USE database statement failed because the database collation Serbian_Latin_100_CI_AS is not recognized by older client drivers. Try upgrading the client operating system or applying a service update to the database client software, or use a different collation. See SQL Server Books Online for more information on changing collations."
As solution, I tried to use 1.2.5 version getting the error mentioned at the beggining.
I was looking for hints in jtds documentation, but I can not resolve the problem.
any ideas?
Thanks in advance.
Try running client JVM with -Duser.language=en -Duser.region=US -Duser.country=US options.
This would switch to everywhere-supported US locale.
Maybe this easy solution would be acceptable in your case.
At least, this would reveal if the problem is in lack of i18n messages resource bundle for current locale in jtds package, as I guess.
Update
Try to just copy jtds.jar/net/sourceforge/jtds/jdbc/Messages.properties and add it to classpath or right inside jtds.jar as net/sourceforge/jtds/jdbc/Messages_sr_RS.properties.
Some explaining links:
Message bundle choosing process
net.sourceforge.jtds.jdbc.Messages source
http://www.localeplanet.com/java/sr-RS/
Update 2
Message bundle choosing process should switch to default provided resource anyway.
My second guess is that Messages.properties of jtds package gets eclipsed by some unrelated file with the same name.
Check your classpath.
You should be able to debug net.sourceforge.jtds.jdbc.Messages in order to find what's happening on for sure.
I have tried other jtds versions. from 1.2.2 yo 1.3.1 (recompiled to java 1.6) and all of them has the same error.
"Error getting jdbc connection: The USE database statement failed because the database collation Serbian_Latin_100_CI_AS is not recognized by older client drivers. Try upgrading the client operating system or applying a service update to the database client software, or use a different collation. See SQL Server Books Online for more information on changing collations."
Perhaps jdts does not support this collation.