次の方法で共有

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

  • [アーティクル]

適用対象: SQL Server

Note

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

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

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

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

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

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

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

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

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

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

SSL (Secure Socket Layer) と 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 バージョン 暗号化スイート は、ネットワーク トレース内の Client Hello および Server Hello パケットで簡単に調べられます。 Client Hello パケットはすべてのクライアント暗号スイートをアドバタイズしますが、Server Hello パケットはそれらのいずれかを指定します。 一致するスイートがない場合、サーバーは Server Hello パケットに応答する代わりに接続を閉じます。

解決方法

この問題を調べるには、次の手順に従います。

  1. ネットワーク トレースを使用できない場合は、次のレジストリ キーの関数の値を確認します。 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 ツールの Ciphers Suites タブを使用して、一致するアルゴリズムがあるかどうかを確認します。 一致するアルゴリズムが見つからない場合は、Microsoft サポートにお問い合わせください。

詳細については、「 TLS 1.2 アップグレード ワークフロー および Transport Layer Security (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 では機能せず、前述のエラーが発生します。

Note

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

解決方法

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

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

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

このシナリオの詳細については、「Windows で SQL サーバーに接続するときのアプリケーション エクスペリエンスによる TLS 接続の強制クローズ エラー」を参照してください。

Note

この記事で問題が解決されていない場合は、 common 接続の問題に関する記事 役立つかどうかを確認できます。

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

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

解決方法

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

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

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

関連項目

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

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