次の方法で共有

既存の接続がリモート ホストによって強制的に閉じられた (OS エラー 10054)

  • [アーティクル]

適用対象: SQL Server

注:

トラブルシューティングを開始する前に、 前提条件 を確認し、チェックリストを確認することをお勧めします。

この記事では、さまざまなシナリオについて詳しい説明を行い、次のエラーの解決策を示します。

  • サーバーとの接続が正常に確立されましたが、ログイン プロセス中にエラーが発生しました。 (プロバイダー: SSL プロバイダー、エラー: 0 - リモート ホストによって既存の接続が強制的に閉じられました)。

  • サーバーとの接続が正常に確立されましたが、ログイン前ハンドシェイク中にエラーが発生しました。 (プロバイダー: TCP プロバイダー、エラー: 0 - リモート ホストによって既存の接続が強制的に閉じられました)。

オペレーティング システム エラー 10054 は、Windows ソケット レイヤーで発生します。 詳細については、「 Windows ソケット エラー コード: WSAECONNRESET 10054」を参照してください。

エラーはいつ表示されますか?

セキュア チャネル ( Schannel とも呼ばれます) は、 セキュリティ サポート プロバイダー (SSP) です。 これには、ID 認証と暗号化によるセキュリティで保護されたプライベート通信を提供する一連のセキュリティ プロトコルが含まれています。 Schannel SSP の 1 つの機能は、さまざまなバージョンの トランスポート層セキュリティ (TLS) プロトコルを実装することです。 このプロトコルは、インターネット経由で通信される情報のプライバシーを保護するために設計された業界標準です。

TLS ハンドシェイク プロトコルは、TCP 経由で通信する 2 つのアプリケーション間のセキュリティで保護されたセッションを確立または再開するために必要なキー交換を担当します。 接続プロセスのログイン前フェーズでは、SQL Serverおよびクライアント アプリケーションは TLS プロトコルを使用して、資格情報を送信するためのセキュリティで保護されたチャネルを確立します。

次のシナリオでは、ハンドシェイクを完了できない場合に発生するエラーについて詳しく説明します。

シナリオ 1: クライアントとサーバーの間に一致する TLS プロトコルが存在しない

SECURE Socket Layer (SSL) と TLS 1.2 より前のバージョンの TLS には、既知のいくつかの脆弱性があります。 TLS 1.2 にアップグレードし、可能な限り以前のバージョンを無効にすることをお勧めします。 したがって、システム管理者は、グループ ポリシーまたはその他のメカニズムを介して更新プログラムをプッシュして、環境内のさまざまなコンピューターでこれらの安全でない TLS バージョンを無効にすることができます。

接続エラーは、アプリケーションで以前のバージョンの Open Database Connectivity (ODBC) ドライバー、OLE DB プロバイダー、.NET Framework コンポーネント、または TLS 1.2 をサポートしていないSQL Server バージョンを使用している場合に発生します。 この問題は、サーバーとクライアントが一致するプロトコル (TLS 1.0 や TLS 1.1 など) を見つけることができないために発生します。 接続を続行するために必要な TLS ハンドシェイクを完了するには、一致するプロトコルが必要です。

解決方法

この問題を解決するには、以下のいずれかの方法を使用します。

  • SQL Serverまたはクライアント プロバイダーを TLS 1.2 をサポートするバージョンにアップグレードします。 詳細については、「Microsoft SQL Server の TLS 1.2 サポート」を参照してください。
  • 次のいずれかの操作を実行して、クライアント コンピューターとサーバー コンピューターの両方で TLS 1.0 または TLS 1.1 を一時的に有効にするようにシステム管理者に依頼します。

シナリオ 2: クライアントとサーバーで TLS プロトコルを照合するが、一致する TLS 暗号スイートがない

このシナリオは、ユーザーまたは管理者が、追加のセキュリティのためにクライアントまたはサーバー上の特定のアルゴリズムを制限した場合に発生します。

クライアントとサーバーの TLS バージョン、暗号スイートは、ネットワーク トレース内のクライアント Helloおよびサーバー Hello パケットで簡単に調べることができます。 クライアント Hello パケットは、すべてのクライアント暗号スイートをアドバタイズしますが、サーバー Hello パケットはそのうちの 1 つを指定します。 一致するスイートがない場合、サーバーはサーバー Hello パケットに応答するのではなく、接続を閉じます。

解決方法

問題をチェックするには、次の手順に従います。

  1. ネットワーク トレースを使用できない場合は、次のレジストリ キーの下に functions 値をチェックします。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    次の PowerShell コマンドを使用して、TLS 関数を見つけます。

    Get-ItemPropertyValue  -Path HKLM:\System\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\ -Name Functions

  2. IIS Crypto ツールの [暗号スイート] タブを使用して、一致するアルゴリズムがあるかどうかをチェックします。 一致するアルゴリズムが見つからない場合は、Microsoft サポートにお問い合わせください。

詳細については、「 TLS 1.2 アップグレード ワークフロー と トランスポート層セキュリティ (TLS) 接続が失敗するか、再開を試みるとタイムアウトになる可能性がある」を参照してください。

シナリオ 3: TLS_DHE暗号が有効になっている可能性がある

この問題は、クライアントまたはサーバーが Windows 2012、2016、およびそれより高いバージョンでホストされている場合に発生します。 両方の OS バージョンが同じ暗号 (TLS_DHE*) を所有しているにもかかわらず、Windows 2012 および 2016 以降では TLS 内の暗号化キーは異なる方法で処理されます。 これにより、通信エラーが発生する可能性があります。

解決方法

この問題を解決するには、ローカル ポリシーから "TLS_DHE*" で始まるすべての暗号を削除します。 アプリケーションが Windows でSQL Serverに接続しようとしたときに発生するエラーの詳細については、「Windows で SQL Server を接続するときにアプリケーションが TLS 接続エラーを強制的に閉じる」を参照してください。

シナリオ 4: SQL Serverは、MD5、SHA224、SHA512 などの弱いハッシュ アルゴリズムによって署名された証明書を使用します

SQL Serverは、サインインに関連するネットワーク パケットを常に暗号化します。 この目的のために、手動でプロビジョニングされた証明書または 自己署名証明書が使用されます。 SQL Server証明書ストアでサーバー認証機能をサポートする証明書が見つかると、証明書が使用されます。 SQL Serverは、手動でプロビジョニングされていない場合でも、この証明書を使用します。 これらの証明書で MD5、SHA224、 SHA512 などの弱ハッシュ アルゴリズム (拇印アルゴリズム) を使用する場合、TLS 1.2 では動作せず、前述のエラーが発生します。

注:

自己署名証明書は、この問題の影響を受けません。

解決方法

この問題を解決するには、次の手順を実行します。

  1. SQL Server 構成マネージャーで、[コンソール] ウィンドウSQL Server [ネットワーク構成] を展開します。
  2. インスタンス名として [プロトコル] を <選択します>。
  3. [ 証明書 ] タブを選択し、関連する手順に従います。
    • 証明書が表示されている場合は、[ 表示 ] を選択して拇印アルゴリズムを調べて、弱ハッシュ アルゴリズムを使用しているかどうかを確認します。 次に、[ クリア ] を選択し、手順 4 に進みます。
    • 証明書が表示されない場合は、次のようなエントリのSQL Serverエラー ログを確認し、ハッシュまたは拇印の値をメモします。
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. サーバー認証を削除するには、次の手順に従います。
    1. [Start Run]\(実行の開始\)> を選択し、「MMC」と入力します。 (MMC は Microsoft 管理コンソールとも呼ばれます)。
    2. MMC で証明書を開き、[証明書] スナップイン画面で [コンピューター アカウント] を選択します。
    3. [ 個人用>証明書] を展開します。
    4. SQL Serverが使用している証明書の名前または証明書ストア内の別の証明書の拇印の値を調べて、その [プロパティ] ウィンドウを開きます。
    5. [ 全般 ] タブで、[ 次の目的のみを有効にする ] を選択し、[ サーバー認証] の選択を解除します。
  5. SQL Server サービスを再起動します。

シナリオ 5: クライアントとサーバーは TLS ハンドシェイクTLS_DHE暗号スイートを使用していますが、システムの 1 つにインストールされているTLS_DHEの先行ゼロ修正がありません

このシナリオの詳細については、「 Windows で SQL Server を接続するときにアプリケーションで TLS 接続エラーが強制的に閉じられる」を参照してください。

注:

この記事で問題が解決されていない場合は、接続に関する一般的な問題の記事が役立つかどうかをチェックできます。

シナリオ 6: IOCP ワーカーの不足による TCP Three-Way ハンドシェイク タイムアウト (SYN 失敗、TCP 拒否)

SQL Server 2017 以前のワークロードが多いシステムでは、TCP 3 方向ハンドシェイクエラーによって 10054 エラーが断続的に発生し、TCP 拒否が発生する可能性があります。 この問題の根本原因は、要求の処理 TCPAcceptEx が遅れている可能性があります。 この遅延は、受信接続の受け入れを管理する IOCP (入力/出力完了ポート) リスナー ワーカーの不足が原因である可能性があります。 IOCP ワーカーの数が不足し、他の要求のサービスがビジーになっていると、接続要求の処理が遅れ、最終的にハンドシェイクエラーと TCP 拒否が発生します。 また、SSL ハンドシェイクの開始中 (存在する場合) やログイン要求の処理中にログイン タイムアウトが観察される場合があります。これは認証チェックに関連します。

解決方法

認証と暗号化操作の処理に割り当てられた IOCP ワーカーと SOS Worker リソースの不足は、TCP の 3 方向ハンドシェイク タイムアウトと追加のログイン タイムアウトのメイン原因です。 SQL Server 2019 には、この領域のいくつかのパフォーマンスの向上が含まれています。 注目すべき機能強化の 1 つは、専用ログイン ディスパッチャー プールの実装です。 これにより、ログイン関連タスクのリソースの割り当てが最適化され、タイムアウトの発生が減り、システム全体のパフォーマンスが向上します。

TLS 接続が失敗するその他のシナリオ

発生したエラー メッセージが前のシナリオのいずれにも対応していない場合は、次の追加シナリオを参照してください。

関連項目

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。