Java 8のSQL Server JDBCエラー：ドライバーは、Secure Sockets Layer（SSL）暗号化を使用してSQL Serverへの安全な接続を確立できませんでした
Microsoft JDBCドライバーのバージョンを使用してSQL Serverデータベースに接続すると、次のエラーが表示されます。
com.Microsoft.sqlserver.jdbc.SQLServerException：ドライバーは、Secure Sockets Layer（SSL）暗号化を使用してSQL Serverへの安全な接続を確立できませんでした。エラー：「SQL Serverは不完全な応答を返しました。接続は閉じられました。ClientConnectionId：98d0b6f4-f3ca-4683-939e-7c0a0fca5931」。
最近、アプリケーションをJava 6＆Java 7からJava 8.実行中のすべてのシステムJavaは、SUSE Linux Enterprise Server 11（x86_64）、VERSION = 11、PATCHLEVEL = 3を実行しています。
ここに、私が書いたJavaプログラムで収集した事実を示します。このプログラムは、1,000個のデータベース接続を単に順番に開閉します。
- 接続は、このエラーで約5％〜10％の確率でドロップされます。エラーはすべての接続で発生するわけではありません。
- この問題は、Java 8.でのみ発生します。同じプログラムをJava 7で実行しましたが、問題は再現性がありません。本番環境ではJava 7で実行中に問題は発生していません。
- この問題は、Java 8を実行しているすべてのLinuxサーバーで発生するわけではありません。一部のサーバーでのみ発生します。これは私には困惑していますが、同じバージョンで同じテストプログラムを実行すると、異なるLinuxインスタンス上のLinux JVM（1.8.0_60、64ビット）の場合、問題はLinuxインスタンスの1つでは発生しませんが、他のLinuxインスタンスでは発生します。Linuxインスタンスは同じバージョンのSUSEを実行しており、同じパッチレベルで。
- この問題は、SQL Server 2008とSQL Server 2014の両方のサーバー/データベースに接続するときに発生します。
- この問題は、SQL Server JDBCドライバーの4.0バージョンを使用しているか、ドライバーの新しい4.1バージョンを使用しているかに関係なく発生します。
この点について、ウェブ上の他のものと比較して私の観察をユニークにしているのは、問題はJava 8でのみ発生するが、一見同一のLinuxサーバーの1つで問題を発生させることはできない同じJava 8 JVM。他の人々は、この問題をJavaの以前のバージョンでも見ましたが、それは私たちの経験ではありませんでした。
ご意見、ご提案、またはご意見をお寄せください。
問題を再現するLinuxインスタンスでJava 8 JVMでSSLロギングをオンにしました。SSLロギングは-Djavax.net.debug=ssl:handshake:verbose。これにより、いくつかの有用な情報が明らかになりました。
本番環境で使用しており、動作することが証明されている回避策は、JVMでこのパラメーターを設定することです。
-Djdk.tls.client.protocols=TLSv1
詳細については、お読みください。
問題を再現できるサーバー（再び、5〜10％の時間）で、次のことを確認しました。
*** ClientHello, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 195
main, READ: TLSv1.2 Handshake, length = 1130
*** ServerHello, TLSv1.2
--- 8<-- SNIP -----
%% Initialized: [Session-79, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
*** Diffie-Hellman ServerKeyExchange
--- 8<-- SNIP -----
*** ServerHelloDone
*** ClientKeyExchange, DH
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 133
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 108, 116, 29, 115, 13, 26, 154, 198, 17, 125, 114, 166 }
***
main, WRITE: TLSv1.2 Handshake, length = 40
main, called close()
main, called closeInternal(true)
main, SEND TLSv1.2 ALERT: warning, description = close_notify
main, WRITE: TLSv1.2 Alert, length = 26
main, called closeSocket(true)
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 returned an incomplete response. The connection has been closed. ClientConnectionId:12a722b3-d61d-4ce4-8319-af049a0a4415
TLSv1.2がデータベースサーバーによって選択され、この交換で使用されることに注意してください。問題のあるlinuxサービスからの接続が失敗すると、TLSv1.2が常に選択されたレベルであることに気付きました。ただし、TLSv1.2が使用されている場合、接続は常に失敗しません。失敗するのは5〜10％だけです。
これが問題のないサーバーからの交換です。それ以外はすべて同じです。つまり、同じデータベース、同じバージョンのJVM（Java 1.8.0_60）、同じJDBCドライバーなどに接続します。ここで、TLSv1障害のあるサーバーの場合のように、TLSv1.2の代わりにデータベースサーバーによって選択されます。
*** ClientHello, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 207
main, READ: TLSv1 Handshake, length = 604
*** ServerHello, TLSv1
--- 8<-- SNIP -----
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
%% Initialized: [Session-79, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
***
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
--- 8<-- SNIP -----
main, WRITE: TLSv1 Handshake, length = 134
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 26, 155, 166, 89, 229, 193, 126, 39, 103, 206, 126, 21 }
***
main, WRITE: TLSv1 Handshake, length = 48
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 48
*** Finished
そのため、TLSv1がLinux JVMとSQL Serverの間でネゴシエートされるとき、接続は常に成功します。 TLSv1.2がネゴシエートされると、散発的な接続エラーが発生します。
（注：Java 7（1.7.0_51）は常にTLSv1をネゴシエートするため、Java 7 JVM。
まだ未解決の質問があります：
- 理由は、同じJava 8 2つの異なるLinuxサーバーから実行されるJVMは常にTLSv1をネゴシエートしますが、別のLinuxサーバーから接続するときは常にTLSv1.2をネゴシエートします。
- また、TLSv1.2ネゴシエートされた接続は、そのサーバーですべてではありませんが、ほとんどの時間成功しているのはなぜですか？
2017年6月10日更新：Microsoftからのこの投稿 は、問題と提案された解決策について説明しています。
リソース：
Java 8、JCE無制限強度ポリシーおよびTLS経由のSSLハンドシェイク
http://blogs.msdn.com/b/saponsqlserver/archive/2013/05/10/analyzing-jdbc-connection-issues.aspx
https://docs.Oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#descPhase2
https://blogs.Oracle.com/Java-platform-group/entry/Java_8_will_use_tls
これは、MS SQL JDBCドライバーのバージョン4.2で修正されたようです。サーバーに1000回接続し、試行ごとに100ミリ秒一時停止するプログラムを作成しました。バージョン4.1では、散発的にしか発生しませんでしたが、毎回問題を再現することができました。バージョン4.2では、問題を再現できませんでした。
SQL JDBCドライバーをアップグレードする前に、まず互換性を確認してください。
- Sqljdbc.jarは5のJREを必要とし、JDBC 3.0 APIをサポートします
- Sqljdbc4.jarは6のJREを必要とし、JDBC 4.0 APIをサポートします
- Sqljdbc41.jarは7のJREを必要とし、JDBC 4.1 APIをサポートします
- Sqljdbc42.jarは8のJREを必要とし、JDBC 4.2 APIをサポートします
ソース： https://www.Microsoft.com/en-us/download/details.aspx?id=11774
私の場合、3DES_EDE_CBCアルゴリズムを使用するSQLサーバーがありましたが、これはjdk 1.8ではデフォルトで無効になっているため、
/ライブラリ/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/security/Java.security
そして、以下からアルゴリズムを削除します：
jdk.tls.disabledAlgorithms = SSLv3、RC4、DES、MD5withRSA、DH keySize <1024、\ EC keySize <224、3DES_EDE_CBC、anon、NULL
私のために働いた。
また、Java 7でJDBCドライバー4.0および4.1を使用して、Windows Server 2012 R2でこの問題に遭遇しました。この マイクロソフトの記事 またはJDBCドライバー4.2にアップグレードできない場合は優先順位を下げます
Microsoftは最近、ドライバーをオープンソース化しました。 mssql-jdbc GitHubでのドライバーアクティビティを確認できます。最新のプレビューバージョンは6.1.5だと思います。
また、Mavenでもすべてのプレビューバージョンを見つけることができます。 JDK7とJDK 8の両方をサポートします。
URLは以下のようになり、sql sqljdbc42.jarを追加する必要があります。これで問題が解決します
url = "jdbc:sqlserver://" +serverName + ":1433;DatabaseName=" + dbName + ";encrypt=true;trustServerCertificate=true;