Vuoi assegnare un certificato TLS/SSL alla connessione RDP su Windows Server 2022 ma non trovi più le vecchie voci di gestione? In questa guida pratica scopri come farlo in ambienti con Connection Broker, su server singoli e perfino senza GPO/UI, con procedure passo‑passo, script e checklist.
Panoramica del problema
Con le versioni moderne di Windows Server Microsoft ha ritirato gli strumenti storici Remote Desktop Services Manager (tsadmin.msc) e le proprietà del listener RDP‑Tcp di tsconfig.msc. Questo ha spiazzato molti amministratori: l’assegnazione del certificato per il servizio RDP non si fa più con un clic sull’interfaccia classica, ma attraverso Server Manager per le distribuzioni con Remote Desktop Connection Broker, oppure via criteri di gruppo e PowerShell/registro quando si gestisce il listener del Servizio Desktop Remoto (TermService) su server stand‑alone o farm senza broker.
La buona notizia: le strade per ottenere una connessione RDP autenticata con certificato valido sono chiare e automatizzabili. Qui sotto trovi una sintesi degli scenari e, a seguire, istruzioni dettagliate, consigli di hardening e script pronti all’uso.
Scenari e percorso consigliato
Scenario | Procedura sintetica | Quando sceglierlo |
---|---|---|
Distribuzione con Remote Desktop Connection Broker | Server Manager → Remote Desktop Services → Deployment Overview → Tasks → Edit Deployment Properties → scheda Certificates → Select existing certificate (PFX + password) per RD Web, RD Gateway, RD Connection Broker (Publishing/SSO). Salva, quindi riavvia i servizi RDS o il server se richiesto. | Ambienti RDS “completi” con Web, Gateway, Broker. Vuoi un unico certificato pubblico per l’accesso dall’esterno. |
Server singolo o farm senza Connection Broker | Importa il certificato nel Computer Store → Personal (mmc.exe → Certificates → Computer ). Forza l’uso del certificato per il listener RDP tramite GPO (Server authentication certificate template) oppure imposta la thumbprint nel registro. Aggiorna i criteri (gpupdate /force ) e riavvia TermService. | Server remoti senza infrastruttura RDS centralizzata; macchine isolate o piccoli gruppi. |
Ambienti senza diritti di GPO/UI | Usa PowerShell:$pfx = Import‑PfxCertificate –FilePath "C:\path\cert.pfx" –CertStoreLocation Cert:\LocalMachine\My Set‑ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP‑Tcp" -Name SSLCertificateSHA1Hash -Value $pfx.Thumbprint Riavvia il servizio RDP. | Server bloccati, sessioni just‑in‑time, container/immagini dove serve uno script idempotente. |
Prerequisiti e concetti chiave
- Tipo di certificato: deve includere la chiave privata ed essere in Local Computer → Personal (
Cert:\LocalMachine\My
), con EKU Server Authentication (OID 1.3.6.1.5.5.7.3.1), firma SHA‑256 e chiave minima 2048 bit (consigliati 3072+) su RSA. ECDSA è supportato dallo stack TLS, ma per massima compatibilità RDP è preferibile RSA. - Nomi nel certificato: il Subject Alternative Name deve contenere il FQDN con cui i client si connettono. Evita l’IP: richiedere un SAN IP è scomodo e spesso inutile. Educa gli utenti a usare sempre il nome DNS.
- Differenza tra certificati:
- RD Web/RD Gateway/RD Connection Broker: gestiti centralmente dalla distribuzione RDS.
- Listener RDP (RDP‑Tcp) del singolo server: può richiedere binding specifico (GPO/registro), anche in presenza di RDCB.
- Protocollo di sicurezza: il servizio RDP su questa piattaforma utilizza TLS 1.2. TLS 1.3 non viene attualmente impiegato dal listener RDP.
- Permessi sulla chiave privata: importando in LocalMachine i permessi sono in genere corretti. Se usi strumenti non standard, verifica che l’account di sistema possa accedere alla chiave.
- Catena di fiducia: installa le CA intermedie/ radice in Trusted Root e Intermediate Certification Authorities del Computer. I client devono fidarsi della stessa catena.
Procedura con infrastruttura gestita da Connection Broker
In una distribuzione RDS completa, l’interfaccia di Server Manager consente di assegnare e replicare rapidamente lo stesso certificato ai ruoli esposti al pubblico. Il flusso tipico:
- Apri Server Manager e scegli Remote Desktop Services.
- Nel riquadro Deployment Overview, clic su Tasks → Edit Deployment Properties.
- Vai alla scheda Certificates.
- Per ciascun ruolo (RD Web, RD Gateway, RD Connection Broker – Publishing e Enable Single Sign‑On) seleziona Select existing certificate, indica il file
.pfx
e la password. - Conferma e consenti il riavvio dei servizi RDS quando richiesto.
Nota importante: la scheda Certificates gestisce i ruoli RDS centrali, ma il listener RDP‑Tcp dei Session Host può ancora usare un certificato locale diverso. Per un’esperienza coerente (niente avvisi in connessione diretta al nodo), applica anche la sezione seguente.
Assegnazione del certificato al listener dei Session Host
Se nel tuo deployment gli utenti talvolta si collegano direttamente ai Session Host (o desideri uniformare il certificato su ogni nodo), lega esplicitamente la stessa thumbprint al listener:
- Assicurati che il PFX sia importato in Local Computer → Personal su tutti i Session Host.
- Applica una GPO a livello di OU che:
- Configura Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → Server authentication certificate template. Se usi auto‑enrollment, indica il nome del template da cui proviene il certificato.
- In alternativa (o in assenza di PKI), distribuisci uno script di startup che imposta la chiave
SSLCertificateSHA1Hash
con la thumbprint del certificato presente sul nodo.
- Forza l’aggiornamento con
gpupdate /force
e riavvia il servizio Remote Desktop Services (TermService
).
Procedura per server singolo o farm senza Connection Broker
Importazione del certificato nel Computer Store
- Esegui
mmc.exe
→ File → Add/Remove Snap‑in → Certificates → Computer account → Local computer. - Nodo Personal → Certificates → tasto destro → All Tasks → Import → seleziona il
.pfx
con chiave privata e completa la procedura guidata.
Forzare il binding con criteri di gruppo
Se disponi di una PKI e del criterio di auto‑enrollment, puoi istruire il server a usare automaticamente un certificato conforme:
- Apri Local Group Policy Editor (
gpedit.msc
) o crea una GPO di dominio. - Vai a Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
- Configura Server authentication certificate template indicando il template usato per emettere il certificato (ad esempio RDP-ServerAuth).
- Facoltativamente, imposta:
- Require user authentication for remote connections by using Network Level Authentication → Enabled.
- Require use of specific security layer for remote (RDP) connections → SSL (TLS).
- Set client connection encryption level → High.
- Esegui
gpupdate /force
e riavvia TermService.
Forzare il binding via registro
Quando non puoi usare GPO/template, lega esplicitamente la thumbprint nel registro:
# Trova la thumbprint (senza spazi)
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter
Imposta la thumbprint nel listener RDP
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name SSLCertificateSHA1Hash -Value ""
Riavvia il servizio RDP
Restart-Service -Name TermService -Force
Procedura interamente con PowerShell
Script idempotente per importare un PFX, legarlo al listener e verificare il risultato. Personalizza $PfxPath
, $PfxPassword
e, se vuoi, $SubjectHint
per scegliere un certificato per soggetto/SAN specifico in caso di store affollato.
$ErrorActionPreference = "Stop"
Parametri
$PfxPath = "C:\PKI\rdp-cert.pfx"
$PfxPassword = Read-Host -AsSecureString "Password PFX"
$SubjectHint = "rdp.contoso.example" # facoltativo: parte del FQDN
Import nel Computer Store
$pfx = Import-PfxCertificate -FilePath $PfxPath -CertStoreLocation Cert:\LocalMachine\My -Password $PfxPassword
Selezione certificato con EKU Server Authentication e SAN/Subject aderente
$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object {
$*.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication" -and
$*.HasPrivateKey -and
($*.Subject -match $SubjectHint -or
($*.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } | Out-String) -match $SubjectHint)
} |
Sort-Object NotAfter -Descending |
Select-Object -First 1
if (-not $cert) { throw "Nessun certificato idoneo trovato nello store LocalMachine\My." }
Thumbprint pulita (senza spazi)
$thumb = ($cert.Thumbprint -replace "\s","").ToUpper()
Binding al listener RDP
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name SSLCertificateSHA1Hash -Value $thumb
Riavvio servizio
Restart-Service -Name TermService -Force
Verifica
$bound = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").SSLCertificateSHA1Hash
Write-Host "Thumbprint configurata: $bound"
Write-Host "Scadenza certificato: $($cert.NotAfter)"
Verifica e collaudo
- Dal server:
- Controlla il binding:
Get-ItemProperty "HKLM:\...\RDP-Tcp" SSLCertificateSHA1Hash
. - Elenca lo store e confronta la thumbprint:
Get-ChildItem Cert:\LocalMachine\My
oppurecertutil -store my
. - Verifica la porta:
Test-NetConnection -ComputerName localhost -Port 3389
.
- Controlla il binding:
- Dal client:
- Connettiti con il FQDN esatto inserito nel certificato (es.
mstsc /v:rdp.contoso.example
). - Apri i dettagli del certificato nella finestra di RDP (icona lucchetto) e verifica Emesso per e Impronta digitale.
- Se non compaiono avvisi, la catena e il nome corrispondono correttamente.
- Connettiti con il FQDN esatto inserito nel certificato (es.
Per auditing, consulta i log Applications and Services Logs → Microsoft → Windows → Schannel (handshake TLS) e i canali TerminalServices‑* per la componente RDP.
Risoluzione dei problemi
Il certificato non appare o non viene usato
- È nello store Local Computer → Personal (non nello store utente)?
- Include la chiave privata (icona con chiave in
certlm.msc
)? - Contiene l’EKU Server Authentication e una catena valida fino alla radice fidata sul client?
- La chiave di registro
SSLCertificateSHA1Hash
contiene la thumbprint corretta senza spazi? - Dopo il binding hai riavviato il servizio TermService?
Avviso di nome host non corrispondente
- Il SAN del certificato deve includere il nome DNS usato nella connessione. Se l’utente digita un alias diverso o l’IP, la validazione fallisce.
- Uniforma i file di collegamento RDP e i record DNS per far usare sempre lo stesso FQDN.
Errore sulla chiave privata o accesso negato
- Se hai importato il PFX con un utente non amministratore o con strumenti terzi, i permessi sul file della chiave potrebbero non essere corretti. Reimporta in LocalMachine con privilegi elevati.
- In casi rari, usa
certutil -repairstore my <THUMBPRINT>
per ricollegare certificato e chiave.
Persistenza dopo rinnovo
- Il rinnovo crea una nuova thumbprint. Aggiorna
SSLCertificateSHA1Hash
o assicurati che la GPO scelga automaticamente il certificato più recente (via template). - Automatizza con uno Scheduled Task post‑rinnovo che lancia lo script mostrato sopra.
Client meno recenti
- Alcuni client datati non supportano suite moderne o SAN assenti: verifica aggiornamenti del client RDP.
- Evita algoritmi deboli (MD5/SHA‑1) e chiavi < 2048 bit: non sono più accettati in ambienti sicuri.
Connessione diretta al nodo in ambienti con Broker
È comune proteggere Gateway/Web/Broker con un certificato affidabile ma dimenticare il listener dei Session Host. Se gli utenti, in emergenza, usano la connessione diretta al nodo, comparirà l’avviso. Risolvi replicando la stessa identità sul listener (GPO o registro) e mantenendo coerente il Subject/SAN.
Best practice di sicurezza
- Enforce TLS: imposta la sicurezza su SSL (TLS) e richiedi NLA via GPO. Disabilita protocolli/algoritmi obsoleti nella configurazione di Schannel se le policy aziendali lo richiedono.
- DNS affidabile: usa nomi stabili, record A/CNAME coerenti e, se serve, split‑DNS per connettività interna/esterna.
- Visibilità operativa: monitora gli eventi Schannel, conserva scadenze e rinnovi in un inventario centralizzato.
- Principio del minimo privilegio: esegui import e binding con privilegi elevati solo quando necessario; archivia i PFX in archivi protetti, ruotando le password.
Automazione del rinnovo e del binding
Questo script seleziona automaticamente il certificato più recente che corrisponde al FQDN desiderato e aggiorna il binding, pensato per essere eseguito periodicamente o al termine di un job di rinnovo.
$Fqdn = "rdp.contoso.example"
Seleziona il certificato idoneo più recente
$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object {
$*.HasPrivateKey -and
($*.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication") -and
(
$*.Subject -match [regex]::Escape($Fqdn) -or
( $*.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } | Out-String) -match [regex]::Escape($Fqdn)
)
} | Sort-Object NotAfter -Descending | Select-Object -First 1
if ($null -eq $cert) { throw "Nessun certificato con SAN/Subject contenente $Fqdn" }
$thumb = ($cert.Thumbprint -replace "\s","").ToUpper()
$current = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").SSLCertificateSHA1Hash
if ($current -ne $thumb) {
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -Value $thumb
Restart-Service TermService -Force
Write-Host "Aggiornata thumbprint RDP a $thumb e riavviato il servizio."
} else {
Write-Host "Thumbprint già aggiornata ($thumb). Nessuna azione."
}
Domande frequenti
- È necessario RD Gateway per avere TLS su RDP? No. Il listener RDP locale usa TLS 1.2 con un certificato valido anche senza Gateway. Gateway aggiunge tunneling HTTPS, controllo granulare e pubblicazione sicura.
- Posso riutilizzare lo stesso PFX su più server? Sì, se l’identità (SAN) copre tutti i nomi usati e la policy aziendale lo consente. In alternativa, emetti certificati individuali e automatizza il binding per ogni host.
- Posso usare un certificato wildcard? In genere funziona per il nome di host (es.
*.contoso.example
), purché i client si connettano con FQDN che ricadono nel wildcard e la CA lo consenta per Server Authentication. - Il listener supporta TLS 1.3? Al momento il servizio RDP non usa TLS 1.3; l’hardening si realizza assicurando TLS 1.2, cipher suite moderne e NLA.
Checklist operativa
Passo | Verifica rapida |
---|---|
Emetti/importa PFX in LocalMachine\My con chiave privata | certlm.msc : presenza chiave; EKU Server Authentication |
Controlla SAN con FQDN usato dai client | Evita IP; unifica i collegamenti al FQDN |
Assegna ai ruoli RDS se usi Connection Broker | Server Manager → Certificates |
Forza binding del listener RDP | GPO Server authentication certificate template o SSLCertificateSHA1Hash |
Riavvia TermService e prova la connessione | Test-NetConnection e verifica certificato dal client |
Automatizza il rinnovo | Scheduled Task con script di aggiornamento della thumbprint |
Approfondimenti utili
- Gli strumenti classici non sono più presenti: tutte le operazioni sui certificati RDS passano da Server Manager, GPO o automazione.
- Se il certificato non compare, verifica che:
- Sia presente nello store Local Computer → Personal e contenga la chiave privata.
- Il SAN includa il FQDN usato dai client RDP.
- Dopo l’importazione, i client possono convalidare il server senza avvisi; viene usato TLS 1.2, elevando la sicurezza della sessione.
Esempi di comandi rapidi
# Elenco certificati idonei allo scopo server
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication" } |
Format-Table Subject, Thumbprint, NotAfter
Imposta la thumbprint manualmente (senza spazi)
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name SSLCertificateSHA1Hash -Value ""
Riavvio del servizio Desktop Remoto
Restart-Service TermService -Force
Verifica connettività porta RDP
Test-NetConnection -ComputerName localhost -Port 3389
Seguendo le procedure descritte otterrai un RDP privo di avvisi, coerente con le policy di sicurezza e pronto per l’automazione del ciclo di vita del certificato, sia in ambienti semplici sia nelle distribuzioni RDS più articolate.