Citrix Virtual Apps and Desktops

Transport Layer Security (TLS)

April 27, 2026

Grazie al contributo di:

C C

Citrix Virtual Apps and Desktops supportano il protocollo Transport Layer Security (TLS) per le connessioni basate su TCP tra i componenti. Citrix Virtual Apps and Desktops supportano anche il protocollo Datagram Transport Layer Security (DTLS) per le connessioni ICA/HDX basate su UDP, utilizzando il trasporto adattivo.

TLS e DTLS sono simili e supportano gli stessi certificati digitali. La configurazione di un sito Citrix Virtual Apps o Citrix Virtual Desktops™ per l’utilizzo di TLS lo configura anche per l’utilizzo di DTLS. Utilizzare le seguenti procedure; i passaggi sono comuni sia a TLS che a DTLS, salvo dove diversamente specificato:

Ottenere, installare e registrare un certificato server su tutti i Delivery Controller e configurare una porta con il certificato TLS. Per i dettagli, vedere Installare i certificati server TLS sui Controller.

Facoltativamente, è possibile modificare le porte utilizzate dal Controller per l’ascolto del traffico HTTP e HTTPS.
Abilitare le connessioni TLS tra l’app Citrix Workspace™ e i Virtual Delivery Agent (VDA) completando le seguenti attività:
- Configurare TLS sulle macchine in cui sono installati i VDA. (Per comodità, i riferimenti successivi alle macchine in cui sono installati i VDA sono semplicemente chiamati “VDA”). Per informazioni generali, vedere Impostazioni TLS sui VDA. Si consiglia vivamente di utilizzare lo script PowerShell fornito da Citrix per configurare TLS/DTLS. Per i dettagli, vedere Configurare TLS su un VDA utilizzando lo script PowerShell. Tuttavia, se si desidera configurare TLS/DTLS manualmente, vedere Configurare manualmente TLS su un VDA.
- Configurare TLS nei Delivery Group contenenti i VDA eseguendo una serie di cmdlet PowerShell in Studio. Per i dettagli, vedere Configurare TLS sui Delivery Group.
  
  Requisiti e considerazioni:
  - L’abilitazione delle connessioni TLS tra utenti e VDA è valida solo per i siti XenApp 7.6 e XenDesktop 7.6, più le versioni supportate successive.
  - Configurare TLS nei Delivery Group e sui VDA dopo aver installato i componenti, creato un sito, creato cataloghi di macchine e creato Delivery Group.
  - Per configurare TLS nei Delivery Group, è necessario disporre dell’autorizzazione per modificare le regole di accesso del Controller. Un amministratore completo dispone di questa autorizzazione.
  - Per configurare TLS sui VDA, è necessario essere un amministratore di Windows sulla macchina in cui è installato il VDA.
  - Sui VDA in pool che sono forniti da Machine Creation Services™ o Provisioning Services, l’immagine della macchina VDA viene ripristinata al riavvio, causando la perdita delle impostazioni TLS precedenti. Eseguire lo script PowerShell ogni volta che il VDA viene riavviato per riconfigurare le impostazioni TLS.

Avviso:

Per le attività che includono l’utilizzo del registro di Windows, la modifica errata del registro può causare seri problemi che potrebbero richiedere la reinstallazione del sistema operativo. Citrix® non può garantire che i problemi derivanti dall’uso errato dell’Editor del Registro di sistema possano essere risolti. Utilizzare l’Editor del Registro di sistema a proprio rischio. Assicurarsi di eseguire il backup del registro prima di modificarlo.

Per informazioni sull’abilitazione di TLS al database del sito, vedere CTX137556.

Installare i certificati server TLS sui Controller

Per HTTPS, il servizio XML supporta le funzionalità TLS utilizzando certificati server, non certificati client. Questa sezione descrive l’acquisizione e l’installazione dei certificati TLS nei Delivery Controller. Gli stessi passaggi possono essere applicati ai Cloud Connector per crittografare il traffico STA e XML.

Sebbene esistano vari tipi di autorità di certificazione e metodi per richiedere certificati da esse, questo articolo descrive la Microsoft Certificate Authority. La Microsoft Certificate Authority deve avere un modello di certificato pubblicato con lo scopo di Autenticazione server.

Se la Microsoft Certificate Authority è integrata in un dominio Active Directory o nella foresta attendibile a cui sono uniti i Delivery Controller, è possibile acquisire un certificato dalla procedura guidata di registrazione certificati dello snap-in MMC Certificati.

Richiesta e installazione di un certificato

Sul Delivery Controller™, aprire la console MMC e aggiungere lo snap-in Certificati. Quando richiesto, selezionare Account computer.
Espandere Personale > Certificati, quindi utilizzare il comando del menu contestuale Tutte le attività > Richiedi nuovo certificato.
Fare clic su Avanti per iniziare e su Avanti per confermare che si sta acquisendo il certificato dalla registrazione di Active Directory.
Selezionare il modello per il certificato di autenticazione server. Se il modello è stato impostato per fornire automaticamente i valori per l’Oggetto, è possibile fare clic su Registra senza fornire ulteriori dettagli.
Per fornire ulteriori dettagli per il modello di certificato, fare clic sul pulsante freccia Dettagli e configurare quanto segue:

Nome soggetto: selezionare Nome comune e aggiungere l’FQDN del Delivery Controller.

Nome alternativo: selezionare DNS e aggiungere l’FQDN del Delivery Controller.

Configurazione della porta di ascolto SSL/TLS

Se il componente IIS di Windows è installato sullo stesso server, che è installato come parte di Web Studio e Director, è possibile configurare TLS utilizzando IIS. Per maggiori informazioni, vedere Abilitare TLS su Web Studio e Director. In caso contrario, per configurare il certificato utilizzando PowerShell:

Per verificare se esiste un certificato associato, aprire un prompt dei comandi ed eseguire netsh http show sslcert:
```
netsh http show sslcert

```
Se esiste un’associazione esistente, eliminarla.
```
netsh http delete sslcert ipport=0.0.0.0:443

```
Sostituire 0.0.0.0:443 con un indirizzo IP e una porta specifici se ne era stato specificato uno nell’associazione esistente.
Trovare l’identificazione personale (thumbprint) del certificato installato in precedenza. Per visualizzare l’identificazione personale, aprire Gestisci certificati computer, individuare il certificato, aprirlo e andare alla scheda Dettagli.

In alternativa, è possibile utilizzare PowerShell. Ad esempio, il seguente script cerca un certificato il cui nome comune corrisponde al nome host del server e stampa l’identificazione personale:
```
$HostName = ([System.Net.Dns]::GetHostByName(($env:computerName))).Hostname
$Thumbprint = (Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -match ("CN=" + $HostName)}).Thumbprint -join ';'
Write-Host -Object "Certificate Thumbprint for $($HostName): $($Thumbprint)" -Foreground Yellow

```
Se il nome comune del certificato non corrisponde ai nomi host, l’operazione fallirà. Se esistono più certificati per il nome host, questo restituirà più identificazioni personali concatenate e sarà necessario scegliere l’identificazione personale appropriata.

L’esempio seguente cerca un certificato per nome descrittivo:
```
$friendlyName = "My certificate name"
$Thumbprint = (Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.FriendlyName -eq $friendlyNam}).Thumbprint -join ';'
Write-Host -Object "Certificate Thumbprint for $friendlyName: $($Thumbprint)" -Foreground Yellow

```
Se esistono più certificati con il nome descrittivo specificato, questo restituirà più identificazioni personali concatenate e sarà necessario scegliere l’identificazione personale appropriata.
Per associare il certificato alla porta, utilizzare il comando netsh http add sslcert:
```
netsh http add sslcert ipport=[IP address]:443 certhash=[certificate hash] appid=[application GUID] disablelegacytls=enable

```
- ipport: L’indirizzo IP e la porta. L’utilizzo di 0.0.0.0:443 applica questa impostazione a tutti gli indirizzi IP. È possibile specificare invece un indirizzo IP specifico.
- certhash: L’identificazione personale (thumbprint) del certificato identificato nel passaggio precedente.
- appid: Il GUID del servizio Citrix Broker.
  
  Nota:
  
  Quando si rinnova un certificato o si esegue un nuovo binding, utilizzare l’appid specifico associato al Broker Service anziché un GUID arbitrario.
  
  Per trovare l’appid corretto per il servizio Citrix Broker:
  1. Aprire una finestra del prompt dei comandi di PowerShell come amministratore ed eseguire il seguente comando:
    Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" 
  2. Individuare l’IdentifyingNumber (GUID) per il servizio Citrix Broker nell’output (ad esempio, {D333C884-187F-447C-8C67-463F33989C8F}). Utilizzare questo GUID per il parametro appid.
- disablelegacytls=enable: Disabilita le versioni legacy di TLS. Questo parametro è disponibile su Windows 2022 e versioni successive. Su Windows 2022 disabilita TLS 1.0 e 1.1. Su Windows 2025 questo non è necessario in quanto TLS 1.0 e 1.1 sono disabilitati per impostazione predefinita.
Ad esempio, eseguire il seguente comando per associare il certificato con identificazione personale bc96f958848639fd101a793b87915d5f2829b0b6 alla porta 443 su tutti gli indirizzi IP:
```
netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable

```

Una volta abilitato HTTPS, è necessario configurare tutte le distribuzioni StoreFront e i Netscaler Gateway per utilizzare HTTPS anziché HTTP per connettersi al Delivery Controller.

Nota:

Se il Controller è installato su Windows Server 2016 e StoreFront è installato su Windows Server 2012 R2, è necessaria una modifica della configurazione sul Controller per modificare l’ordine delle suite di cifratura TLS. Questa modifica della configurazione non è necessaria per Controller e StoreFront con altre combinazioni di versioni di Windows Server.

L’elenco dell’ordine delle suite di cifratura deve includere le suite di cifratura TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (o entrambe); e queste suite di cifratura devono precedere qualsiasi suite di cifratura TLS_DHE_.

Utilizzando l’Editor Criteri di gruppo di Microsoft, accedere a Configurazione computer > Modelli amministrativi > Rete > Impostazioni di configurazione SSL.
Modificare il criterio “Ordine suite di cifratura SSL”. Per impostazione predefinita, questo criterio è impostato su “Non configurato”. Impostare questo criterio su Abilitato.
Disporre le suite nell’ordine corretto; rimuovere le suite di cifratura che non si desidera utilizzare.

Assicurarsi che TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 preceda qualsiasi suite di cifratura TLS_DHE_.

Su Microsoft MSDN, vedere anche Prioritizing Schannel Cipher Suites.

Modificare le porte HTTP o HTTPS

Per impostazione predefinita, il servizio XML sul Controller è in ascolto sulla porta 80 per il traffico HTTP e sulla porta 443 per il traffico HTTPS. Sebbene sia possibile utilizzare porte non predefinite, è necessario essere consapevoli dei rischi per la sicurezza derivanti dall’esposizione di un Controller a reti non attendibili. La distribuzione di un server StoreFront autonomo è preferibile alla modifica delle impostazioni predefinite.

Per modificare le porte HTTP o HTTPS predefinite utilizzate dal Controller, eseguire il seguente comando da Studio:

BrokerService.exe -WIPORT \<porta-http> -WISSLPORT \<porta-https>

dove <porta-http> è il numero di porta per il traffico HTTP e <porta-https> è il numero di porta per il traffico HTTPS.

Nota:

Dopo aver modificato una porta, Studio potrebbe visualizzare un messaggio sulla compatibilità e l’aggiornamento della licenza. Per risolvere il problema, registrare nuovamente le istanze del servizio utilizzando la seguente sequenza di cmdlet PowerShell:

Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->

Imporre solo traffico HTTPS

Se si desidera che il servizio XML ignori il traffico HTTP, creare la seguente impostazione del Registro di sistema in HKLM\Software\Citrix\DesktopServer\ sul Controller e quindi riavviare il servizio Broker.

Per ignorare il traffico HTTP, creare il valore DWORD XmlServicesEnableNonSsl e impostarlo su 0.

Esiste un valore DWORD del Registro di sistema corrispondente che è possibile creare per ignorare il traffico HTTPS: DWORD XmlServicesEnableSsl. Assicurarsi che non sia impostato su 0.

Impostazioni TLS sui VDA

Un gruppo di consegna non può avere una combinazione di alcuni VDA con TLS configurato e alcuni VDA senza TLS configurato. Prima di configurare TLS per un gruppo di consegna, assicurarsi di aver già configurato TLS per tutti i VDA in quel gruppo di consegna.

Quando si configura TLS sui VDA, le autorizzazioni sul certificato TLS installato vengono modificate, concedendo al servizio ICA® l’accesso in lettura alla chiave privata del certificato e informando il servizio ICA di quanto segue:

Quale certificato nell’archivio certificati utilizzare per TLS.
Quale numero di porta TCP utilizzare per le connessioni TLS.

Il firewall di Windows (se abilitato) deve essere configurato per consentire le connessioni in ingresso su questa porta TCP. Questa configurazione viene eseguita automaticamente quando si utilizza lo script PowerShell.
Quali versioni del protocollo TLS consentire.

Importante:

Citrix consiglia di rivedere l’utilizzo di SSLv3 e di riconfigurare tali distribuzioni per rimuovere il supporto per SSLv3, ove appropriato. Vedere CTX200238.

Le versioni del protocollo TLS supportate seguono una gerarchia (dalla più bassa alla più alta): SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2. Specificare la versione minima consentita; tutte le connessioni di protocollo che utilizzano quella versione o una versione superiore sono consentite.

Ad esempio, se si specifica TLS 1.1 come versione minima, sono consentite le connessioni di protocollo TLS 1.1 e TLS 1.2. Se si specifica SSL 3.0 come versione minima, sono consentite le connessioni per tutte le versioni supportate. Se si specifica TLS 1.2 come versione minima, sono consentite solo le connessioni TLS 1.2.

DTLS 1.0 corrisponde a TLS 1.1 e DTLS 1.2 corrisponde a TLS 1.2.
Quali suite di cifratura TLS consentire.

Una suite di cifratura seleziona la crittografia utilizzata per una connessione. Client e VDA possono supportare diversi set di suite di cifratura. Quando un client (Citrix Workspace app o StoreFront) si connette e invia un elenco di suite di cifratura TLS supportate, il VDA abbina una delle suite di cifratura del client a una delle suite di cifratura nel proprio elenco di suite di cifratura configurate e accetta la connessione. Se non esiste una suite di cifratura corrispondente, il VDA rifiuta la connessione.

Il VDA supporta tre set di suite di cifratura (noti anche come modalità di conformità): GOV(ernment), COM(mercial) e ALL. Le suite di cifratura accettabili dipendono anche dalla modalità FIPS di Windows; vedere http://support.microsoft.com/kb/811833 per informazioni sulla modalità FIPS di Windows. La seguente tabella elenca le suite di cifratura in ogni set:

Suite di cifratura TLS/DTLS	ALL	COM	GOV	ALL	COM	GOV
Modalità FIPS	Disattivata	Disattivata	Disattivata	Attivata	Attivata	Attivata
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*	X		X	X		X
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	X		X	X		X
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	X	X		X	X

* Non supportato in Windows Server 2012 R2.

Nota:

Il VDA non supporta le suite di cifratura DHE (ad esempio, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 e TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Se selezionate da Windows, potrebbero non essere utilizzate da Receiver.

Se si utilizza un Citrix Gateway, fare riferimento alla documentazione di Citrix ADC per informazioni sul supporto delle suite di cifratura per la comunicazione back-end. Per informazioni sul supporto delle suite di cifratura TLS, vedere Cifre disponibili sugli appliance Citrix ADC. Per informazioni sul supporto delle suite di cifratura DTLS, vedere Supporto cifratura DTLS.

Richiesta e installazione di un certificato

Sul VDA, aprire la console MMC e aggiungere lo snap-in Certificati. Quando richiesto, selezionare Account computer.
Espandere Personale > Certificati, quindi utilizzare il comando del menu contestuale Tutte le attività > Richiedi nuovo certificato.
Fare clic su Avanti per iniziare e su Avanti per confermare che si sta acquisendo il certificato dall’iscrizione di Active Directory.
Selezionare il modello per il certificato di autenticazione server. Sono accettabili sia il valore predefinito di Windows Computer che Web Server esportabile. Se il modello è stato configurato per fornire automaticamente i valori per l’Oggetto, è possibile fare clic su Registra senza fornire ulteriori dettagli.
Per fornire ulteriori dettagli per il modello di certificato, fare clic su Dettagli e configurare quanto segue:

Nome oggetto — selezionare il tipo Nome comune e aggiungere l’FQDN del VDA

Nome alternativo — selezionare il tipo DNS e aggiungere l’FQDN del VDA

Nota:

Utilizzare l’iscrizione automatica dei certificati dei servizi certificati di Active Directory per automatizzare l’emissione e la distribuzione dei certificati ai VDA. Questo è descritto in https://support.citrix.com/article/CTX205473.

È possibile utilizzare certificati wildcard per consentire a un singolo certificato di proteggere più VDA:

Nome oggetto — selezionare il tipo Nome comune e immettere il *.primary.domain dei VDA

Nome alternativo — selezionare il tipo DNS e aggiungere il *.primary.domain dei VDA

È possibile utilizzare certificati SAN per consentire a un singolo certificato di proteggere più VDA specifici:

Nome oggetto — selezionare il tipo Nome comune e immettere una stringa per aiutare a identificare l’utilizzo del certificato

Nome alternativo — selezionare il tipo DNS e aggiungere una voce per l’FQDN di ciascun VDA. Mantenere il numero di nomi alternativi al minimo per garantire una negoziazione TLS ottimale.

Nota:

Sia i certificati wildcard che i certificati SAN richiedono che sia selezionata l’opzione Rendi esportabile la chiave privata nella scheda Chiave privata:

Configurare TLS su un VDA utilizzando lo script PowerShell

Installare il certificato TLS nell’area Computer locale > Personale > Certificati dell’archivio certificati. Se in quella posizione risiede più di un certificato, fornire l’identificazione personale del certificato allo script PowerShell.

Nota:

A partire da XenApp e XenDesktop 7.16 LTSR, lo script PowerShell trova il certificato corretto in base all’FQDN del VDA. Non è necessario fornire l’identificazione personale quando è presente un solo certificato per l’FQDN del VDA.

Lo script Enable-VdaSSL.ps1 abilita o disabilita il listener TLS su un VDA. Questo script è disponibile nella cartella Supporto > Strumenti > SslSupport sul supporto di installazione.

Quando si abilita TLS, le suite di cifratura DHE vengono disabilitate. Le suite di cifratura ECDHE non sono interessate.

Quando si abilita TLS, lo script disabilita tutte le regole esistenti del firewall di Windows per la porta TCP specificata. Aggiunge quindi una nuova regola che consente al servizio ICA di accettare connessioni in ingresso solo sulle porte TCP e UDP TLS. Disabilita anche le regole del firewall di Windows per:

Citrix ICA (predefinito: 1494)
Citrix CGP (predefinito: 2598)
Citrix WebSocket (predefinito: 8008)

L’effetto è che gli utenti possono connettersi solo utilizzando TLS o DTLS. Non possono utilizzare ICA/HDX, ICA/HDX con Session Reliability o HDX su WebSocket, senza TLS o DTLS.

Nota:

DTLS non è supportato con ICA/HDX Audio su UDP Real-time Transport o con ICA/HDX Framehawk.

Vedere Porte di rete.

Lo script contiene le seguenti descrizioni della sintassi, oltre a esempi aggiuntivi; è possibile utilizzare uno strumento come Notepad++ per rivedere queste informazioni.

Importante:

Specificare il parametro Enable o Disable e il parametro CertificateThumbPrint. Gli altri parametri sono facoltativi.

Sintassi

Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]

Parametro	Descrizione
Enable	Installa e abilita il listener TLS sul VDA. È richiesto questo parametro o il parametro Disable.
Disable	Disabilita il listener TLS sul VDA. È richiesto questo parametro o il parametro Enable. Se si specifica questo parametro, nessun altro parametro è valido.
CertificateThumbPrint “"	Identificazione personale del certificato TLS nell’archivio certificati, racchiusa tra virgolette. Lo script utilizza l’identificazione personale specificata per selezionare il certificato da usare. Se questo parametro viene omesso, viene selezionato un certificato errato.
SSLPort	Porta TLS. Predefinito: 443
SSLMinVersion “"	Versione minima del protocollo TLS, racchiusa tra virgolette. Valori validi: “TLS_1.0” (predefinito), “TLS_1.1” e “TLS_1.2”.
SSLCipherSuite “"	Suite di crittografia TLS, racchiusa tra virgolette. Valori validi: “GOV”, “COM” e “ALL” (predefinito).

Esempi

Lo script seguente installa e abilita il valore della versione del protocollo TLS. L’identificazione personale (rappresentata come “12345678987654321” in questo esempio) viene utilizzata per selezionare il certificato da usare.

Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"

Lo script seguente installa e abilita il listener TLS e specifica la porta TLS 400, la suite di crittografia GOV e un valore minimo del protocollo TLS 1.2. L’identificazione personale (rappresentata come “12345678987654321” in questo esempio) viene utilizzata per selezionare il certificato da usare.

Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.2"
-SSLCipherSuite "All"

Lo script seguente disabilita il listener TLS sul VDA.

Enable-VdaSSL -Disable

Configurare manualmente TLS su un VDA

Quando si configura manualmente TLS su un VDA, si concede l’accesso generico in lettura alla chiave privata del certificato TLS per il servizio appropriato su ogni VDA: NT SERVICE\PorticaService per un VDA per sistema operativo Windows a sessione singola o NT SERVICE\TermService per un VDA per sistema operativo Windows a sessione multipla. Sulla macchina in cui è installato il VDA:

PASSAGGIO 1. Avviare la console di gestione Microsoft (MMC): Start > Esegui > mmc.exe.

PASSAGGIO 2. Aggiungere lo snap-in Certificati alla MMC:

Selezionare File > Aggiungi/Rimuovi snap-in.
Selezionare Certificati e quindi fare clic su Aggiungi.
Quando viene richiesto “Questo snap-in gestirà sempre i certificati per:”, scegliere “Account computer” e quindi fare clic su Avanti.
Quando viene richiesto “Selezionare il computer che si desidera che questo snap-in gestisca”, scegliere “Computer locale” e quindi fare clic su Fine.

PASSAGGIO 3. In Certificati (Computer locale) > Personale > Certificati, fare clic con il pulsante destro del mouse sul certificato e quindi selezionare Tutte le attività > Gestisci chiavi private.

PASSAGGIO 4. L’Editor dell’elenco di controllo di accesso visualizza “Autorizzazioni per le chiavi private di (Nome descrittivo)” dove (Nome descrittivo) è il nome del certificato TLS. Aggiungere uno dei seguenti servizi e concedergli l’accesso in lettura:

Per un VDA per sistema operativo Windows a sessione singola, “PORTICASERVICE”
Per un VDA per sistema operativo Windows a sessione multipla, “TERMSERVICE”

PASSAGGIO 5. Fare doppio clic sul certificato TLS installato. Nella finestra di dialogo del certificato, selezionare la scheda Dettagli e quindi scorrere fino in fondo. Fare clic su Identificazione personale.

PASSAGGIO 6. Eseguire regedit e passare a HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

Modificare la chiave Identificazione personale SSL e copiare il valore dell’identificazione personale del certificato TLS in questo valore binario. È possibile ignorare tranquillamente gli elementi sconosciuti nella finestra di dialogo Modifica valore binario (come ‘0000’ e caratteri speciali).
Modificare la chiave SSLEnabled e cambiare il valore DWORD in 1. (Per disabilitare SSL in seguito, cambiare il valore DWORD in 0.)
Se si desidera modificare le impostazioni predefinite (facoltativo), utilizzare quanto segue nello stesso percorso del Registro di sistema:

SSLPort DWORD – Numero di porta SSL. Predefinito: 443.

SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Predefinito: 2 (TLS 1.0).

SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Predefinito: 3 (ALL).

PASSAGGIO 7. Assicurarsi che le porte TCP e UDP TLS siano aperte nel Firewall di Windows se non sono quelle predefinite 443. (Quando si crea la regola in entrata nel Firewall di Windows, assicurarsi che le sue proprietà abbiano le voci “Consenti la connessione” e “Abilitato” selezionate.)

PASSAGGIO 8. Assicurarsi che nessun’altra applicazione o servizio (come IIS) stia utilizzando la porta TCP TLS.

PASSAGGIO 9. Per i VDA per sistema operativo Windows a sessione multipla, riavviare la macchina affinché le modifiche abbiano effetto. (Non è necessario riavviare le macchine contenenti VDA per sistema operativo Windows a sessione singola.)

Importante:

È necessario un passaggio aggiuntivo quando il VDA si trova su Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o versione successiva supportata. Ciò influisce sulle connessioni da Citrix Receiver per Windows (versioni 4.6-4.9), Citrix Workspace app per HTML5 e Citrix Workspace app per Chrome. Ciò include anche le connessioni che utilizzano Citrix Gateway.

Questo passaggio è richiesto anche per tutte le connessioni che utilizzano Citrix Gateway, per tutte le versioni VDA, se TLS è configurato tra Citrix Gateway e il VDA. Ciò influisce su tutte le versioni di Citrix Receiver™.

Sul VDA (Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o versione successiva), utilizzando l’Editor Criteri di gruppo, passare a Configurazione computer > Criteri > Modelli amministrativi > Rete > Impostazioni di configurazione SSL > Ordine suite di crittografia SSL. Selezionare il seguente ordine:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256

Nota:

I primi sei elementi specificano anche la curva ellittica, P384 o P256. Assicurarsi che “curve25519” non sia selezionato. La modalità FIPS non impedisce l’uso di “curve25519”.

Quando questa impostazione di Criteri di gruppo è configurata, il VDA seleziona una suite di crittografia solo se appare in entrambe le liste: la lista dei Criteri di gruppo e la lista per la modalità di conformità selezionata (COM, GOV o ALL). La suite di crittografia deve anche apparire nella lista inviata dal client (Citrix Workspace app o StoreFront).

Questa configurazione dei Criteri di gruppo influisce anche su altre applicazioni e servizi TLS sul VDA. Se le applicazioni richiedono suite di crittografia specifiche, potrebbe essere necessario aggiungerle a questa lista dei Criteri di gruppo.

Importante:

Anche se le modifiche ai Criteri di gruppo vengono visualizzate quando vengono applicate, le modifiche ai Criteri di gruppo per la configurazione TLS hanno effetto solo dopo il riavvio del sistema operativo. Pertanto, per i desktop in pool, applicare le modifiche ai Criteri di gruppo per la configurazione TLS all’immagine di base.

Configurare TLS sui gruppi di consegna

Completare questa procedura per ogni gruppo di consegna che contiene VDA configurati per le connessioni TLS.

Da Studio, aprire la console PowerShell.
Eseguire asnp Citrix.* per caricare i cmdlet del prodotto Citrix.
Eseguire Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
Eseguire Set-BrokerSite -DnsResolutionEnabled $true.

Risoluzione dei problemi

Se si verifica un errore di connessione, controllare il registro eventi di sistema sul VDA.

Quando si utilizza Citrix Workspace app per Windows, se si riceve un errore di connessione che indica un errore TLS, disabilitare Desktop Viewer e quindi provare a connettersi di nuovo. Anche se la connessione fallisce comunque, potrebbe essere fornita una spiegazione del problema TLS sottostante. Ad esempio, è stato specificato un modello errato durante la richiesta di un certificato all’autorità di certificazione.

La maggior parte delle configurazioni che utilizzano HDX™ Adaptive Transport funzionano correttamente con DTLS, incluse quelle che utilizzano le versioni più recenti di Citrix Workspace app, Citrix Gateway e VDA. Alcune configurazioni che utilizzano DTLS tra Citrix Workspace app e Citrix Gateway, e che utilizzano DTLS tra Citrix Gateway e VDA, richiedono un’azione aggiuntiva.

È necessaria un’azione aggiuntiva se:

la versione di Citrix Receiver supporta HDX Adaptive Transport e DTLS: Receiver per Windows (4.7, 4.8, 4.9), Receiver per Mac (12.5, 12.6, 12.7), Receiver per iOS (7.2, 7.3.x) o Receiver per Linux (13.7)

e si applica anche una delle seguenti condizioni:

la versione di Citrix Gateway supporta DTLS al VDA, ma la versione del VDA non supporta DTLS (versione 7.15 o precedente),
la versione del VDA supporta DTLS (versione 7.16 o successiva), ma la versione di Citrix Gateway non supporta DTLS al VDA.

Per evitare che le connessioni da Citrix Receiver falliscano, eseguire una delle seguenti operazioni:

aggiornare Citrix Receiver, a Receiver per Windows versione 4.10 o successiva, Receiver per Mac 12.8 o successiva, o Receiver per iOS versione 7.5 o successiva; oppure,
aggiornare Citrix Gateway a una versione che supporti DTLS al VDA; oppure,
aggiornare il VDA, alla versione 7.16 o successiva; oppure,
disabilitare DTLS sul VDA; oppure,
disabilitare HDX Adaptive Transport.

Nota:

Un aggiornamento adatto per Receiver per Linux non è ancora disponibile. Receiver per Android (versione 3.12.3) non supporta HDX Adaptive Transport e DTLS tramite Citrix Gateway, e quindi non è interessato.

Per disabilitare DTLS sul VDA, modificare la configurazione del firewall del VDA per disabilitare la porta UDP 443. Vedere Porte di rete.

Comunicazione tra Controller e VDA

La protezione a livello di messaggio di Windows Communication Framework (WCF) protegge la comunicazione tra il Controller e il VDA. Non è richiesta una protezione aggiuntiva a livello di trasporto tramite TLS. La configurazione WCF utilizza Kerberos per l’autenticazione reciproca tra Controller e VDA. La crittografia utilizza AES in modalità CBC con una chiave a 256 bit. L’integrità del messaggio utilizza SHA-1.

Secondo Microsoft, i protocolli di sicurezza utilizzati da WCF sono conformi agli standard OASIS (Organization for the Advancement of Structured Information Standards), incluso WS-SecurityPolicy 1.2. Inoltre, Microsoft afferma che WCF supporta tutte le suite di algoritmi elencate in Security Policy 1.2.

La comunicazione tra il Controller e il VDA utilizza la suite di algoritmi basic256, i cui algoritmi sono quelli sopra indicati.

TLS e reindirizzamento video HTML5 e reindirizzamento del contenuto del browser

È possibile utilizzare il reindirizzamento video HTML5 e il reindirizzamento del contenuto del browser per reindirizzare i siti Web HTTPS. Il JavaScript iniettato in tali siti Web deve stabilire una connessione TLS al servizio di reindirizzamento video HTML5 Citrix HDX in esecuzione sul VDA. Per raggiungere questo obiettivo, il servizio di reindirizzamento video HTML5 genera due certificati personalizzati nell’archivio certificati sul VDA. L’arresto del servizio rimuove i certificati.

La policy di reindirizzamento video HTML5 è disabilitata per impostazione predefinita.

Il reindirizzamento del contenuto del browser è abilitato per impostazione predefinita.

Per maggiori informazioni sul reindirizzamento video HTML5, vedere Impostazioni dei criteri multimediali.

La versione ufficiale di questo contenuto è in inglese. Per alcuni dei contenuti della documentazione Cloud Software Group è stata impiegata la traduzione automatica solo per comodità. Cloud Software Group non ha alcun controllo sui contenuti tradotti in modo automatico, che possono contenere errori, imprecisioni o linguaggio inadatto. Non viene offerta alcuna garanzia di alcun tipo, espressa o implicita, circa l'accuratezza, l'affidabilità, l'idoneità o la correttezza di qualsiasi traduzione dall'originale inglese in qualsiasi altra lingua, o che il prodotto o servizio Cloud Software Group sia conforme a qualsiasi contenuto in traduzione automatica, e qualsiasi garanzia fornita ai sensi del contratto di licenza per l'utente finale applicabile o i termini di servizio, o qualsiasi altro accordo con Cloud Software Group che il prodotto o il servizio sia conforme a qualsiasi documentazione non si applicheranno nella misura in cui tale documentazione sia in traduzione automatica. Cloud Software Group non sarà ritenuta responsabile per eventuali danni o problemi che potrebbero derivare dall'utilizzo di contenuti per cui si è impiegata la traduzione automatica.

È stato utile?

Transport Layer Security (TLS)

April 27, 2026

Grazie al contributo di:

C C

April 27, 2026

Grazie al contributo di:

C C

In questo articolo

Installare i certificati server TLS sui Controller
Modificare le porte HTTP o HTTPS
Impostazioni TLS sui VDA
Comunicazione tra Controller e VDA

È stato utile?