Transport Layer Security (TLS)
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à, ulteriori riferimenti alle macchine in cui sono installati i VDA sono semplicemente chiamati “VDA”.) Per informazioni generali, vedere Impostazioni TLS sui VDA. Si raccomanda 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 forniti da Machine Creation Services™ o Provisioning Services, l’immagine della macchina VDA viene ripristinata al riavvio, causando la perdita delle precedenti impostazioni TLS. Eseguire lo script PowerShell ogni volta che il VDA viene riavviato per riconfigurare le impostazioni TLS.
Avviso:
Per le attività che includono la modifica del registro di Windows, una 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 come acquisire e installare i 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 maggiori dettagli per il modello di certificato, fare clic sulla 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
- Aprire una finestra dei comandi PowerShell come amministratore della macchina.
-
Eseguire i seguenti comandi per ottenere il GUID dell’applicazione del servizio Broker:
New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT $Service_Guid = Get-ChildItem HKCR:\Installer\Products -Recurse -Ea 0 | Where-Object { $key = $_; $_.GetValueNames() | ForEach-Object { $key.GetValue($_) } | Where-Object { $_ -like 'Citrix Broker Service' } } | Select-Object Name $Service_Guid.Name -match "[A-Z0-9]*$" $Guid = $Matches[0] [GUID]$Formatted_Guid = $Guid Remove-PSDrive -Name HKCR Write-Host "Broker Service Application GUID: $($Formatted_Guid)" -ForegroundColor Yellow <!--NeedCopy--> -
Eseguire i seguenti comandi nella stessa finestra PowerShell per ottenere l’identificazione personale (Thumbprint) del certificato installato in precedenza:
$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--> -
Eseguire i seguenti comandi nella stessa finestra PowerShell per configurare la porta SSL/TLS del servizio Broker e utilizzare il certificato per la crittografia:
$IPV4_Address = Test-Connection -ComputerName $HostName -Count 1 | Select-Object -ExpandProperty IPV4Address $IPPort = "$($IPV4_Address):443" $SSLxml = "http add sslcert ipport=$IPPort certhash=$Thumbprint appid={$Formatted_Guid}" $SSLxml | netsh . netsh http show sslcert <!--NeedCopy-->
Se configurato correttamente, l’output dell’ultimo comando .netsh http show sslcert mostra che il listener sta utilizzando l’indirizzo IP:porta corretto e che l’ID applicazione corrisponde al GUID dell’applicazione del servizio Broker.
Supponendo che i server si fidino del certificato installato sui Delivery Controller, è ora possibile configurare i Delivery Controller di StoreFront™ e i binding STA di Citrix Gateway per utilizzare HTTPS anziché HTTP.
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, essere consapevoli dei rischi per la sicurezza di esporre 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 \<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-->
Impostare solo il 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 raccomanda 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, TLS 1.2 e TLS 1.3. 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.3. Se si specifica SSL 3.0 come versione minima, sono consentite le connessioni per tutte le versioni supportate. Se si specifica TLS 1.3 come versione minima, sono consentite solo le connessioni TLS 1.3.
DTLS 1.0 corrisponde a TLS 1.1 e DTLS 1.3 corrisponde a TLS 1.3.
-
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 seguente tabella 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 Ciphers available on the Citrix ADC appliances. Per informazioni sul supporto delle suite di cifratura DTLS, vedere DTLS cipher support.
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 modello predefinito di Windows Computer che Web Server Exportable. Se il modello è stato impostato per fornire automaticamente i valori per l’Oggetto, è possibile fare clic su Registra senza fornire ulteriori dettagli.
-
Per fornire maggiori 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 *.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 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 ogni 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 la chiave privata esportabile 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 più di un certificato risiede in quella posizione, 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 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, più 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.3”. |
| SSLCipherSuite “ |
Suite di cifratura TLS, racchiusa tra virgolette. Valori validi: “GOV”, “COM” e “ALL” (predefinito). |
Esempi
Il seguente script 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"
Il seguente script 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.3"
-SSLCipherSuite "All"
Il seguente script disabilita il listener TLS sul VDA.
Enable-VdaSSL -Disable
Configurare manualmente TLS su un VDA
Quando si configura TLS su un VDA manualmente, si concede l’accesso in lettura generico 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:
PASSO 1. Avviare la console di gestione Microsoft (MMC): Start > Esegui > mmc.exe.
PASSO 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.
PASSO 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.
PASSO 4. L’Editor dell’elenco di controllo degli accessi 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”
PASSO 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 (Thumbprint).
PASSO 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 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:
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.3. Predefinito: 2 (TLS 1.0).
SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Predefinito: 3 (ALL).
PASSO 7. Assicurarsi che le porte TCP e UDP TLS siano aperte nel firewall di Windows se non sono le predefinite 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.)
PASSO 8. Assicurarsi che nessun’altra applicazione o servizio (come IIS) stia utilizzando la porta TCP TLS.
PASSO 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 supportata successiva. Ciò influisce sulle connessioni da Citrix Receiver per Windows (versione 4.6 a 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 tra Citrix Gateway e il VDA è configurato. Ciò influisce su tutte le versioni di Citrix Receiver™.
Sul VDA (Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o successivo), 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 selezionato. La modalità FIPS non impedisce l’uso di “curve25519”.
Quando questa impostazione dei Criteri di gruppo è configurata, il VDA seleziona una suite di cifratura solo se appare in entrambi gli elenchi: l’elenco dei 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 dei 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 dei Criteri di gruppo.
Importante:
Anche se le modifiche ai Criteri di gruppo vengono mostrate 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 di base.
Configurare TLS sui Delivery Group
Completare questa procedura per ogni 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, controllare 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 provare a connettersi di nuovo. Sebbene la connessione fallisca comunque, potrebbe essere fornita una spiegazione del problema TLS sottostante. Ad esempio, è stato specificato un modello errato quando si è richiesto 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 ultime versioni di Citrix Workspace app, Citrix Gateway e il VDA. Alcune configurazioni che utilizzano DTLS tra Citrix Workspace app e Citrix Gateway, e che utilizzano DTLS tra Citrix Gateway e il 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 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 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 è necessaria 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 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 come sopra indicato.
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 ottenere ciò, 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.