Transport Layer Security (TLS)
Citrix Virtual Apps e Desktops supportano il protocollo Transport Layer Security (TLS) per le connessioni basate su TCP tra i componenti. Citrix Virtual Apps e 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, oltre alle versioni successive supportate.
- 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 Windows sulla macchina in cui è installato il VDA.
- Sui VDA in pool 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 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 sul pulsante freccia Dettagli e configurare quanto segue:
Nome oggetto: 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 Windows IIS è installato sullo stesso server, che viene installato come parte di Web Studio e Director, è possibile configurare TLS utilizzando IIS. Per maggiori informazioni, vedere Abilitare TLS su Web Studio e Director. Altrimenti, 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 <!--NeedCopy--> -
Se esiste un’associazione esistente, eliminarla.
netsh http delete sslcert ipport=0.0.0.0:443 <!--NeedCopy-->Sostituire
0.0.0.0:443con 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, lo script seguente 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 <!--NeedCopy-->Se il nome comune del certificato non corrisponde ai nomi host, l’operazione fallirà. Se esistono più certificati per il nome host, verranno restituiti più thumbprint concatenati e sarà necessario scegliere il thumbprint appropriato.
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 <!--NeedCopy-->Se esistono più certificati con il nome descrittivo specificato, verranno restituiti più thumbprint concatenati e sarà necessario scegliere il thumbprint appropriato.
-
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 <!--NeedCopy-->-
ipport: L’indirizzo IP e la porta. L’utilizzo di 0.0.0.0:443 lo applica a tutti gli indirizzi IP. È possibile invece specificare 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’
appidspecifico associato al servizio Broker anziché un GUID arbitrario.Per trovare l’
appidcorretto per il servizio Citrix Broker:-
Aprire una finestra del prompt dei comandi PowerShell come amministratore ed eseguire il comando seguente:
Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" <!--NeedCopy--> -
Individuare l’IdentifyingNumber (GUID) per il servizio Citrix Broker nell’output (ad esempio,
{D333C884-187F-447C-8C67-463F33989C8F}). Utilizzare questo GUID per il parametroappid.
-
-
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 è superfluo poiché TLS 1.0 e 1.1 sono disabilitati per impostazione predefinita.
Ad esempio, eseguire il comando seguente per associare il certificato con thumbprint
bc96f958848639fd101a793b87915d5f2829b0b6alla porta443su tutti gli indirizzi IP:netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable <!--NeedCopy--> -
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 cambiare 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, navigare in 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 eventuali 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 ascolta 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 comando seguente da Studio:
BrokerService.exe -WIPORT \<http-port> -WISSLPORT \<https-port>
dove <http-port> è il numero di porta per il traffico HTTP e <https-port> è il numero di porta per il traffico HTTPS.
Nota:
Dopo aver modificato una porta, Studio potrebbe visualizzare un messaggio sulla compatibilità della licenza e sull’aggiornamento. 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 in HKLM\Software\Citrix\DesktopServer\ sul Controller e quindi riavviare il servizio Broker.
Per ignorare il traffico HTTP, creare DWORD XmlServicesEnableNonSsl e impostarlo su 0.
Esiste un valore DWORD del registro corrispondente che è possibile creare per ignorare il traffico HTTPS: DWORD XmlServicesEnableSsl. Assicurarsi che non sia impostato su 0.
Impostazioni TLS sui VDA
Un Delivery Group non può avere una combinazione di alcuni VDA con TLS configurato e alcuni VDA senza TLS configurato. Prima di configurare TLS per un Delivery Group, assicurarsi di aver già configurato TLS per tutti i VDA in quel Delivery Group.
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 (app Citrix Workspace o StoreFront) si connette e invia un elenco di suite di cifratura TLS supportate, il VDA abbina una delle suite di cifratura del client con 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 tabella seguente elenca le suite di cifratura in ogni set:
| Suite di cifratura TLS/DTLS | ALL | COM | GOV | ALL | COM | GOV |
|---|---|---|---|---|---|---|
| Modalità FIPS | Off | Off | Off | On | On | On |
| 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 dalla registrazione di Active Directory.
-
Selezionare il modello per il certificato di autenticazione server. Sono accettabili sia il valore predefinito di Windows Computer che Web Server Exportable. 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 la registrazione automatica dei certificati di Active Directory Certificate Services 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 inserire il *.dominio.primario dei VDA
Nome alternativo — selezionare il tipo DNS e aggiungere il *.dominio.primario 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 inserire 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 (thumbprint) 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 (thumbprint) 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 Support > Tools > 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. Questo parametro o il parametro Disable è obbligatorio. |
| Disable | Disabilita il listener TLS sul VDA. Questo parametro o il parametro Enable è obbligatorio. Se si specifica questo parametro, nessun altro parametro è valido. |
| CertificateThumbPrint “ |
Identificazione personale (thumbprint) del certificato TLS nell’archivio certificati, racchiusa tra virgolette. Lo script utilizza l’identificazione personale specificata per selezionare il certificato che si desidera utilizzare. 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 cifratura 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 utilizzare.
Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
Lo script seguente installa e abilita il listener TLS e specifica la porta TLS 400, la suite di cifratura 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 utilizzare.
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 ciascun VDA: NT SERVICE\PorticaService per un VDA per Windows Single-session OS oppure NT SERVICE\TermService per un VDA per Windows Multi-session OS. 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 all’MMC:
- Selezionare File > Aggiungi/Rimuovi snap-in.
- Selezionare Certificati e quindi fare clic su Aggiungi.
- Quando richiesto con “Questo snap-in gestirà sempre i certificati per:” scegliere “Account computer” e quindi fare clic su Avanti.
- Quando richiesto con “Selezionare il computer che si desidera gestire con questo snap-in” 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 Elenco di controllo di accesso visualizza “Autorizzazioni per chiavi private (NomeDescrittivo)” dove (NomeDescrittivo) è il nome del certificato TLS. Aggiungere uno dei seguenti servizi e concedere l’accesso in lettura:
- Per un VDA per Windows Single-session OS, “PORTICASERVICE”
- Per un VDA per Windows Multi-session OS, “TERMSERVICE”
PASSAGGIO 5. Fare doppio clic sul certificato TLS installato. Nella finestra di dialogo del certificato, selezionare la scheda Dettagli e quindi scorrere fino alla fine. Fare clic su Identificazione personale.
PASSAGGIO 6. Eseguire regedit e andare a HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Modificare la chiave SSL Thumbprint 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 su 1. (Per disabilitare SSL in seguito, cambiare il valore DWORD su 0.)
-
Se si desidera modificare le impostazioni predefinite (facoltativo), utilizzare quanto segue nello stesso percorso del registro:
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 la porta predefinita 443. (Quando si crea la regola in ingresso 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 Windows Multi-session OS, riavviare la macchina per rendere effettive le modifiche. (Non è necessario riavviare le macchine contenenti VDA per Windows Single-session OS.)
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 (versione da 4.6 a 4.9), app Citrix Workspace per HTML5 e app Citrix Workspace 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 è configurato TLS 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, andare a Configurazione computer > Criteri > Modelli amministrativi > Rete > Impostazioni di configurazione SSL > Ordine suite di cifratura 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 selezionata. La modalità FIPS non impedisce l’uso di “curve25519”.
Quando questa impostazione di Criteri di gruppo è configurata, il VDA seleziona una suite di cifratura solo se appare in entrambi gli elenchi: l’elenco di Criteri di gruppo e l’elenco per la modalità di conformità selezionata (COM, GOV o ALL). La suite di cifratura deve anche apparire nell’elenco inviato dal client (app Citrix Workspace o StoreFront).
Questa configurazione di Criteri di gruppo influisce anche su altre applicazioni e servizi TLS sul VDA. Se le applicazioni richiedono suite di cifratura specifiche, potrebbe essere necessario aggiungerle a questo elenco di 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 un riavvio del sistema operativo. Pertanto, per i desktop in pool, applicare le modifiche ai Criteri di gruppo per la configurazione TLS all’immagine base.
Configurare TLS sui Delivery Group
Completare questa procedura per ciascun Delivery Group 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 ‘<nome-delivery-group>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
- Eseguire Set-BrokerSite -DnsResolutionEnabled $true.
Risoluzione dei problemi
Se si verifica un errore di connessione, verificare il registro eventi di sistema sul VDA.
Quando si utilizza l’app Citrix Workspace per Windows, se si riceve un errore di connessione che indica un errore TLS, disabilitare Desktop Viewer e quindi riprovare a connettersi. Anche se la connessione continua a non riuscire, potrebbe essere fornita una spiegazione del problema TLS sottostante. Ad esempio, è stato specificato un modello errato quando si richiedeva un certificato dall’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 dell’app Citrix Workspace, Citrix Gateway e VDA. Alcune configurazioni che utilizzano DTLS tra l’app Citrix Workspace e Citrix Gateway e che utilizzano DTLS tra Citrix Gateway e il VDA richiedono azioni aggiuntive.
È 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 VDA non supporta DTLS (versione 7.15 o precedente),
-
la versione 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 non riescano, 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 supporta 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 pertanto non è interessato.
Per disabilitare DTLS sul VDA, modificare la configurazione del firewall 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 utilizzando TLS. La configurazione WCF utilizza Kerberos per l’autenticazione reciproca tra il Controller e il 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 di 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 quei siti Web deve stabilire una connessione TLS al servizio Citrix HDX HTML5 Video Redirection in esecuzione sul VDA. Per ottenere ciò, il servizio HTML5 Video Redirection genera due certificati personalizzati nell’archivio certificati sul VDA. L’arresto del servizio rimuove i certificati.
Il criterio di reindirizzamento video HTML5 è disabilitato per impostazione predefinita.
Il reindirizzamento del contenuto del browser è abilitato per impostazione predefinita.
Per ulteriori informazioni sul reindirizzamento video HTML5, vedere Impostazioni dei criteri multimediali.