RDPの信頼された発行元をSHA-1からSHA-256へ移行する手順【Windows 11】

RDPの信頼された発行元をSHA-1からSHA-256へ移行する際に変更するのは、RDP接続先のTLS証明書だけではありません。2026年7月14日のWindows更新をRDPクライアントへ適用し、信頼された.rdp発行元のポリシーに、署名証明書のSHA-256以上のサムプリントを追加します。

移行期間中は既存のSHA-1サムプリントを残し、すべてのクライアントが更新済みであることを確認してから削除する方法が安全です。Microsoftは7月更新でSHA-2サムプリント対応を追加していますが、ポリシーの登録内容が自動的にSHA-256へ変換されるわけではありません。(Microsoft Support)

結論：RDP発行元設定で変更する項目

移行作業の要点は、次のとおりです。

変更対象	移行前	移行後
RDPクライアント	2026年7月更新より前	対象となる2026年7月更新以降
ポリシー名	`Specify SHA1 thumbprints of certificates representing trusted .rdp publishers`	`Specify thumbprints of certificates representing trusted .rdp publishers`
証明書識別子	SHA-1サムプリント	SHA-256以上のサムプリント
SHA-1の扱い	信頼判定に使用	移行期間のみ併記し、最終的に削除
設定対象	RDPサーバーだけを意識しがち	`.rdp`ファイルを開くクライアント端末
証明書の再発行	常に必要と思われやすい	同じ有効な証明書を使うなら、原則として必須ではない

Microsoftは、更新後も後方互換性のためSHA-1を受け付けます。ただし、SHA-1は非推奨であり、将来のWindowsリリースではサポートを削除する予定としています。したがって、SHA-1を残したまま運用を固定するのではなく、SHA-256以上へ段階的に移行する必要があります。(Microsoft Learn)

対象となるWindows 11のバージョンと更新プログラム

今回のSHA-2対応は、次の2026年7月14日更新で追加されています。

Windows 11	OSビルド	更新プログラム
バージョン23H2	22631.7376	KB5099414
バージョン24H2	26100.8875	KB5101650
バージョン25H2	26200.8875	KB5101650
バージョン26H1	28000.2525	KB5101649

26H1は、実際にそのバージョンを利用している検証環境や先行環境など、該当する場合のみ対象です。運用端末については、表に記載したビルド、または変更を含む後続の累積更新が適用されていることを確認してください。(Microsoft Support)

OSビルドは、次のPowerShellで確認できます。

$os = Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

[PSCustomObject]@{
    ProductName    = $os.ProductName
    DisplayVersion = $os.DisplayVersion
    OSBuild        = "$($os.CurrentBuild).$($os.UBR)"
}

表示されたOSBuildが、対象バージョンに対応するビルド以上になっているかを確認します。

最初に理解しておきたい3つの違い

RDPサーバー証明書と`.rdp`発行元証明書は別物

今回変更するのは、主に.rdpファイルの署名に使われる発行元証明書の識別方法です。

RDP環境では、次の証明書が混同されやすいため注意してください。

証明書	主な役割
RDPリスナー証明書	RDPクライアントと接続先の通信を保護する
RD Gateway証明書	RD GatewayとのHTTPS通信を保護する
`.rdp`署名証明書	配布された`.rdp`ファイルの発行元と改ざんの有無を確認する
RD Publishing証明書	RemoteAppやデスクトップ接続の公開時に署名する

信頼されたRDP発行元ポリシーへ登録するのは、通常、.rdpファイルを署名した証明書のサムプリントです。RDPリスナー証明書のサムプリントを登録しても、その証明書で.rdpファイルを署名していなければ期待した信頼判定にはなりません。Microsoftは、手動署名にはrdpsign.exe、RDSコレクションではRD Publishing証明書を利用する方法を案内しています。(Microsoft Learn)

証明書の署名アルゴリズムとサムプリントは同じではない

証明書の詳細画面に次のように表示されていても、ポリシー移行が完了したとは限りません。

署名ハッシュ アルゴリズム: sha256
署名アルゴリズム: sha256RSA

これらは、証明書を発行した認証局が証明書へ署名した際のアルゴリズムです。一方、サムプリントは証明書そのものを識別するために計算したハッシュ値です。

さらに、Windowsや.NETの一般的なThumbprintプロパティはSHA-1サムプリントを返します。そのため、証明書のGUIで「拇印」や「Thumbprint」をコピーしただけでは、SHA-256移行に必要な値を取得できない場合があります。SHA-256サムプリントは、証明書の生データから別途計算します。(Microsoft Learn)

更新が必要なのは`.rdp`ファイルを開くクライアント

信頼された発行元の判定は、.rdpファイルを開くRemote Desktop Connection Client側で行われます。

したがって、次のような対応では不十分です。

RD Session Hostだけを更新する
RD Gatewayだけを更新する
Connection Brokerだけを更新する
.rdpファイルを生成する管理サーバーだけを更新する

社員PC、VDI、管理端末、踏み台端末など、実際に.rdpファイルを開く端末へ更新を適用してください。(Microsoft Learn)

SHA-1からSHA-256へ移行する手順

既存の署名証明書と配布経路を棚卸しする

最初に、現在使われている証明書と.rdpファイルの配布方法を確認します。

最低限、次の項目を記録してください。

確認項目	確認する内容
`.rdp`ファイルの生成元	RDS、RemoteApp、管理者による手動作成など
署名方法	RD Publishing、`rdpsign.exe`、配布ツールなど
証明書の保存場所	ローカルコンピューターまたは現在のユーザー
証明書の件名	どの発行元証明書か
有効期限	移行直後に期限切れにならないか
現在のSHA-1	既存ポリシーとの照合用
配布対象	どのOU、端末、ユーザーが利用しているか
GPOの設定場所	コンピューター構成かユーザー構成か

証明書を更新中の場合は、旧証明書と新証明書の両方を棚卸しします。証明書の切り替えとSHA-256移行を同時に実施すると、問題の原因を切り分けにくくなるためです。

対象クライアントへ7月更新を適用する

最初から全端末へ一斉展開せず、代表的な端末を含むパイロットOUを作成します。

パイロットには、少なくとも次の端末を含めます。

通常のWindows 11クライアント
管理者が利用する踏み台端末
RemoteAppを利用する端末
ドライブやクリップボードをリダイレクトする端末
ユーザー構成のGPOも適用される端末
異なるWindows 11バージョンが混在している場合は各バージョンの端末

更新後、OSビルドを確認し、Remote Desktop Connection Clientを一度終了してから再起動します。

署名証明書のSHA-256サムプリントを計算する

SHA-1サムプリントの文字列をSHA-256で再ハッシュしてはいけません。

正しいSHA-256サムプリントは、元の証明書データから計算します。SHA-1の40桁の文字列を変換したり、末尾へ文字を追加したりして64桁にすることはできません。

次の例は、Windows PowerShell 5.1でも利用できる計算方法です。

$cert = Get-Item `
  'Cert:\LocalMachine\My\<現在のSHA-1サムプリント>'

$sha256 = [System.Security.Cryptography.SHA256]::Create()

try {
    ($sha256.ComputeHash($cert.RawData) |
        ForEach-Object { $_.ToString('X2') }) -join ''
}
finally {
    $sha256.Dispose()
}

<現在のSHA-1サムプリント>には、対象証明書の現在のSHA-1サムプリントを空白なしで指定します。

証明書がユーザー証明書ストアにある場合は、パスを次のように変更します。

Cert:\CurrentUser\My\<現在のSHA-1サムプリント>

正常に計算できると、SHA-256の場合は64桁の16進数が表示されます。登録前に、次の点を確認してください。

対象の証明書を取り違えていない
件名と有効期限が想定どおり
署名に使用している証明書と一致している
出力値に空白、改行、不可視文字が入っていない
SHA-1サムプリントの文字列を再ハッシュしていない

更新後のグループポリシーへSHA-256を追加する

グループポリシー管理エディターで、次の場所を開きます。

コンピューターの構成
  └ 管理用テンプレート
     └ Windows コンポーネント
        └ リモート デスクトップ サービス
           └ リモート デスクトップ接続クライアント

対象となるポリシーは、更新後の次のポリシーです。

Specify thumbprints of certificates representing trusted .rdp publishers

2026年7月更新より前は、次の名称でした。

Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

更新後はポリシー名からSHA1が外れ、SHA-2サムプリントを登録できるようになります。(Microsoft Learn)

ポリシーを有効にし、先ほど取得したSHA-256サムプリントを追加します。

ここで重要なのが、更新後のポリシーの［ヘルプ］欄に示されるアルゴリズム接頭辞と入力形式に従うことです。Microsoftの案内では、SHA-2の登録方法と必要な接頭辞は、更新されたポリシーのヘルプで確認するよう示されています。接頭辞なしの64桁を推測で登録したり、独自にSHA256:などの形式を作ったりしないでください。(Microsoft Learn)

移行期間はSHA-1とSHA-256を併記する

クライアントの更新状況が混在している間は、既存のSHA-1サムプリントをすぐに削除しないでください。

推奨する展開段階は次のとおりです。

段階	ポリシーの登録内容	完了条件
準備	SHA-1のみ	証明書と対象端末の棚卸し完了
パイロット	SHA-1とSHA-256を併記	代表端末で接続試験完了
全体展開	SHA-1とSHA-256を併記	全対象クライアントが更新済み
移行完了	SHA-256のみ	SHA-1依存端末が存在しない

旧クライアントでは、SHA-2形式の項目を正しく解釈できない可能性があります。移行期間にSHA-1を残すことで、未更新端末の接続を維持しながら更新済み端末をSHA-256へ切り替えられます。

ただし、SHA-1の併記は恒久対策ではありません。Microsoftは後方互換性のためにSHA-1を残しているだけで、将来削除する予定としています。(Microsoft Learn)

ポリシー	移行中の推奨	強化後の例
信頼された`.rdp`発行元のサムプリント	SHA-1とSHA-256を併記	SHA-256以上のみ
有効な発行元の`.rdp`ファイルと既定設定を許可	現行設定を維持	無効
不明な発行元の`.rdp`ファイルを許可	現行設定を維持	無効

GPOの適用結果を確認する

ポリシー更新後、パイロット端末で次を実行します。

gpupdate /force

続いて、適用結果のレポートを作成します。

gpresult /h C:\Temp\rdp-policy.html

作成されたHTMLを開き、次の点を確認します。

想定したGPOが適用されている
別のGPOで設定が上書きされていない
コンピューター構成とユーザー構成の適用先を取り違えていない
セキュリティフィルターやWMIフィルターで除外されていない
ループバック処理による想定外のユーザー設定がない

信頼された発行元のポリシーは、コンピューター構成とユーザー構成の両方に存在します。両方を構成した場合、登録されたサムプリントの一覧は組み合わせて扱われます。組織全体へ一貫した設定を配布する場合は、コンピューター構成を基本とし、ユーザー構成は限定的な例外に利用すると管理しやすくなります。(Microsoft Learn)

動作確認で実施すべきテスト

正常なファイルを1回開くだけでは、設定ミスを見逃します。正常系と異常系を組み合わせて確認してください。

テスト	操作	期待する結果
信頼済み発行元	登録した証明書で署名された`.rdp`を開く	想定どおり接続できる
未署名ファイル	署名されていない`.rdp`を開く	ポリシーに応じて警告またはブロック
別の発行元	未登録証明書で署名された`.rdp`を開く	ポリシーに応じて警告またはブロック
改ざん試験	署名後の`.rdp`を複製し、設定を変更する	署名が無効として扱われる
リダイレクト	ドライブ、クリップボード、プリンターを要求する	許可したファイルだけ想定どおり動作
手動接続	`mstsc.exe`から接続先を直接入力する	強化後の許可方針と一致する
証明書更新	新旧証明書で署名したファイルを開く	移行期間中は両方が利用可能

信頼された発行元として一致すると、該当する.rdpファイルのセキュリティ警告や、要求されたリダイレクト設定の扱いが変わります。そのため、接続できるかだけでなく、ドライブやクリップボードなどのリダイレクトも確認する必要があります。(Microsoft Learn)

証明書の再署名が必要になるケース

同じ有効な署名証明書を使い続ける場合、ポリシーに登録する識別子をSHA-1からSHA-256へ変更するだけで済むケースが基本です。

SHA-256サムプリントは、同じ証明書を別のハッシュアルゴリズムで識別した値です。サムプリントをSHA-256へ変えるためだけに、必ずしも証明書を再発行したり、すべての.rdpファイルを再署名したりする必要はありません。

一方、次の場合は再発行または再署名を検討します。

署名証明書が期限切れになっている
証明書が失効している
証明書または証明書チェーン自体がSHA-1署名を使用している
新しい証明書へ更新する
.rdpファイルの内容を変更した
署名時の秘密鍵が失われた
誤った証明書で署名していた
発行元名やPKI構成を変更する

.rdpファイルは署名後に接続先、リダイレクト、ゲートウェイ設定などを変更すると、署名の整合性が失われます。ファイルを更新した場合は、配布前に改めて署名してください。

証明書チェーンの信頼も別途確認する

信頼されたRDP発行元ポリシーへサムプリントを登録することと、証明書チェーンをクライアントが信頼することは別の設定です。

社内認証局や自己署名証明書を利用する場合は、クライアント側で次も確認します。

ルート認証局証明書が信頼されている
中間認証局証明書を検証できる
証明書が失効していない
CRLまたはOCSPへ到達できる
有効期間内である
署名した証明書と登録したサムプリントが一致している

サムプリントだけを許可リストへ追加しても、証明書チェーンの検証に失敗すれば、期待した発行元として扱われない可能性があります。

古い管理用テンプレートが表示される場合の対処

クライアントを更新したにもかかわらず、グループポリシー管理エディターで旧名称が表示される場合は、ドメインのCentral Storeに古いADMX／ADMLファイルが残っている可能性があります。

この問題では、次の2つを分けて考えます。

要素	役割
Windowsクライアントの更新	SHA-2サムプリントを実際に解釈する
管理用テンプレートの更新	新しいポリシー名、説明、入力形式をGPMCへ表示する

更新済み端末のローカルグループポリシーでは新しい名称が表示される一方、ドメインGPOの編集画面では古い名称が表示される場合、Central Storeのテンプレートを確認してください。

Central Storeを更新する際は、次の手順を推奨します。

現在のCentral Storeをバックアップする
検証用のコピーを作成する
TerminalServer.admxと対応言語の.admlの差分を確認する
GPMCで新しい名称とヘルプが表示されることを確認する
既存GPOへ影響がないことを確認してから本番へ反映する

Microsoftは、管理用テンプレートのパッケージをCentral Store用として扱い、ローカル端末のC:\Windows\PolicyDefinitionsを安易に置き換えないよう案内しています。テンプレート更新は、既存ファイルを直接上書きするのではなく、バックアップと検証を行ってから実施してください。(Microsoft Learn)

移行で失敗しやすいポイント

証明書画面の「拇印」をそのまま登録する

証明書画面やPowerShellの通常のThumbprintは、SHA-1であることが一般的です。

64桁のSHA-256値を、証明書の生データから計算してください。見た目が16進数であっても、40桁ならSHA-1です。

SHA-1の文字列をSHA-256でハッシュする

SHA-256は、元の証明書データから計算します。

次の処理は誤りです。

SHA256("既存のSHA-1サムプリント文字列")

この値は、証明書のSHA-256サムプリントとは一致しません。

SHA-256の接頭辞を推測する

更新後のポリシーでは、SHA-2サムプリントの入力形式と接頭辞をポリシーのヘルプで確認します。

Web上の非公式な設定例や、別製品のSHA256:形式をそのまま流用せず、実際に導入したADMX／ADMLのヘルプを基準にしてください。

RDPサーバーだけを更新する

判定するのは.rdpファイルを開くクライアントです。

サーバー側の更新が完了していても、利用者PCや管理端末が未更新なら、SHA-2サムプリントによる信頼判定へ移行できません。

全端末の更新前にSHA-1を削除する

端末の更新状況を資産管理ツールや更新管理基盤で確認せず、先にSHA-1を削除すると、未更新端末だけ接続できなくなる可能性があります。

削除条件は「更新を配信した」ではなく、対象端末で必要なOSビルドが確認できたことにします。

証明書更新とポリシー移行を一度に行う

署名証明書を新しくし、SHA-256サムプリントへ変更し、関連する許可ポリシーも厳格化すると、障害が発生した際に原因を判断しにくくなります。

次の順番に分けると安全です。

クライアントを更新する
同じ証明書のSHA-256を追加する
接続を検証する
必要に応じて証明書を更新する
関連ポリシーを厳格化する
SHA-1を削除する

警告を消すことだけを目的にする

信頼された発行元ポリシーは、単なる警告非表示機能ではありません。

信頼済みの.rdpファイルでは、ドライブ、クリップボード、プリンターなどのリダイレクト要求も扱われます。警告を消すために広範囲の証明書を登録すると、意図しない接続設定まで許可する可能性があります。

登録するのは、自組織が管理し、用途と秘密鍵の管理者を特定できる証明書に限定してください。

SHA-1を削除するための完了条件

次の条件をすべて満たした段階で、SHA-1サムプリントをポリシーから削除します。

対象となるRDPクライアントをすべて把握している
各端末に対象の2026年7月更新以降が適用されている
SHA-256サムプリントが正しい証明書から計算されている
更新後のポリシーヘルプに従った形式で登録されている
信頼済み.rdpファイルの接続試験が完了している
未署名、別発行元、改ざん済みファイルの試験が完了している
RemoteAppやRD Gatewayを含む実運用経路を確認している
証明書チェーンが各クライアントで信頼されている
ロールバック用のGPOバックアップがある
古い証明書を利用する配布物が残っていない

まずは代表端末を含むパイロットOUへ7月更新を適用し、既存の署名証明書からSHA-256サムプリントを計算してください。その値をSHA-1と併記して正常系・異常系の接続試験を行い、全クライアントの更新確認後にSHA-1を削除すれば、安全にRDPの信頼された発行元をSHA-2へ移行できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

RDPの信頼された発行元をSHA-1からSHA-256へ移行する手順【Windows 11】

結論：RDP発行元設定で変更する項目

対象となるWindows 11のバージョンと更新プログラム

最初に理解しておきたい3つの違い

RDPサーバー証明書と`.rdp`発行元証明書は別物

証明書の署名アルゴリズムとサムプリントは同じではない

更新が必要なのは`.rdp`ファイルを開くクライアント

SHA-1からSHA-256へ移行する手順

既存の署名証明書と配布経路を棚卸しする

対象クライアントへ7月更新を適用する

署名証明書のSHA-256サムプリントを計算する

更新後のグループポリシーへSHA-256を追加する

移行期間はSHA-1とSHA-256を併記する

関連ポリシーは段階的に強化する

GPOの適用結果を確認する

動作確認で実施すべきテスト

証明書の再署名が必要になるケース

証明書チェーンの信頼も別途確認する

古い管理用テンプレートが表示される場合の対処

移行で失敗しやすいポイント

証明書画面の「拇印」をそのまま登録する

SHA-1の文字列をSHA-256でハッシュする

SHA-256の接頭辞を推測する

RDPサーバーだけを更新する

全端末の更新前にSHA-1を削除する

証明書更新とポリシー移行を一度に行う

警告を消すことだけを目的にする

SHA-1を削除するための完了条件

この記事を書いた人

コメント

コメントするコメントをキャンセル

RDPの信頼された発行元をSHA-1からSHA-256へ移行する手順【Windows 11】

結論：RDP発行元設定で変更する項目

対象となるWindows 11のバージョンと更新プログラム

最初に理解しておきたい3つの違い

RDPサーバー証明書と.rdp発行元証明書は別物

証明書の署名アルゴリズムとサムプリントは同じではない

更新が必要なのは.rdpファイルを開くクライアント

SHA-1からSHA-256へ移行する手順

既存の署名証明書と配布経路を棚卸しする

対象クライアントへ7月更新を適用する

署名証明書のSHA-256サムプリントを計算する

更新後のグループポリシーへSHA-256を追加する

移行期間はSHA-1とSHA-256を併記する

関連ポリシーは段階的に強化する

GPOの適用結果を確認する

動作確認で実施すべきテスト

証明書の再署名が必要になるケース

証明書チェーンの信頼も別途確認する

古い管理用テンプレートが表示される場合の対処

移行で失敗しやすいポイント

証明書画面の「拇印」をそのまま登録する

SHA-1の文字列をSHA-256でハッシュする

SHA-256の接頭辞を推測する

RDPサーバーだけを更新する

全端末の更新前にSHA-1を削除する

証明書更新とポリシー移行を一度に行う

警告を消すことだけを目的にする

SHA-1を削除するための完了条件

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

RDPサーバー証明書と`.rdp`発行元証明書は別物

更新が必要なのは`.rdp`ファイルを開くクライアント

コメントするコメントをキャンセル