MENU
  1. ホーム
  2. Python
  3. RDS Windows Server 2016: errore 0x300000d dopo rinnovo certificato SSL – guida completa

RDS Windows Server 2016: errore 0x300000d dopo rinnovo certificato SSL – guida completa

Python

Dopo il rinnovo del certificato SSL in una farm RDS su Windows Server 2016, alcuni utenti vedono “The remote resource can’t be reached – 0x300000d”. Qui trovi una guida pratica, passo‑passo, per diagnosticare e risolvere rapidamente il problema senza dover ricostruire l’infrastruttura.

Indice

Scenario e sintomi

In ambienti Remote Desktop Services (RDS) basati su Windows Server 2016, può capitare che, subito dopo l’aggiornamento o la rotazione del certificato SSL/TLS, un sottoinsieme di utenti non riesca più ad aprire sessioni RemoteApp o desktop via RD Gateway, ricevendo il messaggio:

“The remote resource can’t be reached. Check your connection and try again or ask your network administrator for help.”
Error code: 0x300000d – Extended error: 0x0

Il comportamento tipico è ingannevole: nei log del Connection Broker, del Gateway e anche negli Event Viewer standard, spesso non compaiono errori evidenti. La connessione viene interrotta molto prima che RDP stabilisca il canale di controllo, di solito nella fase di handshake TLS.

Perché succede (la spiegazione in breve)

Il codice 0x300000d indica quasi sempre che il client ha abbandonato la sessione perché non è riuscito a instaurare una connessione sicura col Gateway. Le cause più frequenti dopo un rinnovo del certificato sono:

  • Thumbprint non allineato nelle Deployment Properties del Broker: la farm RDS punta ancora al vecchio certificato.
  • CN/SAN non corrispondenti all’FQDN utilizzato dagli utenti (o dal file .rdp / RD Web Feed).
  • Catena incompleta o CA intermedia assente sul server (o non fidata sul client), con CRL/OCSP irraggiungibili.
  • Scelta dell’algoritmo di chiave errata (es. passaggio a ECDSA con client legacy RSA‑only) o suite di cifratura non compatibili.
  • Binding HTTPS non aggiornato (o interferenze di reverse proxy / bilanciatore con un certificato diverso).
  • Cache client (credenziali, feed RD Web, certificati) ancora legata al vecchio certificato.

Checklist prioritaria (da eseguire nell’ordine suggerito)

PrioritàAzioneScopo
1Ricontrollo del certificato su tutti i ruoli RDS (Gateway, Web Access, Broker, Session Host): CN/SAN corretti, catena completa, certificato non scaduto, private key exportable, nessun errore di revoca (CRL/OCSP raggiungibili).Escludere problemi di handshake TLS (l’errore 0x300000d è tipico di una negoziazione TLS fallita).
2In Connection Broker → Deployment Properties → Certificates, aggiornare l’impronta digitale (thumbprint) del nuovo certificato e riavviare i servizi RD* su ogni nodo.Garantire che l’intera farm usi lo stesso certificato.
3Sul client: eliminare credenziali salvate e voci nella cache di certificati (certmgr.msc → Trusted People/Personal) quindi riconnettersi.Rimuovere riferimenti al vecchio certificato.
4Test di rete (ping, tracert, telnet 443/3389 o Test-NetConnection) dal client verso il nome pubblico del Gateway.Escludere latenza o NAT errati.
5Abilitare log dettagliati su RemoteDesktopServices‑RdpCoreTS (server e client) e analizzare le nuove entry.Individuare esattamente in quale fase fallisce la sessione.
6Controllare che TLS 1.2 (o versione richiesta dai client) e i relativi ciphers siano attivi nel Registro (SchUseStrongCrypto, configurazioni SCHANNEL).Alcuni client rifiutano cipher obsoleti dopo un cambio di certificato.
7Aggiornare feed RD Web Access e file .rdp pubblicati (es: rdweb/feed/webfeed.aspx) per propagare il nuovo thumbprint.Evitare che i client scarichino ancora riferimenti al vecchio certificato.
8Verificare DNS e bilanciatori: l’FQDN usato dagli utenti deve puntare al server/gateway che ospita il nuovo certificato.Assicurarsi che la risoluzione corrisponda al CN/SAN.

Guida passo‑passo dettagliata

Verifica immediata del certificato su ogni ruolo RDS

Controlla, su ogni server che eroga un ruolo RDS (Gateway, Web Access, Connection Broker, Session Host), che il certificato attivo sia quello nuovo, installato nello store Local Computer → Personal, con:

  • CN/SAN uguali all’FQDN pubblico usato dagli utenti (es. rdg.contoso.com);
  • EKU “Server Authentication” (1.3.6.1.5.5.7.3.1);
  • Catena completa (inclusa CA intermedia) e revoche raggiungibili;
  • Chiave privata presente e marcata come exportable (utile per replicare su più nodi).

Esempi rapidi con PowerShell (esegui come amministratore):

# Elenco certificati server nello store "My" con CN, SAN, scadenza e thumbprint
Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, @{n='SAN';e={$_.Extensions |
    Where-Object {$_.Oid.FriendlyName -eq 'Subject Alternative Name'} |
    ForEach-Object {$_.Format(0)}}}, NotAfter, Thumbprint

Visualizza dettagli completi di un certificato specifico (incolla il thumbprint)

\$tp = 'INSERISCI\_THUMBPRINT'
Get-ChildItem Cert:\LocalMachine\My\$tp | Format-List \*

Se utilizzi un reverse proxy o un bilanciatore L7, verifica anche lì il certificato: è frequente che la rotazione sia stata fatta sul server ma non sul dispositivo perimetrale (o viceversa), causando handshake falliti.

Allineamento del thumbprint in Deployment Properties

Apri Server Manager → Remote Desktop Services → Overview → Tasks → Edit Deployment Properties → Certificates e sostituisci/propaga il certificato nuovo su tutti i ruoli. In alternativa, usa PowerShell per garantire coerenza e ripetibilità:

# Parametri
$pfx = 'C:\temp\gateway_new.pfx'
$pwd = ConvertTo-SecureString 'PASSWORD_PFX' -AsPlainText -Force

Importa lo stesso PFX su RD Gateway, RD Web, RD Publishing (Broker), RD Redirector (Session Host)

Import-Module RemoteDesktop
Set-RDCertificate -Role RDGateway     -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDWebAccess   -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDPublishing  -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDRedirector  -ImportPath \$pfx -Password \$pwd -Force

Al termine, riavvia i servizi chiave su ogni nodo:

# Elenco nodi (adatta ai tuoi nomi)
$servers = 'RDGW01','RDBR01','RDWA01','RDSH01','RDSH02'

Invoke-Command -ComputerName \$servers -ScriptBlock {
Stop-Service  TSGateway    -ErrorAction SilentlyContinue
Stop-Service  Tssdis       -ErrorAction SilentlyContinue   # Connection Broker
Stop-Service  TermService  -ErrorAction SilentlyContinue   # Remote Desktop Services
& iisreset /stop
Start-Service Tssdis       -ErrorAction SilentlyContinue
Start-Service TSGateway    -ErrorAction SilentlyContinue
Start-Service TermService  -ErrorAction SilentlyContinue
& iisreset /start
}

Nota: i nomi dei servizi possono variare in base alla lingua/edizione; in dubbio, verifica con Get-Service.

Controlli lato client: credenziali e cache certificati

  • Apri Credential Manager (Pannello di Controllo) e rimuovi le voci TERMSRV/<FQDN> e qualsiasi credenziale salvata per il Gateway.
  • Apri certmgr.msc nel profilo utente e rimuovi eventuali copie del vecchio certificato in Personal o Trusted People.
  • Se usi RemoteApp e Desktop Connections, aggiorna o rimuovi/aggiungi nuovamente il feed. In alternativa, cancella le cartelle cache:
    • %LOCALAPPDATA%\Microsoft\Workspaces
    • %LOCALAPPDATA%\RDClientRadc\Feeds

Test di connettività e handshake

Esegui i test seguenti da un client “pulito” (VM appena creata o nuovo profilo):

# Connettività TCP verso RD Gateway (HTTPS)
Test-NetConnection rdg.contoso.com -Port 443 -InformationLevel Detailed

Connettività TCP verso RDP diretto (se pertinente)

Test-NetConnection rds01.contoso.com -Port 3389 -InformationLevel Detailed

Traceroute verso il Gateway

tracert rdg.contoso.com

Se la latenza o il percorso di rete sono anomali (NAT errato, hairpinning, firewall L7), correggi prima questi aspetti.

Abilitazione dei log avanzati RDP

Per capire dove fallisce la sessione:

  • Server: Event Viewer → Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices-RdpCoreTS. Abilita Operational e, se necessario, Debug/Diagnostic.
  • Client: Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices-ClientActiveXCore e TerminalServices-RDPClient (Operational).

Abilitazione via riga di comando:

# Server: abilitazione log diagnostici (puoi disabilitarli dopo la risoluzione)
wevtutil set-log "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" /enabled:true
wevtutil set-log "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Debug"       /enabled:true

Client (esegui come admin sul PC dell’utente/VM di test)

wevtutil set-log "Microsoft-Windows-TerminalServices-ClientActiveXCore/Operational" /enabled\:true
wevtutil set-log "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" /enabled\:true

Indizio utile: se i log RDS non registrano nulla sul tentativo di connessione, il blocco è prima del canale RDP → TLS handshake (certificato, catena, ciphers, CRL/OCSP, proxy).

Protocollo TLS 1.2 e suite di cifratura

Dopo un rinnovo certificato, alcuni client “rigidi” (app aziendali MAM, thin client, sistemi mobili legacy) possono rifiutare handshake se il server offre solo ciphers datati o, al contrario, solo ciphers moderni non supportati dal client. Allinea le impostazioni di sistema:

Windows Registry (server e/o client, se necessario)
[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

(Se applicabile a componenti .NET, es. RD Web)

\[HKEY\LOCAL\MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Evita di disabilitare TLS 1.2: se proprio devi supportare client obsoleti, fallo in modo temporaneo e documentato. Dopo i test, ripristina una postura sicura.

Attenzione al tipo di certificato: RSA vs ECDSA

Se il nuovo certificato è ECDSA e nella tua utenza ci sono client che supportano solo RSA, l’handshake fallirà senza un errore esplicito nei log RDS. Per massima compatibilità in ambienti misti, considera di utilizzare un certificato RSA 2048/3072 sul RD Gateway, oppure predisponi terminazione TLS sul bilanciatore che presenti RSA ai client e re‑encrypt verso il Gateway.

RD Web Access e file .rdp: propagare il nuovo thumbprint

Dopo il cambio certificato, aggiorna i feed e i file .rdp:

  • Rigenera i collegamenti pubblicati via Server Manager → Remote Desktop Services.
  • Verifica che i client scarichino il feed aggiornato (rdweb/feed/webfeed.aspx) e non restino ancorati a vecchie cache.
  • Per i collegamenti .rdp distribuiti via GPO/Intune, ripubblica i file assicurandoti che gatewayhostname e signscope puntino al nuovo certificato.

DNS, bilanciatori, reverse proxy

Conferma che l’FQDN usato dagli utenti (es. rdg.contoso.com) risolva al/i nodo/i corretti su cui è installato il certificato nuovo. In presenza di bilanciamento:

  • Se è L4, tutti i membri del pool devono avere lo stesso certificato e catena.
  • Se è L7/terminazione TLS, verifica che il certificato sul bilanciatore sia quello nuovo e che il re‑encrypt verso i backend usi protocolli/ciphers compatibili.

Procedure operative consigliate (runbook)

  1. Inventario certificati su tutti i ruoli, inclusi appliance di frontiera.
  2. Allineamento thumbprint nelle Deployment Properties con Set-RDCertificate.
  3. Riavvio controllato dei servizi RD e di IIS, un nodo per volta per minimizzare l’impatto.
  4. Pulizia cache client (credenziali, feed, certificati utente).
  5. Test da client pulito con Test-NetConnection e tentativo di sessione RemoteApp.
  6. Log avanzati solo se il problema persiste, per individuare la fase di failure.

Strumenti e comandi utili

Verifica catena e revoche

# Esporta il certificato (DER o CER) e verifica catena/CRL/OCSP
certutil -verify -urlfetch C:\temp\rdg.cer

Controllo binding HTTPS

Può essere utile validare il binding SSL su HTTP.sys (attenzione: in ambienti RD Gateway è preferibile gestire i binding dalla console dedicata o via Set-RDCertificate):

# Elenca binding SSL
netsh http show sslcert

(Avanzato) Sostituzione binding su 0.0.0.0:443 con nuovo certificato

netsh http delete sslcert ipport=0.0.0.0:443

netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINT appid="{GUID\_APP}"

Script di controllo rapido della corrispondenza FQDN ↔ CN/SAN

$fqdn = 'rdg.contoso.com'
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {
  $_.Subject -like "CN=$fqdn" -or
  ($.Extensions | Where-Object {$.Oid.FriendlyName -eq 'Subject Alternative Name'} |
    ForEach-Object {$_.Format(0)} | Select-String -SimpleMatch $fqdn)
}
if ($cert) { $cert | Format-List Subject, NotAfter, Thumbprint } else { 'Nessun certificato corrispondente.' }

Diagnostica: come riconoscere il colpevole

SegnaleProbabile causaAzione
Errore 0x300000d compare subito, nessun evento lato serverHandshake TLS interrotto (certificato, catena, ciphers)Controlla CN/SAN, catena, revoche, tipo certificato e suite di cifratura
Su alcuni client funziona, su altri noCompatibilità TLS/ciphers o trust chain lato clientConferma supporto TLS 1.2, installa CA intermedia sul client
Funziona in LAN, non da InternetBilanciatore/proxy con certificato vecchio o NAT erratoAllinea certificato anche sul perimetro, verifica health probe
Browser mostra certificato corretto su RD Web, ma RDP fallisceRD Gateway usa un certificato diverso da IISAllinea certificato su ruolo RD Gateway (non solo su RD Web)

Note aggiuntive importanti

  • Quando i log RDS non mostrano errori, 0x300000d quasi sempre indica che la connessione è stata interrotta prima del canale RDP, per un problema di autenticazione TLS o di certificato.
  • Con dispositivi mobili o client datati, verifica che riconoscano e si fidino della CA intermedia usata per la nuova emissione.
  • Dopo modifiche a certificati o ciphers, riavvia il servizio RD Gateway e testa da un client “pulito”.

FAQ operative

Posso usare un wildcard?

Sì, purché il SAN includa l’FQDN effettivamente utilizzato dai client e la catena sia completa. Verifica comunque la compatibilità dei client con le suite offerte dalla CA emittente.

Mi conviene ECDSA o RSA?

In ambienti eterogenei e con client legacy, RSA 2048/3072 resta la scelta più compatibile per il ruolo RD Gateway. ECDSA è più moderno ed efficiente ma richiede che tutti i client supportino ciphers ECDSA.

Serve la chiave privata exportable?

È consigliato: semplifica la distribuzione dello stesso certificato su più nodi (Gateway multipli, Web Access, Broker) e gli scenari di DR.

Come verifico CRL/OCSP?

Usa certutil -verify -urlfetch puntando al CER del certificato. Se il server non può raggiungere la CRL o l’OCSP e la CA richiede la verifica, l’handshake può fallire o subire time‑out.

Checklist finale “pronta per change request”

  1. Installare nuovo certificato con chiave privata nello store Local Computer → Personal su tutti i nodi RDS.
  2. Verificare CN/SAN, EKU, catena completa e reachability CRL/OCSP dal server.
  3. Allineare Deployment Properties → Certificates su tutti i ruoli con Set-RDCertificate.
  4. Riavviare TSGateway, Tssdis, TermService e IIS (o eseguire iisreset).
  5. Se presente bilanciatore/proxy, aggiornare il certificato anche lì.
  6. Aggiornare feed RD Web e ripubblicare i file .rdp.
  7. Pulire credenziali e cache certificati sui client pilota, quindi testare.
  8. Abilitare log avanzati solo in caso di esiti negativi, quindi disabilitarli.

Conclusioni

Nel 90% dei casi, l’errore 0x300000d successivo al rinnovo del certificato su una farm RDS Windows Server 2016 si risolve ripercorrendo con metodo la catena TLS: certificato giusto, thumbprint allineato, catena completa, ciphers coerenti e cache client pulita. Procedere con la sequenza di verifiche proposta consente di ripristinare l’accesso senza interventi invasivi o downtime prolungati.

Appendice: raccolta comandi “tutto in uno”

# 1) Inventario certificati su tutti i server RDS
$servers = 'RDGW01','RDWA01','RDBR01','RDSH01','RDSH02'
Invoke-Command -ComputerName $servers -ScriptBlock {
  Write-Host "=== $env:COMPUTERNAME ==="
  Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Subject, NotAfter, Thumbprint
}

2) Allineamento certificati RDS (sostituisci path e password)

\$pfx = 'C:\temp\gateway\_new\.pfx'
\$pwd = ConvertTo-SecureString 'PASSWORD\_PFX' -AsPlainText -Force
Import-Module RemoteDesktop
Set-RDCertificate -Role RDGateway    -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDWebAccess  -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDPublishing -ImportPath \$pfx -Password \$pwd -Force
Set-RDCertificate -Role RDRedirector -ImportPath \$pfx -Password \$pwd -Force

3) Riavvio servizi critici (un server per volta)

Invoke-Command -ComputerName \$servers -ScriptBlock {
Stop-Service TSGateway   -ErrorAction SilentlyContinue
Stop-Service Tssdis      -ErrorAction SilentlyContinue
& iisreset /stop
Start-Sleep -Seconds 2
Start-Service Tssdis     -ErrorAction SilentlyContinue
Start-Service TSGateway  -ErrorAction SilentlyContinue
& iisreset /start
}

4) Verifica TLS 1.2 abilitato (server)

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"

Seguendo le verifiche sopra descritte, la maggior parte degli amministratori risolve il problema senza dover ripristinare l’intera infrastruttura RDS.

Riepilogo punti chiave

  • Allinea thumbprint del certificato su tutti i ruoli RDS.
  • Controlla CN/SAN, catena e CRL/OCSP.
  • Valida TLS 1.2 e cipher suite compatibili con i tuoi client.
  • Aggiorna RD Web Feed e ripubblica i .rdp.
  • Pulisci cache e credenziali lato client.
  • Usa log RdpCoreTS per capire il punto esatto di failure.
Python
Certificati SSL Errore 0x300000d RD Gateway RDP RDS TLS Windows Server 2016
Indice