結論から言うと、リモートデスクトップの証明書警告は無視せず、接続に使ったFQDN、実際に提示された証明書のThumbprint、証明書を管理する役割を特定してから直します。Connection Brokerを含むRDS展開はServer ManagerまたはRemoteDesktop PowerShellで役割ごとに割り当てます。RDS展開に属さない単体Windows Serverは、RDP-TcpリスナーのSSLCertificateSHA1Hashを更新します。
作業前にRDP以外の管理経路を確保し、旧Thumbprintと旧PFXを保持してください。新しい証明書の動作を別クライアントから確認するまで、自己署名証明書や旧証明書を削除しません。警告画面で「はい」を選び続ける運用や、未知の証明書をクライアントの信頼済みに追加する回避策も避けます。
エラー表示から原因を絞る
| 表示・状態 | 主に確認する項目 | 対処の方向 |
|---|---|---|
| 証明書の名前が一致しない | mstscに入力した名前、Gateway外部名、証明書SAN | 証明書に合う正式FQDNで接続するか、SANが正しい証明書へ更新 |
| 発行元が信頼されていない | ルート/中間CA、提示証明書、クライアントの信頼ストア | 正しいCAチェーンを管理配布。未知のサーバー証明書を直接信頼しない |
| 期限切れ・まだ有効でない | NotBefore、NotAfter、サーバー/クライアント時刻 | 有効な証明書へ更新し、時刻同期を修正 |
| 予期しない証明書 | 提示Thumbprintと役割バインド | Get-RDCertificateまたはRDPリスナー設定を確認 |
| RD Webは正常、mstscだけ警告 | RD Web証明書とSession Hostリスナー証明書 | 別管理対象として各バインドを確認 |
| 社外だけ警告・接続不能 | RD Gateway外部FQDN、公開DNS、Gateway証明書 | RDGateway役割と外部名を照合 |
| 証明書更新後に接続不能 | 秘密鍵、NETWORK SERVICEのRead権限、役割、チェーン | 旧証明書へ切り戻し、コンソールから調査 |
| CredSSP、NLA、ライセンス、権限の文言 | 証明書以外の認証・ライセンス・ポリシー | 本記事の証明書手順と分けて診断 |
最初に構成を判定する
同じ「リモートデスクトップ」でも、証明書の管理場所が異なります。ここを取り違えると、PersonalストアへPFXを入れただけで安心したり、別の役割が古い証明書を提示し続けたりします。
| 構成 | 見分け方 | 管理方法 |
|---|---|---|
| Connection Brokerを含むRDS展開 | Server ManagerのRemote Desktop Services、OverviewにDeployment Overviewがある | Edit Deployment PropertiesのCertificates、Get/Set-RDCertificate |
| RD Gateway | 外部クライアントがHTTPSトンネル経由で接続 | RDS展開のRDGateway役割。外部FQDNが重要 |
| RD Web Access | Webポータルやフィードを利用 | RDS展開のRDWebAccess役割 |
| 単体サーバーへ直接RDP | Connection Brokerを使わずmstscでサーバーへ直接接続 | RDP-TcpリスナーのSSLCertificateSHA1Hash |
| 社内CAによるSession Host自動選択 | GPOでServer authentication certificate templateを指定 | 証明書テンプレートとGPO。手動バインドがあればそちらが優先 |
変更前に必ず行う安全確認
- 別管理経路を確保する。物理コンソール、Hyper-V/VMwareコンソール、iLO/iDRAC、クラウドのコンソールなど、RDPが止まっても戻せる経路を準備します。
- 変更時間と利用者影響を調整する。新規接続試験を行える保守時間を確保し、同時に別の証明書・DNS・Gateway変更を重ねません。
- 旧証明書を保持する。Thumbprint、有効期限、役割を記録し、組織の秘密鍵保管手順に従って旧PFXを利用可能な状態にします。
- 接続名を一覧化する。RD Web URL、Gateway外部FQDN、Brokerの公開名、Session Host直接接続名を分けて書きます。
- DNSを確認する。クライアントが使うFQDNが意図したVIPまたはサーバーへ解決するか確認します。IPアドレスや短縮名での試験は名前不一致を生みます。
RDS展開の現状をPowerShellで記録する
次は例としてConnection Brokerをrdcb01.contoso.exampleとしたコマンドです。管理者としてWindows PowerShellを開きます。
$broker = 'rdcb01.contoso.example'
Get-RDCertificate -ConnectionBroker $broker |
Format-List Role, Level, Subject, SubjectAlternateName, ExpiresOn, ThumbprintGet-RDCertificateが返す役割は次の4つです。
| PowerShellのRole | Server Managerの表示 | 主な名前 |
|---|---|---|
| RDGateway | RD Gateway | クライアントが使うGateway外部FQDN |
| RDWebAccess | RD Web Access | RD WebのURL/公開FQDN |
| RDRedirector | RD Connection Broker – Enable Single Sign On | RDSクライアントアクセス名または設計上のBroker名 |
| RDPublishing | RD Connection Broker – Publishing | 公開RDPファイルの署名・発行に使う証明書 |
LevelがTrustedでも、利用者が入力した名前とSANが合うとは限りません。Subject、SubjectAlternateName、ExpiresOn、Thumbprintを個別に確認します。
使用する証明書の要件
- Server Authentication：EKU OID
1.3.6.1.5.5.7.3.1を持つ。 - Key Usage：用途に必要なKey Usage拡張を持つ。
- 信頼：RDSサーバーと接続クライアントが発行CAを信頼できる。
- 名前：利用者が実際に入力するDNS名がSANに含まれる。SANの順番ではなく、実接続名との一致を確認する。
- 有効期間：現在時刻がNotBeforeからNotAfterの範囲内で、更新後の運用期間を十分に確保する。
- 秘密鍵：秘密鍵を持ち、RDS展開へ配布する場合は秘密鍵付きPFXとして安全にエクスポートできる。
- 失効確認：クライアントとサーバーから組織のCRL/OCSPへ到達できる。
RD Gatewayの本番利用について、Microsoftは公開信頼CAの証明書を使用するよう案内しています。内部CAを使う内部接続では、ルートと中間CAをGPOなどの管理手段で配布します。警告を消すためにサーバーのリーフ証明書だけを各利用者のTrusted Rootへ直接入れる運用は避けます。
方法1：Server ManagerでRDS役割へ割り当てる
- Connection Brokerの管理サーバーでServer Managerを開きます。
- 左側の「Remote Desktop Services」を選び、「Overview」を開きます。
- Deployment Overviewの「TASKS」から「Edit Deployment Properties」を選びます。
- 「Certificates」を開き、最初に更新する役割を1つ選びます。
- 「Select existing certificate」、Browseの順に選び、正しい役割用PFXとパスワードを指定します。
- 適用後に状態とThumbprintを確認し、残りの役割も設計した証明書へ更新します。SANが全ての名前をカバーしない場合は、役割別の証明書を使います。
- Get-RDCertificateを再実行し、各RoleのLevel、ExpiresOn、Thumbprintを変更記録と照合します。
現行Microsoft文書では、Server Managerは複数サーバー構成でも証明書を対象サーバーへインポートし、該当役割へバインドします。各サーバーへ手作業で同じPFXを配る前に、展開管理からの割り当てを使ってください。
方法2：Set-RDCertificateで役割を更新する
自動化する場合も、1役割ずつ結果を確認します。次はRD Web AccessへC:\Secure\rds-web.pfxを割り当てる例です。PFXパスワードをコマンドやスクリプトへ平文で書かず、対話入力します。
$broker = 'rdcb01.contoso.example'
$password = Read-Host -AsSecureString -Prompt 'PFX password'
$params = @{
Role = 'RDWebAccess'
ImportPath = 'C:\Secure\rds-web.pfx'
Password = $password
ConnectionBroker = $broker
}
Set-RDCertificate @params
Get-RDCertificate -Role RDWebAccess -ConnectionBroker $broker |
Format-List Role, Level, Subject, SubjectAlternateName, ExpiresOn, Thumbprintほかの役割はRDGateway、RDRedirector、RDPublishingを指定します。同じPFXを全役割へ使えるのは、実際の全接続名がSANで正しくカバーされ、秘密鍵配布範囲が組織方針に合う場合だけです。-Forceで確認を省略せず、役割ごとに変更結果を残します。
方法3：単体サーバーのRDP-Tcpリスナーを更新する
この方法は、Microsoftの公式文書が対象とするRDS展開に属さないWindows Server用です。RDS展開の役割証明書へ代用しません。
証明書をLocal ComputerのPersonalへ入れる
certlm.mscを開き、「Certificates (Local Computer)」、「Personal」、「Certificates」を確認します。- 新しい秘密鍵付き証明書をPersonalへインポートします。Current Userストアではありません。
- 証明書を右クリックし、「All Tasks」、「Manage Private Keys」を開きます。
NETWORK SERVICEへRead権限を付けます。Full Controlは与えません。
承認済みThumbprintの1枚だけを検証してWMIへ割り当てる
証明書を期限順に並べて自動選択してはいけません。変更申請で事前承認された40桁のThumbprintと、利用者が実際にmstscへ入力するFQDNを用意します。次のスクリプトはLocal ComputerのPersonalストアからそのThumbprintに完全一致する証明書をちょうど1枚取得し、Subject、SAN、Issuer、Thumbprint、NotBefore、NotAfter、秘密鍵、Server Authentication EKU、現在の有効性、FQDNとSANの一致、失効確認を含む信頼チェーンを表示・検証します。どれか1つでも失敗するか、表示内容を変更申請と照合して承認できなければ、WMIを変更する前に明示的に停止します。
作業は確保済みの物理・仮想コンソールとは別の管理PowerShellで行い、そのコンソールと現在のRDPセッションを検証終了まで閉じません。旧証明書はLocal ComputerのPersonalストアと承認済みの保管場所に残し、削除・上書きしないでください。スクリプトが記録する$oldThumbprintも同じセッションで保持します。
function Test-SanDnsMatch {
param(
[Parameter(Mandatory)] [string] $Pattern,
[Parameter(Mandatory)] [string] $HostName
)
$patternValue = $Pattern.TrimEnd('.').ToLowerInvariant()
$hostValue = $HostName.TrimEnd('.').ToLowerInvariant()
if ($patternValue -eq $hostValue) {
return $true
}
if (-not $patternValue.StartsWith('*.')) {
return $false
}
$suffix = $patternValue.Substring(1)
if (-not $hostValue.EndsWith($suffix)) {
return $false
}
$leftmostLabel = $hostValue.Substring(0, $hostValue.Length - $suffix.Length)
return $leftmostLabel.Length -gt 0 -and -not $leftmostLabel.Contains('.')
}
function Get-ValidatedRdpCertificate {
param(
[Parameter(Mandatory)] [string] $Thumbprint,
[Parameter(Mandatory)] [string] $ConnectionFqdn
)
if ($Thumbprint -cnotmatch '^[0-9A-Fa-f]{40}$') {
throw 'Thumbprint must be the exact 40 hexadecimal characters from the approved change record.'
}
if ([string]::IsNullOrWhiteSpace($ConnectionFqdn)) {
throw 'The actual connection FQDN is required.'
}
$exactThumbprint = $Thumbprint.ToUpperInvariant()
$certificates = @(
Get-Item -LiteralPath ("Cert:\LocalMachine\My\{0}" -f $exactThumbprint) -ErrorAction SilentlyContinue
)
if ($certificates.Count -ne 1) {
throw "Expected exactly one certificate in LocalMachine\My for the approved thumbprint; found $($certificates.Count)."
}
$certificate = $certificates[0]
$sanNames = @($certificate.DnsNameList | ForEach-Object { $_.Unicode })
$ekuOids = @($certificate.EnhancedKeyUsageList | ForEach-Object { $_.ObjectId.Value })
$hasServerAuthentication = $ekuOids -contains '1.3.6.1.5.5.7.3.1'
$now = Get-Date
$isCurrentlyValid = $now -ge $certificate.NotBefore -and $now -le $certificate.NotAfter
$fqdnMatchesSan = @(
$sanNames | Where-Object {
Test-SanDnsMatch -Pattern $_ -HostName $ConnectionFqdn
}
).Count -gt 0
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
try {
$chain.ChainPolicy.RevocationMode = [System.Security.Cryptography.X509Certificates.X509RevocationMode]::Online
$chain.ChainPolicy.RevocationFlag = [System.Security.Cryptography.X509Certificates.X509RevocationFlag]::EntireChain
$chain.ChainPolicy.VerificationFlags = [System.Security.Cryptography.X509Certificates.X509VerificationFlags]::NoFlag
$chain.ChainPolicy.UrlRetrievalTimeout = [TimeSpan]::FromSeconds(15)
$trustedChain = $chain.Build($certificate)
$chainStatus = @($chain.ChainStatus | ForEach-Object {
"$($_.Status): $($_.StatusInformation.Trim())"
})
} finally {
$chain.Dispose()
}
if ($chainStatus.Count -eq 0) {
$chainStatus = @('No chain errors')
}
$inspection = [pscustomobject]@{
Subject = $certificate.Subject
SAN = ($sanNames -join ', ')
Issuer = $certificate.Issuer
Thumbprint = $certificate.Thumbprint
NotBefore = $certificate.NotBefore
NotAfter = $certificate.NotAfter
HasPrivateKey = $certificate.HasPrivateKey
ServerAuthenticationEKU = $hasServerAuthentication
CurrentlyValid = $isCurrentlyValid
ConnectionFqdn = $ConnectionFqdn
FqdnMatchesSAN = $fqdnMatchesSan
TrustedChain = $trustedChain
ChainStatus = ($chainStatus -join '; ')
}
$inspection | Format-List | Out-Host
$failures = @()
if ($certificate.Thumbprint.ToUpperInvariant() -cne $exactThumbprint) {
$failures += 'thumbprint mismatch'
}
if (-not $certificate.HasPrivateKey) {
$failures += 'private key is missing'
}
if (-not $hasServerAuthentication) {
$failures += 'Server Authentication EKU is missing'
}
if (-not $isCurrentlyValid) {
$failures += 'certificate is not currently valid'
}
if (-not $fqdnMatchesSan) {
$failures += 'actual connection FQDN does not match any SAN entry'
}
if (-not $trustedChain) {
$failures += "trusted chain validation failed: $($chainStatus -join '; ')"
}
$identityApproval = Read-Host 'Compare Subject, SAN, Issuer and all displayed values with the approved record; type APPROVED to continue'
if ($identityApproval -cne 'APPROVED') {
$failures += 'displayed certificate identity was not explicitly approved'
}
if ($failures.Count -gt 0) {
throw "Certificate validation failed; WMI was not changed: $($failures -join ' | ')"
}
return $certificate
}
$connectionFqdn = Read-Host 'Actual FQDN that users enter in the RDP client'
$approvedThumbprint = Read-Host 'Exact pre-approved certificate thumbprint (40 hexadecimal characters)'
$newCertificate = Get-ValidatedRdpCertificate -Thumbprint $approvedThumbprint -ConnectionFqdn $connectionFqdn
$rdpSettings = @(
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"
)
if ($rdpSettings.Count -ne 1) {
throw "Expected exactly one RDP-tcp Win32_TSGeneralSetting object; found $($rdpSettings.Count)."
}
$rdpSetting = $rdpSettings[0]
$oldThumbprint = [string] $rdpSetting.SSLCertificateSHA1Hash
if ($oldThumbprint -cnotmatch '^[0-9A-Fa-f]{40}$') {
throw 'The current listener thumbprint could not be recorded exactly. Stop and preserve the old binding before continuing.'
}
$oldThumbprint = $oldThumbprint.ToUpperInvariant()
$oldCertificates = @(
Get-Item -LiteralPath ("Cert:\LocalMachine\My\{0}" -f $oldThumbprint) -ErrorAction SilentlyContinue
)
if ($oldCertificates.Count -ne 1 -or -not $oldCertificates[0].HasPrivateKey) {
throw 'The old listener certificate is not preserved with its private key in LocalMachine\My. Stop before changing WMI.'
}
if ($oldThumbprint -ceq $newCertificate.Thumbprint.ToUpperInvariant()) {
throw 'The approved certificate is already bound; no WMI change is required.'
}
$rdpSetting | Set-WmiInstance -Arguments @{
SSLCertificateSHA1Hash = $newCertificate.Thumbprint
}
$persistedSettings = @(
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"
)
if ($persistedSettings.Count -ne 1) {
throw 'The listener could not be re-queried immediately after the change. Keep the console open and investigate.'
}
$persistedThumbprint = ([string] $persistedSettings[0].SSLCertificateSHA1Hash).ToUpperInvariant()
if ($persistedThumbprint -cne $newCertificate.Thumbprint.ToUpperInvariant()) {
throw "The listener did not persist the approved thumbprint. Expected $($newCertificate.Thumbprint); found $persistedThumbprint."
}
[pscustomobject]@{
TerminalName = $persistedSettings[0].TerminalName
PreviousThumbprint = $oldThumbprint
PersistedThumbprint = $persistedThumbprint
Confirmed = $true
} | Format-Listこの例はNotAfterで並べ替えず、最初に見つかった証明書も採用しません。承認済みThumbprintに完全一致する1枚だけを取り出し、検証結果をすべて表示したうえで、機械判定と人による変更記録照合の両方を通過した場合だけSSLCertificateSHA1Hashを設定します。設定直後の再クエリで保存値が一致しなければ成功扱いにしません。失敗時は確保した別コンソールを使い、旧証明書を残したまま原因を調べます。
別クライアントから検証する
- 変更に使った管理セッションは、検証が終わるまで切断しません。
- 別の管理端末で新しいmstscを開き、証明書SANに含まれる正式FQDNを入力します。IPアドレスや短縮名を使いません。
- 警告が出ないこと、または証明書詳細のSubject/SAN、発行者、有効期限、Thumbprintが新しい値であることを確認します。
- RDS展開では、RD Web URL、ワークスペース/フィード、RemoteApp、フルデスクトップ、社外からのRD Gatewayを接続経路ごとに試します。
- 新規接続と再接続を分けて確認します。既存セッションが生きているだけでは更新成功を証明できません。
- 利用者へ案内するRDPファイルや接続先名が旧FQDNのままなら更新します。
失敗した場合の分岐
| 失敗 | 確認 | 安全な対応 |
|---|---|---|
| Get-RDCertificateが旧Thumbprint | ConnectionBroker名、Role、PFX、適用結果 | 正しいBrokerから役割を1つずつ再適用 |
| Webだけ旧証明書 | RDWebAccess役割、IIS経路、負荷分散先 | 全WebノードとVIP経路を確認 |
| Gatewayだけ旧証明書 | RDGateway役割、外部FQDN、接続先Gateway | 展開のGateway設定と公開DNSを照合 |
| 直接RDPだけ自己署名 | RDP-TcpのSSLCertificateSHA1Hash | Session Hostリスナーを別途設定 |
| Invalid Parameter | 証明書がLocalMachine\Myにあるか、Thumbprint、秘密鍵 | ストアと候補条件を修正。レジストリを直接編集しない |
| 更新後に接続不能 | NETWORK SERVICEの秘密鍵Read、チェーン、期限 | 別コンソールから旧Thumbprint/PFXへ切り戻す |
| 名前不一致が残る | 実際に入力したFQDNとSAN | 正式FQDNへ統一するか正しいSANで再発行 |
| 信頼エラーが残る | クライアントのルート/中間CA、失効確認 | CA証明書をGPO等で管理配布 |
切り戻し手順
RDS展開を戻す
Server ManagerのDeployment Properties、Certificatesを開き、保管していた旧PFXを問題のRoleへ再割り当てします。全役割を一度に戻さず、影響したRoleから戻します。Get-RDCertificateで旧Thumbprintへ戻ったことを確認し、別クライアントから新規接続を試します。
単体RDPリスナーを戻す
確保した別コンソールを開いたまま、同じPowerShellセッションで記録した$oldThumbprintを使います。古い$rdpSettingオブジェクトは再利用せず、現在のWin32_TSGeneralSettingを必ず再クエリします。その後、上で定義したGet-ValidatedRdpCertificateを旧Thumbprintに対してもう一度実行し、旧証明書がLocal ComputerのPersonalにちょうど1枚存在すること、秘密鍵、Server Authentication EKU、現在の有効性、実接続FQDNとのSAN一致、信頼チェーン、表示したSubject・SAN・Issuerを再確認します。1項目でも失敗した旧証明書へは強制的に戻さず、別コンソールから代替証明書を準備します。
if ($oldThumbprint -cnotmatch '^[0-9A-F]{40}$') {
throw 'The exact old thumbprint is not available; rollback was not attempted.'
}
$currentRdpSettings = @(
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"
)
if ($currentRdpSettings.Count -ne 1) {
throw "Expected exactly one current RDP-tcp setting; found $($currentRdpSettings.Count). Rollback was not attempted."
}
$validatedOldCertificate = Get-ValidatedRdpCertificate -Thumbprint $oldThumbprint -ConnectionFqdn $connectionFqdn
if (-not $validatedOldCertificate.HasPrivateKey) {
throw 'The old certificate has no private key; rollback was not attempted.'
}
$currentRdpSettings[0] | Set-WmiInstance -Arguments @{
SSLCertificateSHA1Hash = $validatedOldCertificate.Thumbprint
}
$rollbackCheck = @(
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"
)
if ($rollbackCheck.Count -ne 1) {
throw 'The listener could not be re-queried immediately after rollback.'
}
$rolledBackThumbprint = ([string] $rollbackCheck[0].SSLCertificateSHA1Hash).ToUpperInvariant()
if ($rolledBackThumbprint -cne $oldThumbprint) {
throw "Rollback did not persist the old thumbprint. Expected $oldThumbprint; found $rolledBackThumbprint."
}
[pscustomobject]@{
TerminalName = $rollbackCheck[0].TerminalName
PersistedThumbprint = $rolledBackThumbprint
RollbackConfirmed = $true
} | Format-List戻した後も接続できなければ、証明書を削除せず、コンソールからイベントログ、秘密鍵ACL、DNS、CAチェーンを調査します。旧証明書を先に削除していると、この切り戻しができません。
再発防止と更新運用
- 役割、接続FQDN、証明書SAN、Thumbprint、有効期限、PFX保管責任者を台帳化する。
- 期限の十分前に通知し、発行、検証、切り戻しの保守日を確保する。
- 内部CAのルート/中間証明書はGPOなど管理された方法で配布する。
- Session Hostが多数ある場合はServer authentication certificate templateのGPOを検討し、テンプレート名と適用範囲をPKI管理者と確認する。
- 更新後は既存セッションではなく新規接続で検証し、Gateway、Web、Broker、Session Hostを別々に確認する。
- PFXをメール添付や一般共有へ置かず、最小権限の秘密保管を使う。
よくある質問
自己署名証明書を削除すれば正しい証明書が使われますか？
削除を先にしてはいけません。提示される証明書はRoleまたはRDPリスナーのバインドで決まります。新証明書を明示的に割り当て、別端末で検証し、切り戻し期間を終えてから旧証明書の廃止を判断します。
ワイルドカード証明書1枚を全役割へ使えますか？
接続に使う全FQDNが正しくカバーされ、CA・クライアント・組織方針がワイルドカードを許可し、秘密鍵の配布範囲も妥当な場合に限ります。Gatewayの外部名と内部Session Host名は階層が異なることもあるため、名前を実際に列挙して確認します。
CNが合っていればSANがなくてもよいですか？
現行運用では、クライアントが接続するDNS名をSANへ含める設計にします。CNだけ、SANの並び順、警告の例外登録へ依存せず、実接続名とSANを照合してください。
証明書警告を無視しても通信は暗号化されていますか？
暗号化されていても、接続先が本物だと検証できなければ中間者を見分けられません。警告を承認して資格情報を入力する運用は避け、名前・信頼・期限・バインドを直します。
Get-RDCertificateにSession Hostが表示されないのはなぜですか？
Get-RDCertificateが扱うRDS展開RoleはRDGateway、RDWebAccess、RDRedirector、RDPublishingです。Session Hostへ直接RDPするときに提示するリスナー証明書は別管理で、必要に応じてRDP-Tcpの設定を確認します。
Microsoft公式資料
- Use certificates in Remote Desktop Services
- Get-RDCertificate
- Set-RDCertificate
- Remote Desktop listener certificate configurations
- Remote Desktop Services – Access from anywhere
- Distribute certificates to Windows devices by using Group Policy
まとめ
RDSの証明書エラーは、名前、信頼、有効期限、秘密鍵、バインドのどこが違うかを順に調べます。Connection Brokerを含む展開は役割証明書、単体サーバーはRDP-Tcpリスナーとして管理し、両者を混ぜません。変更前に別管理経路と旧Thumbprintを確保し、新しい証明書を明示的に割り当て、別端末から正式FQDNで新規接続を検証します。旧証明書の先行削除を避けることが、警告を直しながら管理経路も守る要点です。
コメント