Microsoft Store からの UWP アプリのインストールや WSL の更新が「0x800704cf」や実際の通信層のエラー「0x80072f7d」で止まる──この症状は多くの場合、TLS（HTTPS）の確立に失敗しているサインです。特に mitmproxy 等を一度でも導入した環境では、自己署名のルート証明書や残置プロキシ設定が原因になりがち。本稿では、最短で復旧するための実行順チェックリストから、根本原因の見極め方、再発防止まで実務目線で徹底解説します。
現象：Microsoft Store／WSL でエラー 0x800704cf（実通信層では 0x80072f7d）
症状
- Microsoft Store で WhatsApp などの UWP アプリをインストールしようとすると失敗し、UI 上は汎用エラー
0x800704cfと表示される場合がある。 - 通信層の詳細ログや CLI 実行では
0x80072f7dが出力されることがある（TLS ハンドシェイクで失敗）。 winget経由のインストール、または WSL のwsl --update --web-downloadでも同様に失敗する。- Windows 10 の初期化直後（空き容量 17GB 以上）、VPN／プロキシ未使用のつもりでも発生。ただし以前に mitmproxy 等を試した記憶がある。
推定原因（なぜ起きるか）
Microsoft Store・WSL・winget はいずれも TLS で Microsoft 側の配信サーバーへ接続します。ここで、Windows の「信頼されたルート証明機関」ストアに通常存在しない自己署名 CA が混入していたり、WinHTTP／WinINET のプロキシが不正に設定されていると、以下のような問題が起こります。
- TLS ハンドシェイク時にサーバー証明書の検証が失敗（不明な発行元・中間証明書の欠落・有効期限ずれ・失効処理の失敗）。
- HTTPS 通信がローカルのフィルタリングドライバや MITM プロキシにリダイレクトされ、Store／WSL から見ると「信頼できない経路」に見える。
- 結果として
0x800704cf（ネットワーク到達不可の汎用表示）または実際の通信層エラー0x80072f7dが発生。
ポイントは「ネットワークの暗号化レイヤーに介入するツールや設定の残骸」が犯人である確率が高いということです。
最短で復旧する：実行順チェックリスト
まずは下の表の順で作業してください。上から順に実行することで、プロキシ・フック・証明書・キャッシュ・時間ずれといった“TLS が失敗する主要因”を体系的に外していきます。
| 手順 | 内容 | 解説・補足 |
|---|---|---|
| 1 | プロキシ設定を初期化netsh winhttp reset proxy | 不要なシステム（WinHTTP）プロキシをリセット。開発時の一時設定やツールが残りやすい。 |
| 2 | Winsock カタログを再構築netsh winsock reset → 再起動 | パケットキャプチャ／セキュリティドライバなどの LSP フックをすべて外す。 |
| 3 | HTTPS 接続テスト PowerShell で Invoke-WebRequest https://www.microsoft.com -UseBasicParsing | ここで失敗する場合は OS レベルの TLS 障害が確定。プロキシ／証明書の見直しに進む。 |
| 4 | ルート証明書を確認certutil -store root > "%UserProfile%\Desktop\root_certs.txt" | 出力一覧から Microsoft／DigiCert／GlobalSign 等の大手以外で心当たりのないものを特定。mitmproxy／企業フィルタリング系の自己署名 CA があれば削除。 |
| 5 | Store キャッシュを初期化wsreset | 証明書やプロキシを正した後も失敗する場合、キャッシュ破損を排除。 |
| 6 | 日時設定の確認 | 数分のズレでも TLS 検証は失敗しうる。NTP 同期とタイムゾーンを見直す。 |
| 7 | システムファイル検査sfc /scannow → DISM /Online /Cleanup-Image /RestoreHealth | 証明書ストアや WinHTTP 関連の破損が疑われるときに実施。 |
| 8 | セキュリティソフト／ネットワーク監視ツールの一時停止・アンインストール | HTTPS へ割り込む機能（スキャン・検査）が有効だと証明書が挿入され TLS が失敗。 |
| 9 | 再テスト：Microsoft Store／WSL インストール | 1–8 を済ませたら再度アプリのインストールや wsl --update を試して成功を確認。 |
CLI と GUI の“どちらのプロキシ”を直しているかを理解する
Windows には大きく分けて「WinINET（主に GUI アプリ）」と「WinHTTP（主にサービス・CLI）」の 2 系統のプロキシがあります。Microsoft Store や WSL は WinHTTP の影響を強く受けるため、netsh winhttp reset proxy が効きます。必要に応じて WinINET 側の確認も行いましょう。
- WinHTTP の確認：
netsh winhttp show proxy - WinINET（インターネットオプション）の確認：
［インターネットオプション］→［接続］→［LAN の設定］→「プロキシ サーバー」をオフ - 環境変数ベースのプロキシ確認（開発ツールが設定しがち）：
set http_proxy/set https_proxy
各手順の詳細と背景知識
1. プロキシ設定の初期化（WinHTTP）
管理者としてコマンドプロンプトまたは PowerShell を開き、以下を実行します。
netsh winhttp reset proxy
netsh winhttp show proxy 出力が 直接アクセス (プロキシ サーバーなし) のようになれば OK。過去に netsh winhttp set proxy 127.0.0.1:8080 等を入れていた場合、その残骸が消えます。
2. Winsock リセット（LSP/フィルタの排除）
ネットワークスタックに挿し込まれた LSP（レイヤードサービスプロバイダ）やフィルタドライバが TLS を邪魔している可能性を排除します。
netsh winsock reset
shutdown /r /t 0 再起動後に症状が改善するかを確認。なお、netsh int ip reset で TCP/IP パラメータを初期化するのも有効です。
3. HTTPS 接続の基本健診
PowerShell で単純な GET を投げ、OS レベルの TLS 障害かどうかを切り分けます。
Invoke-WebRequest https://www.microsoft.com -UseBasicParsing
エラーが出る場合、より具体的なチェックとしてポート 443 の到達性を確認します。
Test-NetConnection -ComputerName [www.microsoft.com](http://www.microsoft.com) -Port 443 ここで通らないならネットワーク機器や回線側の問題の可能性も視野に。通るのにエラーが続くなら証明書・プロキシ・時間の問題です。
4. ルート証明書ストアの健全性チェック
自己署名のルート証明書が混入していないかを確認します。
certutil -store root > "%UserProfile%\Desktop\root_certs.txt"
notepad "%UserProfile%\Desktop\root_certs.txt" ファイル内を検索し、以下に当てはまるものを重点的に確認・削除します（削除は certmgr.msc または mmc.exe で［証明書］スナップインを追加）。
- 発行者名に「mitm」「proxy」「inspection」「sandbox」「dev」「corp」等の文言が含まれる。
- 個人名や社内ツール名が CN に入っている。
- 公開鍵長・署名アルゴリズムが異常に弱い、または有効期限が極端に長い。
企業ドメイン参加 PC ではグループポリシーで自動配布されることがあります。勝手に削除できない場合は、IT 管理者ポリシーを確認してください。
| 削除候補になりやすい証明書の例 | 見分け方のヒント |
|---|---|
| mitmproxy のルート CA | 発行者／サブジェクトに「mitmproxy」。拇印（Thumbprint）が手元の mitmproxy で生成したものと一致する。 |
| セキュリティ製品の HTTPS 検査 CA | 製品名＋「Root CA」「SSL Inspection」等。セキュリティ製品の設定で HTTPS 検査を無効化してから削除。 |
| 社内プロキシ用の自己署名 CA | 発行者に社名・部門名。ドメイン参加 PC はポリシー配布の可能性あり。 |
5. Microsoft Store キャッシュ初期化
証明書やプロキシを正した後は、Store のキャッシュをクリアして動作をリセットします。
wsreset
必要に応じて Store アプリの再登録も行います（管理者 PowerShell）。
Get-AppxPackage -AllUsers Microsoft.WindowsStore | `
ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"} 6. 日付・時刻・タイムゾーンの正確性
TLS は証明書の有効期限・失効情報に敏感です。数分のズレでも失敗することがあります。以下で確認・修正。
w32tm /query /status
w32tm /resync
tzutil /g
tzutil /s "Tokyo Standard Time" 7. システムファイルの整合性回復
証明書ストアや WinHTTP に関わるコンポーネントが破損している可能性を排除します。管理者 PowerShell で実行。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth 8. セキュリティ／監視ツールの一時停止・アンインストール
HTTPS スキャンやトラフィック検査機能は、結果的に MITM と同じ挙動をとります。リアルタイム保護を一時停止した上で、ネットワーク関連ドライバやブラウザ拡張の無効化も検討してください。改善したら、対象機能だけを恒久的にオフにするか、例外に Microsoft の配信ドメインを追加します。
9. 再テスト（Store／WSL／winget）
作業後、以下を再試行します。
- Microsoft Store からの任意の UWP アプリのインストール／更新。
- WSL の更新：
wsl --updateまたはwsl --update --web-download - winget のパッケージ取得（必要に応じてソースのリセット）。
winget source reset --forcewinget source update
トラブルが残る場合の追加策
ルート証明書のリセット（高度）
どうしても不整合が取れない場合、ルートストアを既定に戻すアプローチがあります。企業ドメイン PC は必ずポリシーを確認のうえで実施してください。
- Windows の証明書 MMC スナップイン（ローカル コンピュータ／現在のユーザー）で「信頼されたルート証明機関」を見直し、不要な CA を撤去。
- 更新ルートの再取得：
certutil -generateSSTFromWU "%UserProfile%\Desktop\roots.sst"（ネットワーク要）。
Microsoft アカウントの再サインイン／Store 再登録
トークン取得の不整合に備えて、Store アプリからサインアウト→サインインを行い、前述の再登録コマンドも併用します。
ネットワーク機器側の MTU／DNS 変更
まれにルーターや UTM のフィルタで TLS フレームが破棄されることがあります。MTU を確認し、断片化が疑われるときは調整します。
netsh interface ipv4 show subinterfaces
ping -f -l 1472 8.8.8.8 DNS を変更して名前解決の信頼性を確保するのも有効です。
原因の本丸：mitmproxy 等が残した“証明書とプロキシ”の影響を断つ
開発や検証のために mitmproxy・Fiddler・Burp Suite などのツールを導入すると、HTTPS を中間解読するための自己署名 CA が OS にインポートされ、さらにブラウザやシステムのプロキシ設定が書き換えられます。アンインストール後も証明書・プロキシは残りやすく、Windows のサービスや CLI（Store／winget／WSL）がその設定を参照して失敗します。
| 項目 | 影響 | 対処 |
|---|---|---|
| 自己署名ルート CA の残存 | サーバー証明書の検証が想定外のチェーンで行われ、失敗または MITM 経路へ誘導。 | ルートストアから該当 CA を削除。必要なら更新ルートの再取得。 |
| WinHTTP プロキシの残存 | Store／WSL／サービスがローカル MITM へ接続、検証失敗。 | netsh winhttp reset proxy で初期化。 |
| フィルタドライバ／LSP | TLS レコードを改変、SNI／ALPN 交渉失敗等を誘発。 | netsh winsock reset の後、不要ドライバをアンインストール。 |
企業ネットワーク・ドメイン参加 PC の注意点
企業環境では、グループポリシー経由で「信頼されたルート証明機関」へ社内 CA が配布され、HTTPS 検査が義務化されている場合があります。個人判断で削除しても再配布される、あるいは接続が拒否されることがあるため、管理部門に以下を確認します。
- Store／WSL／Windows Update ドメインの HTTPS 検査をバイパスできるか。
- WinHTTP プロキシ設定の配布内容と例外（DirectAccess など）をどう定義しているか。
- 証明書配布・失効リスト（CRL／OCSP）への到達性が確保されているか。
ローカルでの確認ポイント：
- ローカル グループポリシーエディター：
［コンピュータの構成］→［Windows の設定］→［セキュリティの設定］→［公開キーのポリシー］→「信頼されたルート証明機関」 - ポリシー適用状況レポート：
gpresult /h "%UserProfile%\Desktop\gp.html"
ログと診断を活用する（再現性のないときこそ）
一度直ったのに再発する、端末によって再現したりしなかったりする──この場合はログを取って実体を掴むのが近道です。
- イベント ビューアー →［Windows ログ］→［システム］→「Schannel」イベント：証明書検証やハンドシェイクの失敗を記録。
- PowerShell の詳細ログ：
$ErrorView = 'DetailedView'を設定すると IWR の例外詳細が見やすい。 - トレース（高度）：
netsh trace start capture=yes scenario=InternetClientでネットワークトレースを取得し、再現後にnetsh trace stop。
誤解しがちなポイント（やりがちな遠回り）
- 「Windows をクリーンインストールしたのに直らない」：ルーターや UTM の HTTPS 検査、あるいはドメイン参加時のポリシー配布が原因のときは OS 初期化では解決しません。
- 「DNS を変えればすべて解決」：名前解決は要素のひとつに過ぎません。TLS 失敗の本質は証明書チェーンと経路の信頼性です。
- 「ブラウザが見られるなら問題ない」：Edge 等の GUI は WinINET、Store／WSL／winget は WinHTTP。片方だけ直ってもう片方が壊れているパターンが多い。
便利なコマンド早見表（コピーして使える）
| 目的 | コマンド | 補足 |
|---|---|---|
| WinHTTP プロキシの確認 | netsh winhttp show proxy | 「直接アクセス」になっていなければ要リセット。 |
| WinHTTP プロキシのリセット | netsh winhttp reset proxy | 開発ツールの残存設定を一掃。 |
| Winsock リセット | netsh winsock reset | 再起動必須。LSP を外す。 |
| HTTPS 到達性テスト | Invoke-WebRequest https://www.microsoft.com -UseBasicParsing | 失敗なら TLS 障害確定。 |
| TCP 443 の疎通 | Test-NetConnection www.microsoft.com -Port 443 | 到達性を数値で把握。 |
| ルート証明書の一覧保存 | certutil -store root > "%UserProfile%\Desktop\root_certs.txt" | 差分比較に便利。 |
| Store キャッシュ初期化 | wsreset | 再登録は別途コマンドあり。 |
| Store の再登録 | Get-AppxPackage -AllUsers Microsoft.WindowsStore | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"} | 管理者 PowerShell で実行。 |
| 時間同期 | w32tm /resync | タイムゾーンは tzutil で。 |
| システム整合性の回復 | sfc /scannow → DISM /Online /Cleanup-Image /RestoreHealth | 破損による不具合を除外。 |
ケーススタディ：復旧までの思考プロセス
以下は、実環境での復旧プロセスを抽象化したモデルケースです。
- Store でインストール失敗。UI には
0x800704cf。CLI ログに0x80072f7d。 - ブラウザは普通に Web を閲覧できるためネットワーク自体は生きていると判断。
netsh winhttp show proxyを確認するとローカルホストのプロキシが設定済み。resetで初期化。- 改善せず。
netsh winsock reset→ 再起動。 Invoke-WebRequestが「証明書エラー」で停止。certutil -store rootで一覧を出すと mitmproxy のルート CA が残存。- MMC の証明書スナップインで該当 CA を削除。セキュリティソフトの HTTPS 検査をオフ。
wsreset実行。Store で再試行 → 成功。wsl --updateも完了。
再発防止のための運用 Tips（開発・検証で MITM を使う場合）
- 検証用の「一時プロファイル」や「開発用 VM／コンテナ」に限定して MITM ツールを使用する。本番端末にインストールしない。
- ツール導入時の変更点（インポートした CA、設定したプロキシ、導入したドライバ）をメモ化し、撤去の逆手順を用意する。
- セキュリティ製品で HTTPS 検査を使う場合、Microsoft Store／Windows Update／WSL 関連のドメインは検査対象から除外する。
- 定期的に
certutil -store rootの出力を保存し、差分チェックで不審な CA を早期発見する。
まとめ
Microsoft Store／WSL のインストール失敗で表示される 0x800704cf（実際は 0x80072f7d）は、ほぼ確実に TLS の確立失敗と考えてよい症状です。根本原因は、ネットワークの暗号化レイヤーに介入するツールが残した「プロキシ設定」や「自己署名のルート証明書」であることが多く、次の 4 アクションが特に有効です。
- 通信経路のリセット：
netsh winhttp reset proxy、netsh winsock reset。 - 信頼ストアの健全化：
certutil -store rootで不審な CA を特定し削除。 - 時間の正確性：時刻とタイムゾーンの同期。
- キャッシュ・破損の排除：
wsresetとsfc／DISM。
これらを実施すれば、Microsoft Store と WSL の双方でエラーが解消するケースが大半です。開発・検証で MITM を使う際は、端末を分ける・設定の撤去手順を確立するなど、運用面の工夫で再発を防止しましょう。
コメント