Sécurité de la couche de transport (TLS)
Citrix Virtual Apps and Desktops prennent en charge le protocole Transport Layer Security (TLS) pour les connexions TCP entre les composants. Citrix Virtual Apps and Desktops prennent également en charge le protocole Datagram Transport Layer Security (DTLS) pour les connexions ICA/HDX basées sur UDP, en utilisant le (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/technical-overview/hdx/adaptive-transport.html)transport adaptatif.
TLS et DTLS sont similaires et prennent en charge les mêmes certificats numériques. La configuration d’un site Citrix Virtual Apps ou Citrix Virtual Desktops™ pour utiliser TLS le configure également pour utiliser DTLS. Utilisez les procédures suivantes ; les étapes sont communes à TLS et DTLS, sauf indication contraire :
-
Obtenez, installez et enregistrez un certificat de serveur sur tous les Delivery Controllers, et configurez un port avec le certificat TLS. Pour plus de détails, consultez (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/secure/tls.html#install-tls-server-certificates-on-controllers)Installer les certificats de serveur TLS sur les Controllers.
Vous pouvez éventuellement modifier les ports que le Controller utilise pour écouter le trafic HTTP et HTTPS.
-
Activez les connexions TLS entre l’application Citrix Workspace™ et les Virtual Delivery Agents (VDA) en effectuant les tâches suivantes :
- Configurez TLS sur les machines où les VDA sont installés. (Par commodité, les références ultérieures aux machines sur lesquelles les VDA sont installés sont simplement appelées « VDA ».) Pour des informations générales, consultez (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/secure/tls.html#tls-settings-on-vdas)Paramètres TLS sur les VDA. Il est fortement recommandé d’utiliser le script PowerShell fourni par Citrix pour configurer TLS/DTLS. Pour plus de détails, consultez (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/secure/tls.html#configure-tls-on-a-vda-using-the-powershell-script)Configurer TLS sur un VDA à l’aide du script PowerShell. Toutefois, si vous souhaitez configurer TLS/DTLS manuellement, consultez (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/secure/tls.html#manually-configure-tls-on-a-vda)Configurer TLS manuellement sur un VDA.
-
Configurez TLS dans les Delivery Groups contenant les VDA en exécutant un ensemble de cmdlets PowerShell dans Studio. Pour plus de détails, consultez (/fr-fr/citrix-virtual-apps-desktops/2402-ltsr/secure/tls.html#configure-tls-on-delivery-groups)Configurer TLS sur les Delivery Groups.
Exigences et considérations :
- L’activation des connexions TLS entre les utilisateurs et les VDA est valide uniquement pour les sites XenApp 7.6 et XenDesktop 7.6, ainsi que les versions ultérieures prises en charge.
- Configurez TLS dans les Delivery Groups et sur les VDA après avoir installé les composants, créé un site, créé des catalogues de machines et créé des Delivery Groups.
- Pour configurer TLS dans les Delivery Groups, vous devez disposer des autorisations nécessaires pour modifier les règles d’accès du Controller. Un administrateur complet dispose de cette autorisation.
- Pour configurer TLS sur les VDA, vous devez être un administrateur Windows sur la machine où le VDA est installé.
- Sur les VDA en pool qui sont provisionnés par Machine Creation Services™ ou Provisioning Services, l’image de la machine VDA est réinitialisée au redémarrage, ce qui entraîne la perte des paramètres TLS précédents. Exécutez le script PowerShell chaque fois que le VDA est redémarré pour reconfigurer les paramètres TLS.
Avertissement :
Pour les tâches qui incluent l’utilisation du registre Windows, une modification incorrecte du registre peut entraîner de graves problèmes qui peuvent nécessiter la réinstallation de votre système d’exploitation. Citrix® ne peut garantir que les problèmes résultant d’une utilisation incorrecte de l’Éditeur du Registre puissent être résolus. Utilisez l’Éditeur du Registre à vos propres risques. Assurez-vous de sauvegarder le registre avant de le modifier.
Pour plus d’informations sur l’activation de TLS pour la base de données du site, consultez CTX137556.
Installer des certificats de serveur TLS sur les contrôleurs
Pour HTTPS, le service XML prend en charge les fonctionnalités TLS en utilisant des certificats de serveur, et non des certificats clients. Cette section décrit l’acquisition et l’installation de certificats TLS dans les Delivery Controllers. Les mêmes étapes peuvent être appliquées aux Cloud Connectors pour chiffrer le trafic STA et XML.
Bien qu’il existe différents types d’autorités de certification et de méthodes pour leur demander un certificat, cet article décrit l’autorité de certification Microsoft. L’autorité de certification Microsoft doit avoir un modèle de certificat publié avec un objectif d’authentification de serveur.
Si l’autorité de certification Microsoft est intégrée à un domaine Active Directory ou à la forêt approuvée à laquelle les Delivery Controllers sont joints, vous pouvez acquérir un certificat à partir de l’assistant d’inscription de certificat du composant logiciel enfichable MMC Certificats.
Demander et installer un certificat
- Sur le Delivery Controller™, ouvrez la console MMC et ajoutez le composant logiciel enfichable Certificats. Lorsque vous y êtes invité, sélectionnez Compte d’ordinateur.
-
Développez Personnel > Certificats, puis utilisez la commande du menu contextuel Toutes les tâches > Demander un nouveau certificat.
- Cliquez sur Suivant pour commencer, puis sur Suivant pour confirmer que vous acquérez le certificat à partir de l’inscription Active Directory.
-
Sélectionnez le modèle pour le certificat d’authentification de serveur. Si le modèle a été configuré pour fournir automatiquement les valeurs pour le Sujet, vous pouvez cliquer sur Inscrire sans fournir plus de détails.
-
Pour fournir plus de détails pour le modèle de certificat, cliquez sur le bouton fléché Détails et configurez les éléments suivants :
Nom du sujet : sélectionnez Nom commun et ajoutez le FQDN du Delivery Controller.
Nom alternatif : sélectionnez DNS et ajoutez le FQDN du Delivery Controller.
Configuration du port d’écoute SSL/TLS
- Ouvrez une fenêtre de commande PowerShell en tant qu’administrateur de la machine.
-
Exécutez les commandes suivantes pour obtenir le GUID de l’application Broker Service :
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--> -
Exécutez les commandes suivantes dans la même fenêtre PowerShell pour obtenir l’empreinte numérique du certificat que vous avez installé précédemment :
$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--> -
Exécutez les commandes suivantes dans la même fenêtre PowerShell pour configurer le port SSL/TLS du Broker Service et utiliser le certificat pour le chiffrement :
$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-->
Lorsqu’il est correctement configuré, la sortie de la dernière commande .netsh http show sslcert indique que l’écouteur utilise le bon IP:port, et que Application ID correspond au GUID de l’application Broker Service.
Si les serveurs font confiance au certificat installé sur les Delivery Controllers, vous pouvez maintenant configurer les Delivery Controllers StoreFront™ et les liaisons STA de Citrix Gateway pour utiliser HTTPS au lieu de HTTP.
Remarque :
Si le Controller est installé sur Windows Server 2016 et que StoreFront est installé sur Windows Server 2012 R2, une modification de configuration est nécessaire sur le Controller pour modifier l’ordre des suites de chiffrement TLS. Cette modification de configuration n’est pas nécessaire pour le Controller et StoreFront avec d’autres combinaisons de versions de Windows Server.
La liste d’ordre des suites de chiffrement doit inclure les suites de chiffrement TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ou les deux) ; et ces suites de chiffrement doivent précéder toutes les suites de chiffrement TLS_DHE_.
- À l’aide de l’Éditeur de stratégie de groupe Microsoft, accédez à Configuration ordinateur > Modèles d’administration > Réseau > Paramètres de configuration SSL.
- Modifiez la stratégie « SSL Cipher Suite Order ». Par défaut, cette stratégie est définie sur « Non configuré ». Définissez cette stratégie sur Activé.
- Organisez les suites dans le bon ordre ; supprimez toutes les suites de chiffrement que vous ne souhaitez pas utiliser.
Assurez-vous que TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 précède toute suite de chiffrement TLS_DHE_.
Sur Microsoft MSDN, consultez également Prioritizing Schannel Cipher Suites.
Modifier les ports HTTP ou HTTPS
Par défaut, le service XML sur le Controller écoute sur le port 80 pour le trafic HTTP et sur le port 443 pour le trafic HTTPS. Bien que vous puissiez utiliser des ports non par défaut, soyez conscient des risques de sécurité liés à l’exposition d’un Controller à des réseaux non fiables. Le déploiement d’un serveur StoreFront autonome est préférable à la modification des paramètres par défaut.
Pour modifier les ports HTTP ou HTTPS par défaut utilisés par le Controller, exécutez la commande suivante depuis Studio :
BrokerService.exe -WIPORT \<http-port> -WISSLPORT \<https-port>
où <http-port> est le numéro de port pour le trafic HTTP et <https-port> est le numéro de port pour le trafic HTTPS.
Remarque :
Après avoir modifié un port, Studio peut afficher un message concernant la compatibilité des licences et la mise à niveau. Pour résoudre le problème, réenregistrez les instances de service à l’aide de la séquence de cmdlets PowerShell suivante :
Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->
Appliquer le trafic HTTPS uniquement
Si vous souhaitez que le service XML ignore le trafic HTTP, créez le paramètre de registre suivant dans HKLM\Software\Citrix\DesktopServer\ sur le Controller, puis redémarrez le service Broker.
Pour ignorer le trafic HTTP, créez la valeur DWORD XmlServicesEnableNonSsl et définissez-la sur 0.
Il existe une valeur DWORD de registre correspondante que vous pouvez créer pour ignorer le trafic HTTPS : DWORD XmlServicesEnableSsl. Assurez-vous qu’elle n’est pas définie sur 0.
Paramètres TLS sur les VDA
Un groupe de mise à disposition ne peut pas contenir un mélange de VDA avec TLS configuré et de VDA sans TLS configuré. Avant de configurer TLS pour un groupe de mise à disposition, assurez-vous d’avoir déjà configuré TLS pour tous les VDA de ce groupe de mise à disposition.
Lorsque vous configurez TLS sur les VDA, les autorisations sur le certificat TLS installé sont modifiées, donnant au service ICA® un accès en lecture à la clé privée du certificat, et informant le service ICA des éléments suivants :
- Quel certificat dans le magasin de certificats utiliser pour TLS.
-
Quel numéro de port TCP utiliser pour les connexions TLS.
Le pare-feu Windows (s’il est activé) doit être configuré pour autoriser les connexions entrantes sur ce port TCP. Cette configuration est effectuée automatiquement lorsque vous utilisez le script PowerShell.
-
Quelles versions du protocole TLS autoriser.
Important :
Citrix vous recommande de revoir votre utilisation de SSLv3 et de reconfigurer ces déploiements pour supprimer la prise en charge de SSLv3 le cas échéant. Voir CTX200238.
Les versions de protocole TLS prises en charge suivent une hiérarchie (de la plus basse à la plus élevée) : SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3. Spécifiez la version minimale autorisée ; toutes les connexions de protocole utilisant cette version ou une version supérieure sont autorisées.
Par exemple, si vous spécifiez TLS 1.1 comme version minimale, alors les connexions de protocole TLS 1.1 et TLS 1.3 sont autorisées. Si vous spécifiez SSL 3.0 comme version minimale, alors les connexions pour toutes les versions prises en charge sont autorisées. Si vous spécifiez TLS 1.3 comme version minimale, seules les connexions TLS 1.3 sont autorisées.
DTLS 1.0 correspond à TLS 1.1, et DTLS 1.3 correspond à TLS 1.3.
-
Quelles suites de chiffrement TLS autoriser.
Une suite de chiffrement sélectionne le chiffrement utilisé pour une connexion. Les clients et les VDA peuvent prendre en charge différents ensembles de suites de chiffrement. Lorsqu’un client (application Citrix Workspace ou StoreFront) se connecte et envoie une liste de suites de chiffrement TLS prises en charge, le VDA fait correspondre l’une des suites de chiffrement du client avec l’une des suites de chiffrement de sa propre liste de suites de chiffrement configurées, et accepte la connexion. S’il n’y a pas de suite de chiffrement correspondante, le VDA rejette la connexion.
Le VDA prend en charge trois ensembles de suites de chiffrement (également appelés modes de conformité) : GOV(ernment), COM(mercial) et ALL. Les suites de chiffrement acceptables dépendent également du mode FIPS de Windows ; voir http://support.microsoft.com/kb/811833 pour plus d’informations sur le mode FIPS de Windows. Le tableau suivant répertorie les suites de chiffrement de chaque ensemble :
| Suite de chiffrement TLS/DTLS | TOUS | COM | GOV | ALL | COM | GOV |
|---|---|---|---|---|---|---|
| Mode FIPS | Désactivé | Désactivé | Désactivé | Activé | Activé | Activé |
| 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 pris en charge dans Windows Server 2012 R2.
Remarque :
Le VDA ne prend pas en charge les suites de chiffrement DHE (par exemple, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 et TLS_DHE_RSA_WITH_AES_128_CBC_SHA). S’ils sont sélectionnés par Windows, ils peuvent ne pas être utilisés par Receiver.
Si vous utilisez un Citrix Gateway, reportez-vous à la documentation Citrix ADC pour plus d’informations sur la prise en charge des suites de chiffrement pour la communication back-end. Pour plus d’informations sur la prise en charge des suites de chiffrement TLS, consultez Chiffrements disponibles sur les appliances Citrix ADC. Pour plus d’informations sur la prise en charge des suites de chiffrement DTLS, consultez Prise en charge des chiffrements DTLS.
Demander et installer un certificat
- Sur le VDA, ouvrez la console MMC et ajoutez le composant logiciel enfichable Certificats. Lorsque vous y êtes invité, sélectionnez Compte d’ordinateur.
- Développez Personnel > Certificats, puis utilisez la commande du menu contextuel Toutes les tâches > Demander un nouveau certificat.
- Cliquez sur Suivant pour commencer, puis sur Suivant pour confirmer que vous obtenez le certificat via l’inscription Active Directory.
-
Sélectionnez le modèle de certificat d’authentification de serveur. Les modèles Windows par défaut Ordinateur ou Serveur Web exportable sont tous deux acceptables. Si le modèle a été configuré pour fournir automatiquement les valeurs pour le Sujet, vous pouvez cliquer sur Inscrire sans fournir plus de détails.
-
Pour fournir plus de détails pour le modèle de certificat, cliquez sur Détails et configurez les éléments suivants :
Nom du sujet — sélectionnez le type Nom commun et ajoutez le FQDN du VDA
Nom alternatif — sélectionnez le type DNS et ajoutez le FQDN du VDA
Remarque :
Utilisez l’inscription automatique de certificats des services de certificats Active Directory pour automatiser l’émission et le déploiement de certificats sur les VDA. Ceci est décrit dans https://support.citrix.com/article/CTX205473.
Vous pouvez utiliser des certificats génériques pour permettre à un seul certificat de sécuriser plusieurs VDA :
Nom du sujet — sélectionnez le type Nom commun et entrez le *.primary.domain des VDA
Nom alternatif — sélectionnez le type DNS et ajoutez le *.domaine.principal des VDA
Vous pouvez utiliser des certificats SAN pour permettre à un seul certificat de sécuriser plusieurs VDA spécifiques :
Nom du sujet — sélectionnez le type Nom commun et entrez une chaîne pour aider à identifier l’utilisation du certificat
Nom alternatif — sélectionnez le type DNS et ajoutez une entrée pour le FQDN de chaque VDA. Réduisez au minimum le nombre de noms alternatifs pour garantir une négociation TLS optimale.
Remarque :
Les certificats génériques et SAN nécessitent que Rendre la clé privée exportable soit sélectionné dans l’onglet Clé privée :
Configurer TLS sur un VDA à l’aide du script PowerShell
Installez le certificat TLS dans la zone Ordinateur local > Personnel > Certificats du magasin de certificats. Si plusieurs certificats se trouvent à cet emplacement, fournissez l’empreinte numérique du certificat au script PowerShell.
Remarque :
À partir de XenApp et XenDesktop 7.16 LTSR, le script PowerShell trouve le certificat correct en fonction du FQDN du VDA. Vous n’avez pas besoin de fournir l’empreinte numérique lorsqu’un seul certificat est présent pour le FQDN du VDA.
Le script Enable-VdaSSL.ps1 active ou désactive l’écouteur TLS sur un VDA. Ce script est disponible dans le dossier Support > Tools > SslSupport sur le support d’installation.
Lorsque vous activez TLS, les suites de chiffrement DHE sont désactivées. Les suites de chiffrement ECDHE ne sont pas affectées.
Lorsque vous activez TLS, le script désactive toutes les règles de pare-feu Windows existantes pour le port TCP spécifié. Il ajoute ensuite une nouvelle règle qui permet au service ICA d’accepter les connexions entrantes uniquement sur les ports TCP et UDP TLS. Il désactive également les règles de pare-feu Windows pour :
- Citrix ICA (par défaut : 1494)
- Citrix CGP (par défaut : 2598)
- Citrix WebSocket (par défaut : 8008)
L’effet est que les utilisateurs ne peuvent se connecter qu’en utilisant TLS ou DTLS. Ils ne peuvent pas utiliser ICA/HDX, ICA/HDX avec la fiabilité de session, ou HDX sur WebSocket, sans TLS ou DTLS.
Remarque :
DTLS n’est pas pris en charge avec ICA/HDX Audio sur transport en temps réel UDP, ou avec ICA/HDX Framehawk.
Voir Ports réseau.
Le script contient les descriptions de syntaxe suivantes, ainsi que des exemples supplémentaires ; vous pouvez utiliser un outil tel que Notepad++ pour consulter ces informations.
Important :
Spécifiez le paramètre Enable ou Disable, et le paramètre CertificateThumbPrint. Les autres paramètres sont facultatifs.
Syntaxe
Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]
| Paramètre | Description |
|---|---|
| Activer | Installe et active l’écouteur TLS sur le VDA. Ce paramètre ou le paramètre Désactiver est requis. |
| Désactiver | Désactive l’écouteur TLS sur le VDA. Ce paramètre ou le paramètre Activer est requis. Si vous spécifiez ce paramètre, aucun autre paramètre n’est valide. |
| EmpreinteCertificat “ |
Empreinte numérique du certificat TLS dans le magasin de certificats, entre guillemets. Le script utilise l’empreinte numérique spécifiée pour sélectionner le certificat que vous souhaitez utiliser. Si ce paramètre est omis, un certificat incorrect est sélectionné. |
| PortSSL |
Port TLS. Par défaut : 443 |
| VersionMinimaleSSL “ |
Version minimale du protocole TLS, entre guillemets. Valeurs valides : « TLS_1.0 » (par défaut), « TLS_1.1 » et « TLS_1.3 ». |
| SuiteDeChiffrementSSL “ |
Suite de chiffrement TLS, entre guillemets. Valeurs valides : « GOV », « COM » et « ALL » (par défaut). |
Exemples
Le script suivant installe et active la valeur de version du protocole TLS. L’empreinte numérique (représentée par « 12345678987654321 » dans cet exemple) est utilisée pour sélectionner le certificat à utiliser.
Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
Le script suivant installe et active l’écouteur TLS, et spécifie le port TLS 400, la suite de chiffrement GOV et une valeur de protocole TLS 1.2 minimale. L’empreinte numérique (représentée par « 12345678987654321 » dans cet exemple) est utilisée pour sélectionner le certificat à utiliser.
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.3"
-SSLCipherSuite "All"
Le script suivant désactive l’écouteur TLS sur le VDA.
Enable-VdaSSL -Disable
Configurer manuellement TLS sur un VDA
Lorsque vous configurez TLS sur un VDA manuellement, vous accordez un accès en lecture générique à la clé privée du certificat TLS pour le service approprié sur chaque VDA : NT SERVICE\PorticaService pour un VDA pour OS Windows à session unique, ou NT SERVICE\TermService pour un VDA pour OS Windows multi-session. Sur la machine où le VDA est installé :
ÉTAPE 1. Lancez la console de gestion Microsoft (MMC) : Démarrer > Exécuter > mmc.exe.
ÉTAPE 2. Ajoutez le composant logiciel enfichable Certificats à la MMC :
- Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable.
- Sélectionnez Certificats, puis cliquez sur Ajouter.
- Lorsque vous êtes invité à « Ce composant logiciel enfichable gérera toujours les certificats pour : », choisissez « Compte d’ordinateur », puis cliquez sur Suivant.
- Lorsque vous êtes invité à « Sélectionner l’ordinateur que vous souhaitez que ce composant logiciel enfichable gère », choisissez « Ordinateur local », puis cliquez sur Terminer.
ÉTAPE 3. Sous Certificats (ordinateur local) > Personnel > Certificats, cliquez avec le bouton droit sur le certificat, puis sélectionnez Toutes les tâches > Gérer les clés privées.
ÉTAPE 4. L’éditeur de liste de contrôle d’accès affiche « Autorisations pour les clés privées (Nom convivial) » où (Nom convivial) est le nom de votre certificat TLS. Ajoutez l’un des services suivants et accordez-lui un accès en lecture :
- Pour un VDA pour OS Windows à session unique, « PORTICASERVICE »
- Pour un VDA pour OS Windows multi-session, « TERMSERVICE »
ÉTAPE 5. Double-cliquez sur le certificat TLS installé. Dans la boîte de dialogue du certificat, sélectionnez l’onglet Détails, puis faites défiler vers le bas. Cliquez sur Empreinte numérique.
ÉTAPE 6. Exécutez regedit et accédez à HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Modifiez la clé SSL Thumbprint et copiez la valeur de l’empreinte numérique du certificat TLS dans cette valeur binaire. Vous pouvez ignorer en toute sécurité les éléments inconnus dans la boîte de dialogue Modifier la valeur binaire (tels que ‘0000’ et les caractères spéciaux).
- Modifiez la clé SSLEnabled et remplacez la valeur DWORD par 1. (Pour désactiver SSL ultérieurement, remplacez la valeur DWORD par 0.)
-
Si vous souhaitez modifier les paramètres par défaut (facultatif), utilisez les éléments suivants dans le même chemin de registre :
SSLPort DWORD – Numéro de port SSL. Par défaut : 443.
SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.3. Par défaut : 2 (TLS 1.0).
SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Par défaut : 3 (ALL).
ÉTAPE 7. Assurez-vous que les ports TCP et UDP TLS sont ouverts dans le Pare-feu Windows s’ils ne sont pas le port 443 par défaut. (Lorsque vous créez la règle de trafic entrant dans le Pare-feu Windows, assurez-vous que ses propriétés ont les entrées « Autoriser la connexion » et « Activé » sélectionnées.)
ÉTAPE 8. Assurez-vous qu’aucune autre application ou service (tel qu’IIS) n’utilise le port TCP TLS.
ÉTAPE 9. Pour les VDA pour OS Windows multi-session, redémarrez la machine pour que les modifications prennent effet. (Vous n’avez pas besoin de redémarrer les machines contenant des VDA pour OS Windows mono-session.)
Important :
Une étape supplémentaire est nécessaire lorsque le VDA est sur Windows Server 2012 R2, Windows Server 2016, ou Windows 10 Anniversary Edition ou une version ultérieure prise en charge. Cela affecte les connexions depuis Citrix Receiver pour Windows (version 4.6 à 4.9), Citrix Workspace app pour HTML5 et Citrix Workspace app pour Chrome. Cela inclut également les connexions utilisant Citrix Gateway.
Cette étape est également requise pour toutes les connexions utilisant Citrix Gateway, pour toutes les versions de VDA, si TLS est configuré entre Citrix Gateway et le VDA. Cela affecte toutes les versions de Citrix Receiver™.
Sur le VDA (Windows Server 2012 R2, Windows Server 2016, ou Windows 10 Anniversary Edition ou version ultérieure), à l’aide de l’Éditeur de stratégie de groupe, accédez à Configuration ordinateur > Stratégies > Modèles d’administration > Réseau > Paramètres de configuration SSL > Ordre des suites de chiffrement SSL. Sélectionnez l’ordre suivant :
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
Remarque :
Les six premiers éléments spécifient également la courbe elliptique, P384 ou P256. Assurez-vous que « curve25519 » n’est pas sélectionné. Le mode FIPS n’empêche pas l’utilisation de « curve25519 ».
Lorsque ce paramètre de stratégie de groupe est configuré, le VDA sélectionne une suite de chiffrement uniquement si elle apparaît dans les deux listes : la liste de la stratégie de groupe et la liste du mode de conformité sélectionné (COM, GOV ou ALL). La suite de chiffrement doit également apparaître dans la liste envoyée par le client (application Citrix Workspace ou StoreFront).
Cette configuration de stratégie de groupe affecte également d’autres applications et services TLS sur le VDA. Si vos applications nécessitent des suites de chiffrement spécifiques, vous devrez peut-être les ajouter à cette liste de stratégie de groupe.
Important :
Même si les modifications de stratégie de groupe sont affichées lorsqu’elles sont appliquées, les modifications de stratégie de groupe pour la configuration TLS ne prennent effet qu’après un redémarrage du système d’exploitation. Par conséquent, pour les bureaux en pool, appliquez les modifications de stratégie de groupe pour la configuration TLS à l’image de base.
Configurer TLS sur les groupes de mise à disposition
Suivez cette procédure pour chaque groupe de mise à disposition contenant des VDA que vous avez configurés pour les connexions TLS.
- Depuis Studio, ouvrez la console PowerShell.
- Exécutez asnp Citrix.* pour charger les cmdlets du produit Citrix.
- Exécutez Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
- Exécutez Set-BrokerSite -DnsResolutionEnabled $true.
Dépannage
Si une erreur de connexion se produit, vérifiez le journal des événements système sur le VDA.
Lorsque vous utilisez l’application Citrix Workspace pour Windows, si vous recevez une erreur de connexion indiquant une erreur TLS, désactivez Desktop Viewer, puis essayez de vous connecter à nouveau. Bien que la connexion échoue toujours, une explication du problème TLS sous-jacent pourrait être fournie. Par exemple, vous avez spécifiez un modèle incorrect lors de la demande d’un certificat auprès de l’autorité de certification.)
La plupart des configurations utilisant HDX™ Adaptive Transport fonctionnent avec succès avec DTLS, y compris celles utilisant les dernières versions de l’application Citrix Workspace, de Citrix Gateway et du VDA. Certaines configurations qui utilisent DTLS entre l’application Citrix Workspace et Citrix Gateway, et qui utilisent DTLS entre Citrix Gateway et le VDA, nécessitent une action supplémentaire.
Une action supplémentaire est nécessaire si :
- la version de Citrix Receiver prend en charge HDX Adaptive Transport et DTLS : Receiver pour Windows (4.7, 4.8, 4.9), Receiver pour Mac (12.5, 12.6, 12.7), Receiver pour iOS (7.2, 7.3.x) ou Receiver pour Linux (13.7)
et l’une des conditions suivantes s’applique également :
-
la version de Citrix Gateway prend en charge DTLS vers le VDA, mais la version du VDA ne prend pas en charge DTLS (version 7.15 ou antérieure),
-
la version du VDA prend en charge DTLS (version 7.16 ou ultérieure), mais la version de Citrix Gateway ne prend pas en charge DTLS vers le VDA.
Pour éviter que les connexions depuis Citrix Receiver n’échouent, effectuez l’une des opérations suivantes :
- mettez à jour Citrix Receiver vers Receiver pour Windows version 4.10 ou ultérieure, Receiver pour Mac 12.8 ou ultérieure, ou Receiver pour iOS version 7.5 ou ultérieure ; ou,
- mettez à jour Citrix Gateway vers une version qui prend en charge DTLS vers le VDA ; ou,
- mettez à jour le VDA vers la version 7.16 ou ultérieure ; ou,
- désactivez DTLS sur le VDA ; ou,
- désactivez HDX Adaptive Transport.
Remarque :
Une mise à jour appropriée pour Receiver pour Linux n’est pas encore disponible. Receiver pour Android (version 3.12.3) ne prend pas en charge HDX Adaptive Transport et DTLS via Citrix Gateway, et n’est donc pas affecté.
Pour désactiver DTLS sur le VDA, modifiez la configuration du pare-feu du VDA pour désactiver le port UDP 443. Consultez Ports réseau.
Communication entre le Controller et le VDA
La protection au niveau des messages de Windows Communication Framework (WCF) sécurise la communication entre le Controller et le VDA. Une protection supplémentaire au niveau du transport utilisant TLS n’est pas requise. La configuration WCF utilise Kerberos pour l’authentification mutuelle entre le Controller et le VDA. Le chiffrement utilise AES en mode CBC avec une clé de 256 bits. L’intégrité des messages utilise SHA-1.
Selon Microsoft, les protocoles de sécurité utilisés par WCF sont conformes aux normes d’OASIS (Organization for the Advancement of Structured Information Standards), y compris WS-SecurityPolicy 1.2. De plus, Microsoft déclare que WCF prend en charge toutes les suites d’algorithmes répertoriées dans Security Policy 1.2.
La communication entre le Controller et le VDA utilise la suite d’algorithmes basic256, dont les algorithmes sont ceux mentionnés ci-dessus.
Redirection vidéo TLS et HTML5, et redirection de contenu de navigateur
Vous pouvez utiliser la redirection vidéo HTML5 et la redirection de contenu de navigateur pour rediriger les sites web HTTPS. Le JavaScript injecté dans ces sites web doit établir une connexion TLS avec le service de redirection vidéo HTML5 Citrix HDX exécuté sur le VDA. Pour ce faire, le service de redirection vidéo HTML5 génère deux certificats personnalisés dans le magasin de certificats sur le VDA. L’arrêt du service supprime les certificats.
La stratégie de redirection vidéo HTML5 est désactivée par défaut.
La redirection de contenu de navigateur est activée par défaut.
Pour plus d’informations sur la redirection vidéo HTML5, consultez Paramètres de stratégie multimédia.