Windows Server 2012 R2 の WSUS で「Synchronization が失敗し続ける」「The underlying connection was closed」「An existing connection was forcibly closed by the remote host」といった WebException が出ると、まずプロキシやホワイトリストを疑いがちです。実はサーバー側の暗号スイート制限が原因になるケースがあります。切り分けから復旧までまとめます。
状況整理：WSUS の同期が止まると何が困るか
WSUS（Windows Server Update Services）の同期（Synchronization）は、Microsoft Update から更新プログラムのメタデータ（更新一覧、分類、承認対象など）を取得する処理です。ここが止まると、クライアントが既存の更新を配布できていても「新しい更新が WSUS に入ってこない」状態になり、パッチ運用が数週間単位で遅延します。
今回のケースは、Windows Server 2012 R2 上の WSUS が数週間にわたり同期失敗を繰り返し、コンソール上は失敗のまま。さらに、WSUS はプロキシ経由でインターネット接続しており、Windows Update 関連 URL はホワイトリスト化済み……という、いかにも「プロキシが怪しい」と感じやすい状況でした。
よく出るエラーメッセージとログの確認ポイント
WSUS の同期失敗で頻出するのが、.NET 例外（WebException）系のメッセージです。特に次のような文言が出ている場合、通信そのものは始まっているのに途中で切断されている可能性が高いです。
| 表示されがちなエラー | 意味のイメージ | 誤解しやすい点 |
|---|---|---|
The underlying connection was closed | TLS/HTTP の下位層接続が途中で閉じられた | 「プロキシが落としている」と決めつけやすい |
An existing connection was forcibly closed by the remote host | 相手側が強制的に接続を切った | “remote host” がプロキシなのか Microsoft 側なのか判別しづらい |
Could not create SSL/TLS secure channel | TLS のハンドシェイクに失敗 | URL ホワイトリストや DNS のせいにされがち |
原因特定の入口としては、まず WSUS 側で「どこに、どのタイミングで」失敗しているかを把握します。代表的には次を確認します。
- WSUS コンソール：同期結果（失敗時刻、エラー概要）
- WSUS ログ：
C:\Program Files\Update Services\LogFiles配下（例：SoftwareDistribution.log） - イベント ビューアー：Application / System、および Schannel 関連イベント
WSUS ログで例外が出ている場合は、次のような断片が見つかります（例）。
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
--> System.IO.IOException: Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.プロキシが原因か、WSUS/OS 側か：切り分けの考え方
プロキシ経由の WSUS で同期が失敗すると、まず「URL のホワイトリスト漏れ」「プロキシ認証」「SSL インスペクション（復号検査）」などが疑われます。ただし、今回のように WebException の切断系が続く場合、プロキシは単にトンネルを張っているだけで、真の原因はサーバー側の TLS 設定ということも珍しくありません。
切り分けでは、次の3層で考えると迷いにくいです。
| 層 | 見るポイント | 代表的な確認方法 |
|---|---|---|
| 名前解決・到達性 | DNS/ルーティング/Firewall で詰まっていないか | nslookup、Test-NetConnection（PowerShell） |
| HTTP/プロキシ制御 | プロキシが CONNECT を許可しているか、認証や除外は適切か | プロキシログ、netsh winhttp show proxy、WSUS の Proxy 設定 |
| TLS（暗号化） | TLS バージョン/暗号スイートで握手できるか | Schannel イベント、暗号スイート設定の履歴（GPO/レジストリ） |
まず確認：WSUS と WinHTTP のプロキシ設定がズレていないか
「プロキシは設定しているつもり」でも、WSUS の設定と OS（WinHTTP）設定が食い違っていると、同期の一部だけ失敗することがあります。疑う順番としては暗号スイートの前に、設定の整合性だけは押さえるのがおすすめです。
- WSUS コンソール：オプション > 更新元とプロキシ サーバー で、プロキシ/認証/例外設定を確認
- WinHTTP の確認：
netsh winhttp show proxy
netsh winhttp show proxyもし WinHTTP 側が未設定で、組織の通信要件上プロキシ必須なら、次のように IE 設定を取り込む運用もあります（環境の標準に従ってください）。
netsh winhttp import proxy source=ieSSL インスペクションをしているプロキシは要注意
プロキシが HTTPS を「復号して検査」する構成（SSL インスペクション）の場合、WSUS とプロキシの間で TLS が終端します。このとき、証明書置換や独自 CA、暗号スイート制限が絡むと障害が複雑化します。運用上可能なら、Windows Update/WSUS の宛先は SSL インスペクションを除外するのがトラブル回避になります。
今回の結論：プロキシではなく、暗号スイート制限が WSUS 同期を壊していた
結論から言うと、原因はプロキシではありませんでした。サーバー側で実施した「暗号スイート（Cipher Suite）の制限（弱い暗号の除外）」が、WSUS の Microsoft Update 同期に必要な TLS ネゴシエーション（ハンドシェイク）を成立させなくなっていたのが根本原因でした。
暗号スイートを触ると WSUS の同期が止まる典型パターン
TLS 通信では、クライアント（WSUS 側）とサーバー（Microsoft 側）が共通で利用できる暗号スイートを選んで通信を開始します。暗号スイートを「弱いものを除外する」つもりで絞り込むと、意図せず次のような状態になり得ます。
| ありがちな変更 | 起こりやすいこと | WSUS 側の見え方 |
|---|---|---|
| RSA 系をまとめて外す | 相手が RSA 証明書のとき、共通スイートが消える | 握手できず切断（WebException） |
| GCM のみ残す | 相手の優先順位や一時的な仕様変更で不一致になる | 断続的に失敗する |
| ツール/GPO の適用ミスで空リスト | 実質「全無効」になり、あらゆる HTTPS が不安定に | 突然すべての外向き通信が壊れる |
| 順序を極端に入れ替える | 古い/弱いスイートが優先され、相手に拒否される | 接続が確立せずタイムアウト/切断 |
この結果、WSUS から見ると「接続が途中で切られた」「安全なチャネルが作れない」といった WebException になります。プロキシが間にいる場合でも、プロキシが単なる CONNECT トンネルならTLS の握手は WSUS と Microsoft 間で実施されるため、プロキシ設定が正しくても失敗します。
“プロキシっぽい”エラーに見える理由
プロキシ経由の HTTPS は、まずプロキシに対して CONNECT を張り、その中を TLS で通信します。WSUS 側の暗号スイートが合わずに握手が失敗すると、見た目は「外部のホストが接続を切った」ように見えます。ログ上も “remote host” と出るため、ついプロキシや出口を疑い続けて時間を溶かしがちです。
暗号スイート制限が入っているかを短時間で確認する方法
「暗号スイートを触った記憶がない」場合でも、セキュリティ部門の GPO、ハードニングツール、監査対応の一括設定で入っていることがあります。まずは“いま有効な制限がどこから来ているか”を確認します。
レジストリでポリシー適用の有無を確認
次のキーが存在し、Functions に暗号スイートの列挙が入っていれば、既定ではなく制限/順序指定が有効です。
reg query "HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002" /v Functionsどの GPO が適用しているかを確認
ドメイン環境では、ローカルで未構成にしても上位の GPO が上書きします。適用元の特定には次が便利です。
gpresult /h C:\temp\gpresult.html出力した HTML を開き、SSL 構成設定や関連するセキュリティポリシーを確認します。
Schannel ログで「握手失敗」を見える化する（必要なときだけ）
切り分けを急ぎたい場合は、Schannel のイベントログ出力を一時的に増やして、TLS の失敗を観測します。大量にログが出ることがあるため、作業が終わったら戻す前提で実施してください。
| キー | 値 | 意味 |
|---|---|---|
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL | EventLogging（DWORD） | Schannel のログレベル。例：7 で詳細寄り |
ログに「利用可能な暗号スイートがない」「ハンドシェイクに失敗」などが出る場合、プロキシよりもTLS 設定側の疑いが濃厚です。
復旧手順：暗号スイート設定を変更前にロールバックして同期を通す
今回有効だった対処はシンプルで、変更していた暗号スイート制限を元に戻す（既定に戻す）ことでした。安全に戻すための手順を、実務でやりやすい形に整理します。
作業前に必ず取るバックアップ
暗号スイートの変更は OS 全体に影響します。まずは設定の現状を退避して、戻せる状態にします。
- GPO で設定している場合：該当ポリシーの内容（暗号スイート文字列）を控える
- レジストリで設定している場合：該当キーをエクスポート
暗号スイート順序（SSL Cipher Suite Order）がポリシーで設定されている場合、次のキーが使われることが多いです。
HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
(値) Functions : (カンマ区切りの暗号スイート名)エクスポート例：
reg export "HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002" C:\temp\ssl_cipher_order.reg設定を既定に戻す方法（おすすめ順）
| 方法 | やること | メリット | 注意点 |
|---|---|---|---|
| GPO で「未構成」に戻す | ローカル/ドメインの「SSL 暗号スイートの順序」を未構成へ | 意図が明確で戻しやすい | ドメイン GPO が上書きしていないか確認 |
| ポリシーのレジストリを削除する | 上記キー（00010002）を削除、または Functions を除去 | 即効性が高い | 運用ルールに従い、必ずバックアップ後に実施 |
| 既定の暗号スイート文字列に戻す | 環境の標準リストに差し戻す | 再ハードニング前提なら便利 | 既定文字列の管理が必要 |
GPO の場所（例）：
- コンピューターの構成 > 管理用テンプレート > ネットワーク > SSL 構成設定 > SSL 暗号スイートの順序
変更後は、次を実施します。
gpupdate /force（GPO 適用）- サーバー再起動（Schannel の再読み込みを確実にするため推奨）
- WSUS の同期を手動実行して結果を確認
復旧確認：同期が「成功」になるまで見るポイント
再起動後、WSUS コンソールから同期を実行し、成功になることを確認します。成功したら、次も合わせて見ると「本当に治った」が担保できます。
- WSUS コンソールの同期履歴で、失敗が止まり成功が記録されている
- WSUS ログ（例：
SoftwareDistribution.log）で WebException が止まっている - イベントログに Schannel の致命的エラーが出続けていない
参考：同種トラブルでよく使う一般的なチェック（今回は決定打ではないが有用）
今回の根本原因は暗号スイートでしたが、WSUS 同期トラブルでは次のチェックも定番です。暗号スイートを疑う前後で併用すると、原因の取りこぼしを減らせます。
WSUS の健康状態チェック
WSUS の整合性や内部状態を確認するために、次のコマンドがよく使われます。
wsusutil.exe checkhealth実行後、イベントビューアーの Application ログに WSUS の健康状態に関するイベントが出力されます。同期以前に DB やコンテンツの問題があると、ここで気づけます。
IIS（WSUS 向け設定）の確認
WSUS は IIS 上で動作します。IIS 側の設定が極端に変わっている場合、同期やコンソール動作に影響が出ることがあります（アプリプール、メモリ制限、タイムアウト等）。ただし今回のように「外部同期の TLS で落ちる」タイプでは、IIS 最適化だけでは直らないことが多いです。
WSUS/.NET/OS の更新状況
Windows Server 2012 R2 は古い世代のため、累積更新（ロールアップ）や .NET 更新の適用状況で TLS まわりの挙動が変わることがあります。WSUS を長期運用している環境ほど、更新適用の抜けが障害の温床になります。
.NET に TLS 1.2 を使わせるレジストリ（参考）
WSUS や周辺コンポーネントが .NET の既定設定に影響される場合、次のようなレジストリが話題になります。環境依存のため、適用する場合はバックアップと検証が必須です。
| キー | 値 | 目的 |
|---|---|---|
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 | SchUseStrongCrypto = 1 (DWORD) | .NET に強い暗号を優先させる |
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 | SystemDefaultTlsVersions = 1 (DWORD) | OS の既定 TLS 設定に追随させる |
HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 | 同上 | 32bit 側 .NET への適用 |
ただし、今回のケースでは暗号スイートの絞り込みが原因だったため、上記を追加しても決定打にはなりませんでした。まずは「握手できる暗号が残っているか」を優先してください。
運用上の注意：暗号スイートのハードニングは“段階的”が安全
セキュリティ対策として弱い暗号を削ること自体は重要です。しかし、WSUS のような基盤機能が止まると運用影響が大きいため、いきなり理想形に寄せないのがコツです。
安全な進め方（おすすめの順番）
| 手順 | やること | 狙い | 確認 |
|---|---|---|---|
| 既定に戻して復旧 | 暗号スイート制限をロールバック | まず業務復旧 | WSUS 同期が成功する |
| バックアップ取得 | GPO/レジストリをエクスポート | 即時ロールバック可能に | 復元手順を用意 |
| 弱いものから削る | RC4/DES/NULL/EXPORT など明確に弱いものを先に除外 | 影響を最小化 | 同期と主要サービスを都度テスト |
| 段階的に厳格化 | 必要に応じて 3DES や古い SHA を整理 | 安全性向上 | 失敗したら即戻す |
“残すべき暗号”を考えるときの実務的なポイント
暗号スイートの名前を見ても分かりにくい場合は、次の観点で判断すると事故を減らせます。
- 鍵交換：ECDHE が基本。迷ったら RSA 系も一定数残して“逃げ道”を作る
- 暗号化方式：AES-GCM が主流。環境によっては AES-CBC も必要になるため段階的に
- ハッシュ：SHA1 より SHA256/384 を優先
さらに具体化したい場合は、現場でよく使われる「残す候補」の例として次の系統があります（あくまで例です。環境の標準と通信要件に合わせて調整してください）。
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256/TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256/TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256/TLS_RSA_WITH_AES_256_GCM_SHA384
重要なのは「正解リストを暗記する」ことではなく、変更のたびに WSUS 同期で疎通テストし、失敗したらすぐ戻せる運用を作ることです。
再発防止：WSUS 同期障害を早期に検知する仕組み
同期失敗が数週間放置されると、気づいた時点でパッチ適用計画が崩れます。次のような“軽い監視”だけでも効果があります。
- WSUS の同期結果（成功/失敗）を週次で確認する運用（担当者のチェックリスト化）
- イベントログ（Schannel/WSUS）のエラー数を監視し、急増したら通知
- GPO 変更やセキュリティツール適用時に「WSUS 同期テスト」を作業手順へ組み込む
- 暗号スイート設定のエクスポートを構成管理（リポジトリや保管場所）に残す
まとめ
Windows Server 2012 R2 の WSUS で WebException（The underlying connection was closed / An existing connection was forcibly closed）が続く場合、プロキシや URL ホワイトリストだけを疑うと遠回りになることがあります。セキュリティ対策で実施した暗号スイート制限が、Microsoft Update との TLS ハンドシェイクを壊しているケースがあるため、まずは変更履歴を確認し、既定へロールバックして同期が通るかを試すのが最短です。
コメント