MENU

KB5060531 適用後に SAP Crystal Reports の JDBC で SQL Server 2022 へ接続できない原因と対処法【Windows Server 2019】

Windows Server

2025年6月の累積更新プログラム KB5060531 を適用した Windows Server 2019 で、「Crystal Reports から JDBC だけが SQL Server 2022 に繋がらない」という報告が世界中で上がっています。本記事では、この現象の背景にある TLS（Schannel）強化と、SAP Crystal Reports が抱えがちな「同梱 JRE／古い JDBC ドライバ」の問題を整理しつつ、業務を止めないための回避策と、JDBC を継続利用するための恒久対策を、実務目線で詳しく解説します。

目次

KB5060531 適用後に JDBC から SQL Server 2022 へ接続できない現象とは

まず、今回よく見られる具体的な症状を整理します。

  • 対象 OS：Windows Server 2019（1809）
  • 適用更新：2025 年 6 月 10 日公開のセキュリティ更新 KB5060531（OS ビルド 17763.7434）
  • DB：SQL Server 2022
  • クライアント：SAP Crystal Reports（レポート実行時に JDBC で接続）
  • 更新適用後：
    • JDBC 経由の接続のみ失敗
    • ADO / OLE DB に切り替えると正常に接続できる

エラー メッセージは典型的には次のようなものです（英語 UI の例）：

The driver could not establish a secure connection to SQL Server
by using Secure Sockets Layer (SSL) encryption.
SQL Server did not return a response. The connection has been closed.

同じエラー内容が、Microsoft Q&A やサードパーティの KB まとめサイトでも「KB5060531 適用後に Crystal Reports の JDBC から SQL Server 2022 へ繋がらない」として報告されています。

接続方式ごとの挙動を表にすると、次のようなイメージです。

接続方式プロバイダ／ドライバKB5060531 適用後の挙動コメント
JDBCCrystal 同梱の JRE + JDBC ドライバTLS ハンドシェイクで失敗し接続不可古い TLS / 暗号スイートしか話せないケースが多い
ADO.NET / OLE DB（MSOLEDBSQL など）正常に接続可能Windows の Schannel に合わせて更新されている
ODBCODBC Driver for SQL Server多くの環境で正常同じく OS 側の TLS スタックの恩恵を受ける

KB5060531 と Windows Server 2019 の TLS 強化

KB5060531 は Windows 10 1809 / Windows Server 2019 に対する 2025年6月のセキュリティ更新で、GDI や Windows Hello の修正に加え、各種脆弱性修正を含む累積更新です。

公式の「既知の問題」には主に DHCP サーバーの停止などが挙げられていますが、サードパーティのまとめでは「TLS ハンドシェイク失敗や JDBC での SQL Server 2022 への接続不可」が現場の声として紹介されています。

特に指摘されているのは、次のような TLS / Schannel 周りの挙動です。

  • 弱い暗号スイート（古い RSA キー交換のみのスイートなど）がより強く制限される
  • SHA-1 署名証明書や 2048bit 未満の DH パラメータへの対応が厳格化
  • TLS 1.0 / 1.1 が無効化または事実上利用困難になる構成
  • 再ネゴシエーションや証明書チェーン検証の仕様が現行標準に近付く

Windows Server 2019 自体は TLS 1.3 を持たないため、実質的には「TLS 1.2 を前提としたより強いポリシー」に収れんし、その結果として クライアント側が TLS 1.2 / ECDHE / 現代的な暗号スイートに対応していないと接続できない ケースが顕在化します。

なぜ ADO/OLE DB は成功し、JDBC だけが失敗するのか

同じ SQL Server 2022 に対して、ADO / OLE DB では接続でき、JDBC では失敗する理由は、「どの TLS 実装を使っているか」の違いにあります。

  • ADO / OLE DB / ODBC
    • Windows の TLS スタック（Schannel）をそのまま利用
    • OS 更新とともに暗号スイート・TLS バージョン・証明書検証が更新される
  • JDBC（Java）
    • Java の SSL/TLS 実装（JSSE）を利用
    • 証明書の信頼情報も Java 側の truststore（cacerts）に依存
    • アプリケーションが同梱する独自の JRE を使うことが多く、OS を更新してもそこは自動では更新されない

Crystal Reports のようなツールは、しばしば自身のインストール領域に JRE を同梱しており、システム側の Java を最新化しても Crystal 内部の JRE / JDBC ドライバは古いまま、という構成になりがちです。Microsoft Q&A でも、Crystal が古い JRE と JDBC を同梱していることが根本原因候補として指摘されています。

この前提を踏まえると、現象は次のように整理できます。

レイヤー更新内容結果影響を受けるもの
Windows Server 2019（OS）KB5060531 により Schannel のポリシー強化サーバー側の TLS がより厳しくなるSQL Server 2022 の SSL/TLS エンドポイント
ADO / OLE DB クライアントOS の Schannel を利用サーバーと同じく最新ポリシーでハンドシェイクできるCrystal Reports の ADO 接続など
JDBC クライアント（Crystal 内部 JRE）古い JRE + 古い JDBC ドライバのままTLS 1.2 / ECDHE / GCM などに対応しきれずハンドシェイク失敗SAP Crystal Reports の JDBC 接続

まず実施したい切り分けと確認ポイント

いきなりレジストリや TLS ポリシーをいじる前に、次のような基本的な切り分けを行うと、原因がどこにあるかを明確にできます。

環境情報の確認

  • Windows のビルド：winver で OS ビルドが 17763.7434 になっているか確認
  • 更新履歴：
    「設定 > 更新とセキュリティ > 更新の履歴を表示」から KB5060531 のインストール日を確認
  • SQL Server バージョン：
    SSMS などで SELECT @@VERSION; を実行し、SQL Server 2022 であることを確認
  • Crystal Reports 側：
    • Crystal Reports / BusinessObjects のバージョン
    • JDBC ドライバの種類（Microsoft 純正 or jTDS など）
    • Crystal が利用している JRE のパス（インストール先配下に jre フォルダがないか確認）

「JDBC だけ」が落ちているかを確認

  • 同じ SQL Server 2022 に対して：
    • SSMS（TDS / ネイティブプロトコル）
    • ODBC（ODBC Driver for SQL Server）
    • .NET アプリ（System.Data.SqlClient / Microsoft.Data.SqlClient）
    などから接続を試し、問題なく TLS で繋がるかを確認します。
  • Crystal Reports からは：
    • JDBC 接続：失敗するか
    • ADO / OLE DB 接続：成功するか

JDBC のみが失敗し、他の手段がすべて成功する場合は、ほぼ間違いなく Java 側（Crystal 内部 JRE / JDBC ドライバ）とサーバー側 TLS ポリシーの相性問題 と見て良いでしょう。

ログとイベントの確認

  • Windows イベントログ（サーバー側）
    • [イベント ビューア] → [Windows ログ] → [システム] → ソース Schannel の警告・エラーを確認
    • イベント ID 36874, 36887 などで「ハンドシェイクエラー」「致命的なアラート」が出ていないかを確認
  • SQL Server エラーログ
    • 「A TLS 1.2 connection request was received from a client that does not support the requested cipher suite.」のようなメッセージが出ていないか
  • Java 側の TLS デバッグログ
    • Crystal の起動オプションに -Djavax.net.debug=ssl,handshake を付与し、JDBC 接続時のハンドシェイクログを取得
    • ClientHello でどの TLS バージョン／暗号スイートを投げているかを確認
  • Wireshark などでパケットキャプチャ
    • ClientHello まで進んで ServerHello が返ってこないのか
    • ServerHello までは成功し、その後 Certificate / Alert で落ちているのか

ここまで確認して「Crystal の JDBC だけが TLS ハンドシェイクで落ちている」ことがはっきりしたら、次に紹介する対処方針に進みます。

業務継続のための暫定回避策：ADO / OLE DB に切り替える

まず最優先すべきは「レポート出力という業務を止めないこと」です。根本原因の追及や Java 側の更新には時間がかかるため、短期的には JDBC をいったん諦めて、ADO / OLE DB で接続するのが現実的です。

Crystal Reports 側での典型的な切り替えイメージ

  • データソースの種類を「JDBC」から「OLE DB（ADO）」へ変更
  • プロバイダとして MSOLEDBSQL / MSOLEDBSQL19 など、現行サポートの OLE DB ドライバを選択
  • サーバー名・データベース名・認証方式（Windows / SQL 認証）を再設定

この方法で、Microsoft Q&A の事例でも「JDBC はダメだが、ADO に切り替えたらすぐに復旧した」と報告されています。

もちろん、アプリ側の実装やライセンスポリシーによっては簡単に接続方式を変えられないケースもありますが、Crystal のレポートだけが影響を受けているのであれば、この暫定回避は非常に有効です。

JDBC を継続利用するための恒久対策

「どうしても JDBC（Java）で接続したい」「将来的に Java ベースのアプリケーションを統一したい」といった要件がある場合は、以下の 3 点をひとまとまりの変更セットとして実施することをおすすめします。

  1. Crystal が利用している JRE をサポートされているバージョン（Java 11 以上）に更新
  2. Microsoft JDBC Driver for SQL Server を SQL Server 2022 対応の最新バージョンへ更新
  3. 接続文字列と証明書の信頼設定を、TLS 1.2 / ECDHE 前提で正しく構成

1. Crystal が利用している JRE / JDBC のバージョンを把握する

最初に、Crystal がどの JRE / JDBC ドライバを使っているかを明確にします。

  • Crystal のインストールフォルダ直下に jre フォルダがあるか
  • JDBC ドライバの .jar ファイル（mssql-jdbc-*.jar や jtds-*.jar）がどこに配置されているか
  • JRE のバージョン：bin\java.exe -version を実行して確認

システムの java -version を更新しても、Crystal が使っているのは「インストール先配下の古い JRE」だった、というのは非常にありがちなパターンです。Microsoft Q&A の回答でも、この点が強く注意喚起されています。

2. JRE を Java 11 以上に更新する

次に、Crystal が参照する JRE を、サポート対象の LTS バージョン（Java 11 以上）に更新します。

  • 利用中の Crystal バージョンが公式に対応している JRE バージョンを、SAP のサポートノートや製品ドキュメントで確認
  • ベンダーの推奨に従って、対応する JRE（多くの場合 Java 11 もしくは Java 8 の最新 u リリース）へ更新
  • Crystal の起動スクリプトや設定ファイルで、使用する Java のパスを新しい JRE に向ける

Java 6/7 あるいは初期の 8u では、TLS 1.2 が既定で有効でなかったり、最新の暗号スイートに対応していなかったりします。Java 8u191 以降または Java 11 以上であれば TLS 1.2 が標準で有効になり、今回のようなサーバー側 TLS 強化にも追従しやすくなります。

3. Microsoft JDBC Driver for SQL Server を最新バージョンへ更新

SQL Server 2022 と Java 11 の組み合わせであれば、Microsoft JDBC Driver 9.x 以降、特に 12.x 系や 13.x 系が推奨されます。Microsoft のサポートマトリクスでは、12.x 系および 13.x 系が SQL Server 2022 / Java 11 の組み合わせを正式サポートしていることが明示されています。

  • Microsoft 公式サイトから、環境に合ったドライバ（例：mssql-jdbc-12.10.1.jre11.jar）を入手
  • Crystal が JDBC 接続で読み込んでいる既存の mssql-jdbc-*.jar をバックアップし、新しい .jar に差し替える
  • 古いバージョンの .jar がクラスパスに残らないよう、重複を整理

サードパーティ製の jTDS ドライバなどを使っている場合は、開発が止まっており TLS 周りが追従できていないケースが多いため、できる限り Microsoft 純正 JDBC ドライバに切り替えるとよいでしょう。

4. TLS 1.2 を明示した接続文字列の設定

JRE / JDBC ドライバを更新したら、接続文字列で TLS 関連のパラメータを明示します。Microsoft JDBC Driver 6.3.2 以降では、sslProtocol=TLSv1.2 を指定することができます。

典型的な接続文字列の例：

jdbc:sqlserver://<サーバー名>:1433;
databaseName=<DB名>;
encrypt=true;
sslProtocol=TLSv1.2;
trustServerCertificate=false;
hostNameInCertificate=<SQLサーバのFQDN>;

ポイントは次の通りです。

  • encrypt=true SQL Server との通信を必ず暗号化する（SQL Server 側が暗号化を強制していない場合でも暗号化）
  • sslProtocol=TLSv1.2 使用する TLS バージョンを明示的に TLS 1.2 に指定
  • trustServerCertificate=false サーバー証明書を検証する（本番では必須）
  • hostNameInCertificate サーバー証明書の Subject Alternative Name（SAN）に含まれる FQDN と一致させる

一時的な切り分けとして、次のように trustServerCertificate=true を指定すると、証明書検証をスキップできますが、本番環境での常用は推奨されません。

jdbc:sqlserver://<サーバー名>:1433;
databaseName=<DB名>;
encrypt=true;
sslProtocol=TLSv1.2;
trustServerCertificate=true;

これで接続できる場合は、証明書チェーンの信頼設定 に問題があることがほぼ確定します。

5. Crystal の JRE truststore に SQL Server 証明書（またはルート CA）を登録

社内 CA や自己署名証明書を使って SQL Server の TLS を構成している場合、Crystal の JRE がその証明書を信頼していない可能性があります。この場合は、Crystal が利用している JRE の cacerts に証明書を取り込む必要があります。

手順のイメージ：

  1. SQL Server に割り当てられているサーバー証明書（もしくは発行元のルート CA 証明書）を .cer 形式でエクスポート
  2. Crystal の JRE の cacerts を特定
    • 例：C:\Program Files (x86)\SAP BusinessObjects\<製品名>\jre\lib\security\cacerts（実際のパスは環境による）
  3. 次のようなコマンドで証明書を登録
"&lt;Crystal内JREのパス&gt;\bin\keytool.exe" ^
 -importcert ^
 -alias sqlserver-cert ^
 -keystore "&lt;JREパス&gt;\lib\security\cacerts" ^
 -file "C:\temp\sqlserver.cer"

初期パスワードは多くのディストリビューションで changeit ですが、セキュリティポリシーにより変更されている場合もあるため、利用している JRE の運用ルールを確認してください。

同様に、JVM 引数で truststore を明示する方法もあります。

-Djavax.net.ssl.trustStore=&lt;独自truststoreのパス&gt;
-Djavax.net.ssl.trustStorePassword=&lt;パスワード&gt;

6. サーバー側（SQL Server / Windows Server）の暗号スイート・証明書を点検

クライアント側を更新しても接続できない場合は、サーバー側の TLS 設定が極端に制限されている可能性があります。

  • 証明書の要件
    • 署名アルゴリズム：SHA-256 以上
    • 鍵長：2048 bit 以上
    • SAN（Subject Alternative Name）に FQDN（例：sql01.example.local）が含まれている
  • 暗号スイート
    • 少なくとも TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 などの ECDHE + AES-GCM 系が有効
    • 古い TLS_RSA_* や RC4 等に依存していないこと
  • SQL Server の暗号化設定
    • SQL Server 構成マネージャで「プロトコル」→「証明書」の割り当てを確認
    • 「暗号化を強制」の有無と実証明書を確認

Windows の TLS ポリシーは、グループポリシーやレジストリ（Schannel キー配下）で変更されている可能性もあるため、セキュリティチームがカスタムポリシーを適用していないかも合わせて確認しておきましょう。

ログとパケットから原因を特定するためのチェックリスト

ここまでの内容を、「どこを見れば何がわかるか」という観点でまとめると、次のようになります。

調査対象確認方法わかること典型的な所見
Windows イベントログ（Schannel）イベント ID 36874, 36887 などTLS ハンドシェイクどこで失敗しているかサーバーがクライアントの暗号スイートを拒否
SQL Server エラーログ「TLS 1.2 connection request」関連メッセージSQL Server 側が TLS 1.2 のみを許容しているか古いクライアントからの接続が拒否されている
Java TLS デバッグログ-Djavax.net.debug=ssl,handshakeクライアントが投げている TLS バージョン・暗号スイートTLSv1 or TLSv1.1 のみ、RSA キー交換のみ等
Wireshark キャプチャClientHello / ServerHello の有無どのレイヤーで通信が途切れているかServerHello が返らない / 直後に Alert が返る

これらを組み合わせることで、「JRE が古くて TLS 1.2 を話せていないのか」「証明書が信頼されていないのか」「サーバー側で暗号スイートの絞り込みがきつすぎるのか」といった切り分けがかなり明確になります。

どうしても解決しない場合の最終手段（非推奨）

ここまでの手当てを行っても JDBC 接続がどうしても回復しない場合、短期的には次のような「禁じ手」を取らざるを得ないケースもあります。

1. KB5060531 をアンインストールする

もっとも単純で効果は高い一方、セキュリティ修正をすべて巻き戻す という重大なデメリットがあります。実際、DHCP 問題などでも「ひとまず KB5060531 をアンインストールして業務を復旧した」という報告がいくつも上がっています。

  • コマンド例：wusa /uninstall /kb:5060531 /quiet /norestart
  • または [更新の履歴] から KB5060531 を選択してアンインストール

あくまでも「一時的な復旧策」としてのみ利用し、後続の修正（例：DHCP 問題を解決する KB5062557 など） が公開されたら改めて適用することが望まれます。

2. 古い TLS（1.0 / 1.1）や弱い暗号スイートを再有効化する

レジストリやグループポリシーで TLS 1.0 / 1.1 や古い暗号スイートを再び有効にすると、古い JRE / JDBC でも接続できる可能性はあります。しかし、これは現在のセキュリティ基準から見ると明確な後退であり、コンプライアンス違反となることもあります。

  • 攻撃面の拡大（既知の TLS 1.0 / 1.1 の脆弱性）
  • 監査で「なぜ無効化していないのか」を説明する負担

従って、どうしてもやるならば 検証環境限定 とし、本番環境では JRE / JDBC の更新と証明書設定の是正 を優先すべきです。

今回の事例の「落としどころ」と運用上の提案

Microsoft Q&A に投稿された事例では、次のような経緯が報告されています。

  • Windows Server 2019 に KB5060531 を適用
  • その直後から、SAP Crystal Reports の JDBC 接続のみが SQL Server 2022 へ接続不可に
  • アドバイザーの提案に従い：
    • JRE を Java 11 へ更新
    • Microsoft JDBC Driver for SQL Server 12.10.1（Java 11 用）を導入
    • 接続文字列で TLS 1.2 や証明書関連のパラメータを調整
  • しかし環境依存の要因もあり、最終的には JDBC 接続を断念
  • Crystal Reports の接続方式を ADO / OLE DB に切り替えることで業務を継続

この落としどころから読み取れるポイントは次の通りです。

  • 「JDBC にこだわりすぎない」ことも重要な選択肢 – レポート用途であれば、ADO / OLE DB / ODBC で十分なケースも多い。
  • JDBC を本気で継続利用するなら「セットで大改修」が必要 – Crystal 内部の JRE / JDBC を全面的に更新 – TLS 1.2 / ECDHE 前提で証明書や暗号スイートを再設計 – 検証環境での十分なテストとロールバック手順の用意

「とりあえず KB をアンインストールする」「古い TLS を復活させる」という対処は、短期的には楽ですが、中長期的にはセキュリティリスクと運用負債を積み上げるだけになりかねません。

今後の運用指針とベストプラクティス

最後に、今回の KB5060531 ＋ JDBC 問題を教訓にした、今後の運用指針をまとめます。

1. Java / JDBC を使うシステムは「OS と別軸で」ライフサイクル管理する

  • OS を最新に保つだけでは不十分で、同梱 JRE や JDBC ドライバも計画的に更新が必要
  • どのアプリがどの JRE / JDBC を使っているかの台帳を作成しておくと、今回のようなトラブル時に即時把握できる

2. TLS 設定は「最低限 TLS 1.2 / ECDHE / SHA-256」前提で設計

  • SQL Server 側の証明書・暗号スイート・TLS バージョンは、現代的な標準（TLS 1.2 + ECDHE + AES-GCM + SHA-256）を基本とする
  • それに追従できないクライアント（古い Java など）は計画的にリプレースする方針を立てる

3. ベンダーサポート情報（Microsoft / SAP / ミドルウェア各社）をウオッチする

  • 今回のように、特定の KB と特定のミドルウェアの組み合わせで初めて顕在化する問題は珍しくありません
  • Microsoft の更新情報や、ベンダーのサポートノート（SAP Note など）を定期的に確認し、既知の問題と回避策を把握する

4. ログとパケットキャプチャの取得手順を標準化しておく

  • Schannel ログの取得手順
  • Java の TLS デバッグログ出力方法
  • Wireshark による TLS ハンドシェイクの確認方法

これらを標準手順としてドキュメント化しておけば、次回似たようなトラブルが発生した際も、短時間で原因にたどり着けるようになります。

まとめ：KB5060531 と JDBC/TLS 問題への向き合い方

  • 原因の本質 KB5060531 による Windows Server 2019 側の TLS 強化と、SAP Crystal Reports が内部に抱えている古い JRE / JDBC ドライバ、あるいは不適切な証明書・暗号設定との不整合により、JDBC の TLS ハンドシェイクが失敗している可能性が高い。
  • 暫定対応 業務継続を最優先するなら、まずは Crystal Reports の接続方式を JDBC から ADO / OLE DB（MSOLEDBSQL など）に切り替えて、レポート出力を復旧させる。
  • 恒久対応 JDBC を使い続けたい場合は、Crystal 内部の JRE をサポートされている Java 11 以上に更新し、Microsoft JDBC Driver for SQL Server を SQL Server 2022 対応の最新バージョンに統一。接続文字列で TLS 1.2 / 証明書検証を明示し、サーバー側の証明書・暗号スイートも現代的な構成にそろえる。
  • 禁じ手の扱い KB のアンインストールや古い TLS の再有効化は、短期的には復旧策になり得るが、セキュリティリスクが大きいため、検証や一時回避以外では避けるべき。
  • 長期的な教訓 OS パッチと同様に、Java ランタイムや JDBC ドライバも継続的にアップデートする体制を整え、TLS 1.2 / ECDHE / SHA-256 を前提にした設計へ移行していくことが、将来のトラブル回避とセキュリティ強化につながる。

以上を踏まえ、まずは「業務を止めないための暫定回避」と「JRE/JDBC 更新を含めた恒久対応の計画」を切り分けて検討し、社内のセキュリティポリシーやベンダーサポートと整合した形で、最適な落としどころを探っていくことをおすすめします。

Windows Server
JDBC Windows Server 2019 SQL Server 2022 TLS 1.2 KB5060531 SAP Crystal Reports

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次