SQL Server暗号化エラーを修正 - ワンクリックソリューション

エラーを読んでください - それは信頼の問題であり、ネットワークの問題ではありません

ネットワークは正常で、サーバーは稼働しています。接続は SQL Server に到達し、サーバーはログイン用の暗号化チャネルを提供しましたが、サーバーの ID を証明する証明書が PC が信頼する人によって署名されていないため、PC はそれを拒否しました。 SSMS が示す完全なエラーは次のとおりです。

デフォルトでは、SQL Server は自身で作成する自己署名証明書を使用してログインを保護します。自己署名証明書はトラフィックを暗号化しますが、サーバーが本当に自分のサーバーであることを証明できないため、検証された暗号化を要求するクライアントはそれを拒否します。すべての誠実な修正は 2 つのうちの 1 つです。クライアントにこの特定のサーバーを意図的に受け入れるようにする (ステップ 2 および 3)、またはクライアントが独自に信頼する証明書をサーバーに与える (ステップ 4)。

SSMS のクライアントのクイック修正 - サーバー証明書を信頼する

動画で紹介されている最速ルートです。サーバー上では何も変更されません。これは、この 1 つの接続に対して、誰が署名したかを確認せずにサーバーの証明書を受け入れるように指示します。 SSMS の [サーバーへの接続] ウィンドウで、オプション をクリックして追加のタブを開き、接続プロパティ タブに移動し、暗号化を必須 に設定し (または提供されたままにし)、サーバー証明書を信頼する にチェックを入れて、接続 をクリックします。ログインはすぐに完了します。

アプリ接続文字列内の同じ修正

SSMS ではなくアプリケーションが失敗した場合、同じスイッチが接続文字列内に存在します。 2 つの設定を明示的に追加します。Encrypt=True は保護されたチャネルをオンにし、TrustServerCertificate=True は SSMS チェックボックスの接続文字列のスペルです。

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

例の値の代わりに独自のサーバー名、データベース、ログインを使用します。トレードオフはステップ 2 のチェックボックスとまったく同じですが、さらに危険性が 1 つあります。出荷されたアプリケーションの構成に組み込まれているため、スキップされたチェックはすべてのユーザーに目に見えず永続的に適用されます。この時間を開発およびステージング構成に保持し、実稼働環境では、ステップ 4 のサーバー証明書が配置されるまで借用時間として扱います。

適切な修正 - サーバーに実際の証明書を与える

永続的な修復はサーバー上で 1 回行われ、その後はすべてのクライアントがチェックボックスや警告なしで厳密に接続します。まず、サーバー認証を使用して、内部認証局またはパブリック CA からサーバーの完全な DNS 名 (sql01.company.local など) の証明書を取得します。これを秘密キーとともに SQL Server マシンのローカル コンピューター 証明書ストアにインポートします。次に、証明書を右クリックし、すべてのタスク → 秘密キーの管理 を選択し、SQL Server サービス アカウントに秘密キーの読み取り アクセス許可を付与します。 SQL Server 構成マネージャー を開き、SQL Server ネットワーク構成 を展開し、MSSQLSERVER のプロトコル を右クリックしてプロパティ を選択し、証明書 タブで証明書を選択します。 [フラグ] タブで、ForceEncryption を はい に設定して、すべてのクライアントに暗号化を要求することもできます。 SQL Server サービスを再起動します。再起動するまで、変更は何も反映されません。

厳密な方法で修正を検証する

一部の設定の組み合わせは実際の保護なしで接続するため、静かに成功するログインは人々が考えているよりも重要ではありません。両方の半分を証明します。まず、クライアントから厳密な方法で再接続します。サーバーの DNS 名 (証明書内の名前) を使用して接続し、暗号化を [必須] に設定し、サーバー証明書を信頼する のチェックを外します。ログインは警告なしで成功するはずです。次に、同じセッションで、SSMS で次のクエリを実行して、接続が実際に暗号化されているかどうかをサーバーに問い合わせます。

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option で TRUE が表示されれば合格です。ログインが機能している場合の FALSE は、保護を解除することで接続が成功し、ジョブが完了していないことを意味します。このテストに合格することが本当の最終ラインです。将来の SSMS バージョンを含む、正しく構成されたクライアントは、特別な設定を行わずに完全な検証で接続できるようになります。