Windows Server 2019 をドメイン参加のままリネームした直後、NLA 有効の RDP だけが 0x80004005 で失敗することがあります。多くは RDP が提示する SSL 証明書が旧 FQDN のままで、名前不一致で握手が落ちるのが原因です。再発行と差し替えの手順をまとめます。
現象：サーバー名変更後、NLA 有効時だけ RDP が 0x80004005 で失敗する
ドメイン参加済みの Windows Server 2019 をリネーム（サーバー名変更）した後、リモートデスクトップ接続（RDP）で接続できなくなり、クライアント側に 0x80004005 のような汎用エラーが出るケースがあります。
特徴的なのは、NLA（ネットワーク レベル認証）を無効にすると接続できる点です。NLA を無効にした場合は、証明書警告（発行先名が一致しない等）が表示されても、そのままログオン画面まで到達できることがあります。
| 条件 | 結果 | 見え方（典型） |
|---|---|---|
| NLA 有効 | 接続失敗 | 「0x80004005」「接続できません」など。証明書警告が出る前に落ちることも多い。 |
| NLA 無効 | 接続できる場合あり | 証明書の警告が表示されるが、続行するとログオン可能。 |
| FQDN 指定 / 短いホスト名指定 / IP 指定 | いずれも失敗する場合あり | 「名前の指定を変えたのに改善しない」ことで原因が見えづらくなる。 |
管理・運用目的の RDP であっても、ドメイン側で「SSL 必須（証明書配布あり）」のようなポリシー運用をしていると、証明書周りの不整合が 0x80004005 という“よく分からない失敗”として表に出ることがあります。
なぜ NLA 有効時だけ失敗するのか
NLA は、ユーザー名/パスワードのやり取りを含む認証処理を、セッション確立より前の段階で行います。実装としては CredSSP を使い、通信の土台に TLS（SSL）を張ります。
ここで重要なのが、TLS のハンドシェイク時にサーバーが提示する証明書です。クライアントは、接続先として指定した名前（例：newname.example.com）と、証明書の CN/SAN（Subject Alternative Name）に入っている名前が一致しているかを確認します。
証明書の名前が一致しない場合、運用やポリシー次第では「警告を出して続行」ではなく、握手自体を失敗として扱い、そのまま切断されます。NLA を無効にすると、認証処理の流れが変わり、証明書警告を表示できる段階まで進めるため「警告は出るけど入れる」ように見えます。
原因の本命：RDP が使う証明書が旧 FQDN のまま（名前不一致）
サーバーをリネームすると、OS 側のコンピューター名/FQDN、DNS、SPN などが更新されます。一方で、すでにサーバーに入っている証明書は、自動では“発行先名”が書き換わりません。
その結果、RDP が古い証明書（例：oldname.example.com で発行された証明書）を提示し続け、クライアントが新しい名前（newname.example.com）で接続しようとして名前不一致になります。SSL 必須・NLA 必須のような環境では、ここで弾かれて 0x80004005 になりやすい、という構図です。
よくある“試したけど直らない”対処と、その理由
サーバー名変更後の RDP 障害では、つい「ドメイン再参加」「SPN の確認」「RDP-Tcp のリセット」などを先に試しがちです。もちろん状況によっては有効ですが、今回のように “NLA 有効時だけ失敗する”症状では、根本原因が証明書にあるため、下表のように的外れになりやすいです。
| よく試される対処 | 効きにくい理由（証明書起因の場合） | 補足 |
|---|---|---|
| ドメインから外して再参加 | コンピューターアカウントや SPN は整うが、RDP が提示する証明書（旧 FQDN）の差し替えには直結しない。 | 証明書の自動登録が走る環境なら「新証明書が入る」可能性はあるが、RDP への割り当て確認は別途必要。 |
| MachineKeys フォルダーの操作 | 名前不一致は解決しない。むしろ秘密鍵の権限が崩れて TLS 失敗が増えることがある。 | 証明書差し替え後も直らない場合に「秘密鍵の権限」を見る、という順番が安全。 |
| RDP-Tcp のリセット | 設定が初期化されても、SSL 強制環境では“正しい名前の証明書”が無い限り詰む。 | 自己署名証明書に戻ると、ポリシー次第でさらに接続しにくくなる。 |
| SPN の確認（setspn） | Kerberos の問題切り分けには有効だが、証明書で TLS が確立できない場合は、その前段で接続が終わる。 | 「NLA 無効なら入れる」なら、まず証明書を疑うのが近道。 |
| IP アドレス指定で接続 | 証明書に IP が入っていない限り、結局は名前不一致になる（IP 指定で回避できない）。 | 運用は FQDN で統一し、SAN を運用に合わせて設計するのが最も堅い。 |
最短で切り分けるチェックリスト（原因を“証明書”に寄せる）
「サーバー名変更がトリガー」「NLA 無効なら入れる」という条件が揃っている時点で証明書が最有力ですが、作業前に確認しておくと迷いが減ります。
- 同じ端末から NLA の ON/OFF だけを変えて挙動が変わるか（変わるなら TLS/証明書の線が濃い）
- 接続先に FQDN（
newname.example.com）と 短いホスト名（newname）の両方を試し、どちらでも失敗するか - サーバー側イベントログで TLS/Schannel 系のエラーが出ていないか
- サーバーの証明書ストア（ローカル コンピューター）に、新しい名前の証明書が存在するか
- RDP リスナーが参照している証明書のサムプリント（thumbprint）が、旧証明書のままではないか
イベントログは、次あたりが手掛かりになりやすいです（環境によりログ名は差があります）。
- イベント ビューアー → Windows ログ → システム（Schannel、TermService など）
- イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → TerminalServices-RemoteConnectionManager（Operational）
ログ上で「証明書」「TLS」「名前が一致しない」に近い手掛かりが見えれば、やることはほぼ固まります。
解決策：新しい FQDN を含む証明書を再発行し、RDP に差し替える
やるべきことはシンプルで、次の 2 点です。
- 新しい FQDN（必要なら短いホスト名も）を SAN に含めたサーバー証明書を用意する
- RDP（RDP-Tcp リスナー）が その証明書を提示するように割り当てる
手順：証明書の要件を整理する（ここを外すと沼ります）
| 項目 | 推奨 | 理由 / 補足 |
|---|---|---|
| CN / SAN | DNS: newname.example.com を必ず含める。運用で短い名前を使うなら DNS: newname も追加。 | 「接続時に入力する名前」と一致しないと、NLA＋SSL 強制では切断されやすい。 |
| 用途（EKU） | Server Authentication を含む | RDP の TLS でサーバー証明書として使えることが条件。 |
| 秘密鍵 | サーバー上に秘密鍵を保持（エクスポート不要なら不可でよい） | 秘密鍵が無い/アクセスできないと TLS が成立しない。 |
| 格納場所 | ローカル コンピューター → 個人（Personal / My） | 現在のユーザー（Current User）に入れると RDP が参照できない。 |
| 発行元 | 社内 CA / 信頼済みの CA | クライアントが信頼していない CA だと、ポリシー次第で接続できない。 |
ポイントは 「クライアントが何で接続するか」です。運用で短いホスト名（例：newname）を使っているのに、証明書が FQDN しか持っていないと、将来また同じ現象を踏みます。RDP は “接続先名＝証明書名” の一致が前提になるため、運用ルールを決めたうえで SAN を設計するのが安全です。
手順：社内 CA（AD CS など）で新しい名前の証明書を発行する
証明書配布を GPO/自動登録（Autoenrollment）で回している環境では、リネーム後に自動登録が走れば新証明書が入ることもあります。ただし、「入る」ことと「RDP が使う」ことは別なので、必ず次の手順で割り当てを確認します。
- テンプレートは RDP 用（Server Authentication を含む）を使用
- SAN に
newname.example.com（必要ならnewname）を含めて発行 - 移行期間があり旧名でも接続する可能性があるなら、旧 FQDN を SAN に一時的に残すのも選択肢（ただし運用設計は要注意）
自動登録を手動で促す場合は、次が有効です。
gpupdate /force
certutil -pulse手順：サーバーに新証明書が入ったことを確認する
GUI で確認する場合は、サーバーで次を開きます。
- certlm.msc（ローカル コンピューターの証明書）
- 個人 → 証明書
PowerShell で「新しい名前が SAN に入っているか」を確認する例です。
Get-ChildItem Cert:\LocalMachine\My |
Sort-Object NotAfter -Descending |
Select-Object Subject, Thumbprint, NotAfter, @{n='SAN';e={$_.Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Subject Alternative Name'} | ForEach-Object {$_.Format($false)}}} |
Format-Listここで DNS Name=newname.example.com（必要なら DNS Name=newname）が見えていれば、証明書としては合格です。
手順：RDP（RDP-Tcp）が提示する証明書を差し替える
ここが核心です。RDP が使う証明書は、レジストリ（RDP-Tcp リスナーの設定）でサムプリントとして保持されています。新しい証明書を入れただけでは、旧サムプリントが残り続けることがあります。
レジストリの場所
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
SSLCertificateSHA1Hashこの値が指している証明書（thumbprint）が旧名の証明書のままになっていないか確認し、必要なら新証明書に切り替えます。以下は 管理者として実行する前提の PowerShell 例です（newname.example.com は環境に合わせて変更してください）。
# 1) SAN に newname.example.com を含む証明書を選び、Thumbprint を取得
$targetFqdn = 'newname.example.com'
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {
$san = ($_.Extensions |
Where-Object { $_.Oid.FriendlyName -eq 'Subject Alternative Name' } |
ForEach-Object { $_.Format($false) }) -join ' '
$san -match [regex]::Escape($targetFqdn)
} | Sort-Object NotAfter -Descending | Select-Object -First 1
if (-not $cert) {
throw "SAN に $targetFqdn を含む証明書が見つかりません。証明書の発行/自動登録を確認してください。"
}
$thumb = ($cert.Thumbprint -replace ' ', '').ToUpper()
$thumb
# 2) レジストリが要求するバイト配列に変換して設定
$bytes = for ($i=0; $i -lt $thumb.Length; $i += 2) {
[byte]::Parse($thumb.Substring($i, 2), 'HexNumber')
}
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Set-ItemProperty -Path $path -Name 'SSLCertificateSHA1Hash' -Value $bytes証明書が複数並ぶ環境では「最新の 1 枚」を選ぶと外すことがあります。SAN を基準に選ぶ（上の例のように FQDN を含む証明書だけに絞る）と事故が減ります。
手順：TermService を再起動して反映させる
証明書の割り当てを変えても、RDP のサービスが証明書を再読込しないと旧証明書を提示し続けることがあります。メンテナンス可能なタイミングで、サービス再起動または再起動を行います。
# 実行すると RDP セッションが切れる可能性があります（現地作業や別経路の確保が安全）
Restart-Service TermService -Force反映後は、クライアントから newname.example.com で接続し、証明書の発行先が新しい名前になっているかを確認します。
「IP アドレス指定でもダメ」になりやすい理由
証明書の検証は「クライアントが指定した接続先」と照合されます。IP アドレスで接続すると、クライアントは “接続先名＝IP” として検証し、証明書の SAN に IP が入っていない限り名前不一致になります。
つまり、証明書が旧 FQDN で発行されている状態で IP 指定に逃げても、IP も証明書に入っていないため余計に条件が悪化します。RDP は原則として FQDN で接続する設計に寄せた方が運用品質が上がります。
ハマりどころ：証明書を入れ替えても直らないときの追加チェック
「新証明書を入れたのに 0x80004005 が消えない」場合、次の“ありがち”を順に潰すと復旧が早いです。
サーバー側：秘密鍵のアクセス権（TermService が読めない）
証明書に秘密鍵が付いていても、サービスアカウント（多くの場合 SYSTEM/TermService）が秘密鍵を読めないと TLS が成立しません。過去に MachineKeys 周りを触った後などで起きやすいポイントです。
- certlm.msc → 対象証明書 → 右クリック → すべてのタスク → 秘密キーの管理
- SYSTEM（または該当サービス）に読み取り権限があるか確認
権限が崩れている場合は、適切な権限を付け直すか、証明書を作り直してクリーンに戻す方が早いこともあります。
サーバー側：RDP が別の証明書を掴んでいる
自動登録で複数の証明書が入っていると、RDP が意図しない証明書を提示することがあります。SSLCertificateSHA1Hash が新証明書の thumbprint になっているかを必ず確認します。
クライアント側：古い接続情報/証明書情報のキャッシュ
多くの場合、サーバー側が正しい証明書を提示できれば接続は復旧しますが、端末によっては「以前の証明書の指紋」を覚えていて警告や拒否の挙動が変わることがあります。
- レジストリ：
HKCU\Software\Microsoft\Terminal Server Client\Serversの該当サーバー情報 - RDP クライアントのキャッシュ（環境によって保存場所が異なる）
ただし、今回のように “警告が出る前に落ちる” 事象は、根本がサーバー側（証明書/ポリシー）のことが多いので、キャッシュ削除は最後のひと押しとして捉えるとよいです。
GPO：SSL 強制と NLA の組み合わせを確認する
ドメインのセキュリティポリシーで RDP のセキュリティレイヤーや NLA が強制されていると、証明書不整合が “許されない” 方向に倒れます。代表的なポリシー例です。
| ポリシー（例） | 場所 | ポイント |
|---|---|---|
| ネットワーク レベル認証でのユーザー認証を必須にする | コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → リモート デスクトップ サービス → リモート デスクトップ セッション ホスト → セキュリティ | NLA を切れない環境では、証明書の整合が必須になる。 |
| リモート接続に特定のセキュリティ レイヤーの使用を要求する | 同上 | SSL/TLS を強制していると、証明書が合わない瞬間に接続が終わる。 |
| サーバー認証証明書テンプレートの指定 | 同上 | テンプレートが旧名のまま発行される設計になっていないか見直す。 |
GPO が絡む環境では「サーバー側で入れ替えたつもりでも、次の更新で元に戻る」こともあります。証明書の配布方法（自動登録/スクリプト/手作業）と、RDP への割り当て（SSLCertificateSHA1Hash）が一貫しているかまでセットで見直すと再発防止になります。
再発防止：サーバー名変更時にセットで実施する運用手順
リネームは OS 的には数分で終わる作業に見えますが、周辺（DNS、SPN、証明書、監視、バックアップ、運用台帳）の整合が取れて初めて“完了”です。RDP を管理の生命線にしている環境ほど、証明書対応を手順化しておくと事故が減ります。
| タイミング | やること | 確認ポイント |
|---|---|---|
| リネーム前 | 現行証明書の控え（thumbprint、期限、SAN） | 復旧時に“元に戻す”判断ができるようにする。 |
| リネーム直後 | DNS（A/PTR）、FQDN の確認 | クライアントから新 FQDN が引けるか。 |
| リネーム直後 | 新 FQDN を含む証明書の発行/自動登録 | SAN に newname と new FQDN が入っているか。 |
| 証明書導入後 | RDP リスナーへ割り当て | SSLCertificateSHA1Hash が新 thumbprint を指しているか。 |
| 最後 | TermService 再起動 → 接続試験 | NLA 有効のまま、複数端末から接続できるか。 |
短い名前で接続している端末が混在している場合は、移行期間中に「FQDN 統一」に寄せるのが最も確実です。どうしても短い名前が残るなら、証明書の SAN に短い名前も必ず入れることで、今回のようなリネーム起点の障害を減らせます。
まとめ：0x80004005（NLA 有効時のみ失敗）は“証明書の名前不一致”を疑う
- リネーム後に NLA 有効の RDP だけ失敗するなら、まず RDP が提示する証明書の CN/SAN を確認する
- 新しい FQDN（必要なら短いホスト名も）を含む証明書を再発行し、RDP-Tcp に割り当てる
- 割り当て後は TermService の再起動で確実に読み替え、GPO 運用なら「再配布で戻されない」ことまで確認する
0x80004005 は原因を直接語ってくれない分、証明書と NLA の関係を知っていると復旧が一気に速くなります。リネーム作業のチェックリストに「RDP 証明書の再発行・割り当て」を組み込んでおくと、同様の事故をほぼ防げます。
コメント