Windowsのリモートデスクトップで「Root Certificate is Not Trusted」エラーを直す方法：原因から安全な対処まで

リモートデスクトップ接続（RDP／RDC）で突然「Root Certificate is Not Trusted（ルート証明書が信頼されていません）」のようなSSL証明書エラーが出ると、接続できないだけでなく「このまま進めて大丈夫なのか？」という不安も残ります。
このエラーは、証明書の仕組みとWindows側の信頼ストア、そしてRDP関連（RD Web／RD Gateway含む）の構成が噛み合っていないときに起こりがちです。この記事では、よくある原因を整理し、現場で安全に復旧するための手順を、順番にわかりやすくまとめます。

Windowsのリモートデスクトップで「Root Certificate is Not Trusted」エラーを直す方法：原因から安全な対処まで

「Root Certificate is Not Trusted」とは何が起きているのか

証明書（SSL/TLS）は、通信相手が本物であることを確認するための仕組みです。証明書は通常、以下の“鎖（チェーン）”で信頼が成立します。

サーバー証明書（接続先が提示する証明書）
中間証明書（CAが発行する中継）
ルート証明書（OSが「信頼してよい」と登録済みの最上位）

このとき、クライアントPC（接続する側のWindows）が、提示された証明書チェーンの最上位（Root）を信頼できないと判断すると、「Root Certificate is Not Trusted」系のエラーになります。

よくある原因（発生パターン別）

1) 自己署名証明書を使っている

社内検証や小規模運用で、RD Web／RD Gateway／RDPに自己署名証明書を当てていると、クライアント側が当然信頼できずエラーになりやすいです。

2) 中間証明書が不足している（チェーン不完全）

サーバー証明書は正しくても、中間証明書をサーバー側が正しく提示できていないと、クライアントはチェーンを完成できず失敗します。

3) ルート証明書が古い／失効している

Windowsのルート証明書ストア更新が止まっている、更新ポリシーが制限されている、古い環境を使っているなどで起こります。

4) 証明書の名前が接続先と一致しない（CN/SAN不一致）

「rdp.example.com」で接続しているのに証明書は「server01.local」向け、など。
この場合は「信頼されていない」以外の警告と併発することもあります。

5) 時刻ずれ（地味に多い）

PCやサーバーの時刻が大きくずれると、証明書の有効期間判定に失敗します。

最優先の確認：安全に切り分けるチェックリスト

作業前に、次を確認すると遠回りを防げます。

接続先の名前（FQDN／IP）と、証明書の対象名（CN/SAN）が一致しているか
クライアントPCの日時が正しいか（自動時刻同期）
エラーが出るのが
- 直接RDP（mstsc）なのか
- RD Web（ブラウザ）なのか
- RD Gateway経由なのか
  を切り分ける（出どころで対処が変わる）

対処法1：まずはWindows側のルート証明書更新を正常化する

「ルートが信頼されない」問題は、クライアント側の信頼ストア更新で改善することがあります。

Windows Updateが止まっていないか確認する
社内環境でWSUS／GPOによりルート更新が制限されていないか確認する
可能なら、最新の更新プログラムを適用する

ポイントは、“証明書を無理やり信頼させる”前に、OS側を正しく最新化することです。運用上の安全性が段違いになります。

対処法2：正規CA（パブリックCA）証明書に置き換える（最も推奨）

もし外部からのアクセスや複数端末で利用するなら、最終的にはこれが一番トラブルが少ないです。

RD Web／RD Gateway／RDPに、パブリックCAの証明書を適用
中間証明書も含めて正しく構成（チェーン完全化）
証明書の対象名は、実際にユーザーが接続するFQDNに合わせる

この方式のメリットは、クライアント側へ個別インストールが不要になり、端末追加やBYODでも破綻しにくい点です。

対処法3：社内CA（AD CSなど）のルート証明書を配布する（社内向けの現実解）

社内閉域で、社内CAを運用している場合は、クライアントへルート証明書を配布して信頼させます。

ルートCA証明書を「信頼されたルート証明機関」に配布
中間CAもある場合は「中間証明機関」に配布
端末が多いならGPO配布が基本

注意点として、個別PCに手動で入れる運用は事故りやすいです。できる限りGPOやMDMで統制しましょう。

対処法4：サーバー側の「中間証明書不足」を直す（見落としやすい）

「ルートが信頼されない」と出ても、実は“中間不足”が原因のことがあります。特にRD Web（IIS）やゲートウェイ周りでは起こりがちです。

サーバー証明書だけでなく、中間証明書を正しくサーバーに入れる
サーバーが接続時にチェーンを提示できる状態にする

ここが直ると、クライアント側で余計な作業が不要になる場合があります。

対処法5：一時回避（推奨しないが事情がある場合）

現場では「とにかく今だけ繋げたい」という状況もあります。ただし、証明書警告を無視する運用は、なりすましや中間者攻撃のリスクを上げます。

どうしても一時対応するなら、次をセットで考えるのが最低限です。

接続先が本物か、別経路（管理画面やIP制限下）で確認
恒久対応（正規証明書適用／CA配布／チェーン修正）の作業を確実に予定化
“無視して良い”を常態化させない（利用者に癖がつくと危険）

失敗しがちな落とし穴

IP直打ちで接続している：証明書はFQDN前提のことが多く不一致になりやすい
複数の役割で別証明書が当たっている：RD WebとGatewayで証明書が別、など
証明書更新後に古いものが残っている：バインド先や設定反映の抜け
PCの時刻ずれ：想像以上に多い

まとめ：最短で安全に直す優先順位

クライアントの日時とWindows Update状況を確認
接続名（FQDN）と証明書の対象名一致を確認
サーバー側の証明書チェーン（中間含む）を正しくする
可能ならパブリックCA証明書へ置き換える
社内運用なら社内CAをGPO/MDMで配布して統制する

「Root Certificate is Not Trusted」は、根本原因を押さえれば再発を大きく減らせます。短期の復旧だけでなく、次の端末追加や更新でも困らない形に整えるのが、結果的に一番コストが下がります。