Transport Layer Security (TLS)
Citrix Virtual Apps and Desktops prend en charge le protocole TLS (Transport Layer Security) pour les connexions TCP entre composants. Citrix Virtual Apps and Desktops prend également en charge le protocole DTLS (Datagram Transport Layer Security) pour les connexions ICA/HDX basées sur UDP, en utilisant letransport 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 suivantes sont communes à TLS et DTLS sauf mention contraire :
-
Obtenez, installez et enregistrez un certificat de serveur sur tous les Delivery Controller, et configurer un port avec le certificat TLS. Pour de plus amples informations, consultez la rubrique Installer les certificats de serveur TLS sur des Controller.
Si vous le souhaitez, vous pouvez modifier les ports que le Controller utilise pour écouter le trafic HTTP et HTTPS.
-
Activez les connexions TLS entre l’application Citrix Workspace et Virtual Delivery Agents (VDA) en renseignant les tâches suivantes :
- Configurez TLS sur les machines où le VDA est installé. (Par commodité, les références supplémentaires aux machines sur lesquelles les VDA sont installés sont simplement appelées « VDA ».) Vous trouverez des informations générales dans la section 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 la section Configurer TLS sur un VDA à l’aide du script PowerShell. Toutefois, si vous souhaitez configurer TLS/DTLS manuellement, veuillez consulter la section Configurer manuellement TLS sur un VDA.
-
Configurez TSL dans les groupes de mise à disposition contenant les VDA en exécutant un jeu de cmdlets PowerShell dans Studio. Pour de plus amples informations, consultez la section Configurer TLS sur les groupes de mise à disposition.
Configuration requise 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 groupes de mise à disposition et le VDA après l’installation de composants, créez un site, créez des catalogues de machines, et créez des groupes de mise à disposition.
- Pour configurer TLS dans les groupes de mise à disposition, vous devez disposer de l’autorisation de modification des règles d’accès de Controller. Un administrateur complet possède cette autorisation.
- Pour configurer TLS sur les VDA, vous devez être un administrateur Windows sur la machine sur laquelle le VDA est installé.
- Sur les VDA regroupés qui sont provisionnés par Machine Creation Services ou Provisioning Services, l’image de la machine VDA est réinitialisée au redémarrage, entraînant 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, la modification du Registre peut entraîner de sérieux problèmes qui pourraient nécessiter la réinstallation de votre système d’exploitation. Citrix ne peut garantir la possibilité de résoudre les problèmes provenant d’une mauvaise utilisation de l’Éditeur du Registre. Vous assumez l’ensemble des risques liés à l’utilisation de l’Éditeur du Registre. Veillez à faire une copie de sauvegarde de votre registre avant de le modifier.
Pour plus d’informations sur l’activation de TLS pour la base de données du site, consultez la section CTX137556.
Installer les certificats de serveur TLS sur des Controller
Pour HTTPS, Le service XML prend en charge les fonctionnalités TLS par le biais de certificats de serveur mais pas de certificats de client. Cette section décrit l’acquisition et l’installation de certificats TLS dans des Delivery Controller. Les mêmes étapes peuvent être appliquées aux Cloud Connector pour chiffrer le trafic STA et XML.
Il existe différents types d’autorités de certification et méthodes pour demander un certificat, mais cet article décrit l’autorité de certification Microsoft. L’autorité de certification Microsoft doit disposer d’un modèle de certificat publié avec Authentification du serveur comme objectif.
Si l’autorité de certification Microsoft est intégrée à un domaine Active Directory ou à la forêt approuvée à laquelle les Delivery Controller sont joints, vous pouvez acquérir un certificat à partir de l’Assistant Inscription de certificats du composant logiciel enfichable MMC Certificats.
Demande et installation d’un certificat
- Sur le Delivery Controller, ouvrez la console MMC et ajoutez le composant logiciel enfichable Certificats. Lorsque vous y êtes invité, sélectionnez Un compte d’ordinateur.
-
Développez Personnel > Certificats, puis utilisez la commande de 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 à partir de l’inscription Active Directory.
-
Sélectionnez le modèle de certificat d’authentification du serveur. Si le modèle a été configuré pour fournir automatiquement les valeurs du sujet, vous pouvez cliquer sur Inscrire sans fournir plus de détails.
-
Pour fournir plus de détails sur le modèle de certificat, cliquez sur le bouton flèche Détails et configurez les éléments suivants :
Nom du sujet : sélectionnez Nom commun et ajoutez le nom de domaine complet du Delivery Controller.
Autre nom : sélectionnez DNS et ajoutez le nom de domaine complet du Delivery Controller.
Configuration du port de l’écouteur 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 du service 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--> -
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 service Broker 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’elle est correctement configurée, 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 du service Broker.
Si les serveurs approuvent le certificat installé sur les Delivery Controller, vous pouvez désormais configurer les Delivery Controller StoreFront et les liaisons STA 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 la configuration est nécessaire au niveau du Controller, pour modifier l’ordre des suites de chiffrement TLS. Cette modification de la configuration n’est pas nécessaire pour le Controller et StoreFront avec d’autres combinaisons de versions de Windows Server.
La liste d’ordre de la suite 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) ; ces suites de chiffrement doivent précéder toutes les suites de chiffrement TLS_DHE_.
- Dans 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 « Ordre des suites de chiffrement SSL ». Par défaut, cette stratégie est définie sur Non configuré. Définissez cette stratégie sur Activé.
- Organisez les suites dans l’ordre approprié ; supprimez 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èdent les suites de chiffrement TLS_DHE_.
Sur Microsoft MSDN, consultez également Priorité des suites de chiffrement Schannel.
Modifier les ports HTTP ou HTTPS
Par défaut, le service XML du Controller écoute le trafic HTTP sur le port 80 et le trafic HTTPS sur le port 443. Bien que vous puissiez utiliser des ports différents de ceux par défaut, n’oubliez pas les risques de sécurité relatifs à l’exposition d’un Controller à des réseaux non approuvés. Le déploiement d’un serveur StoreFront autonome est préférable à la modification des valeurs par défaut.
Pour modifier la valeur par défaut des ports HTTP ou HTTPS utilisés par le Controller, exécutez la commande suivante à partir de 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> le numéro de port pour le trafic HTTPS.
Remarque :
Après avoir modifié un port, il se peut que Studio affiche un message sur la compatibilité et la mise à niveau des licences. Pour résoudre le problème, ré-enregistrez les instances de service à l’aide de la séquence de l’applet de commande 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 sur le Controller dans HKLM\Software\Citrix\DesktopServer\ et redémarrez le service Broker.
Pour ignorer le trafic HTTP, créez un DWORD XmlServicesEnableNonSsl et définissez-le sur 0.
Il existe une valeur de registre DWORD 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 avoir un mélange d’un VDA avec TLS configuré et d’autres VDA sans TLS configuré. Avant de configurer le protocole TLS pour un groupe de mise à disposition, vous devez avoir déjà configuré TLS pour tous les VDA dans ce groupe de mise à disposition.
Lorsque vous configurez le protocole TLS sur les VDA, les autorisations sur le certificat TLS installé sont modifiées, offrant au service ICA un accès en lecture à la clé privée du certificat, et informant le service ICA des opérations suivantes :
- Quel certificat utiliser dans le magasin de certificat à 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 pour vous si vous utilisez le script PowerShell.
-
Versions du protocole TLS à autoriser.
Important :
Citrix vous recommande de vérifier leur utilisation de SSLv3 et de reconfigurer ces déploiements pour supprimer la prise en charge de SSLv3, le cas échéant. Consultez l’article CTX200238.
Les versions prises en charge du protocole TLS suivent une hiérarchie (de la plus basse à la plus élevée) : SSL 3.0, TLS 1.0, TLS 1.1 et TLS 1.2. 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, les connexions de protocole TLS 1.1 et TLS 1.2 sont autorisées. Si vous spécifiez SSL 3.0 en tant que version minimale, les connexions pour toutes les versions prises en charge sont alors autorisées. Si vous spécifiez TLS 1.2 comme version minimale, seules les connexions TLS 1.2 sont autorisées.
DTLS 1.0 correspond à TLS 1.1, et DTLS 1.2 correspond à TLS 1.2.
-
Suites de chiffrement TLS à autoriser.
Une suite de chiffrement sélectionne le cryptage qui sera utilisé pour une connexion. Les clients et les VDA peuvent prendre en charge plusieurs ensembles de suites de chiffrement. Lorsqu’un client (app Citrix Workspace ou StoreFront) se connecte et envoie une liste des suites de chiffrement TLS pris en charge, le VDA fait correspondre une des suites de chiffrement du client avec l’une de suites de chiffrement de sa liste configurée et accepte la connexion. S’il n’existe aucune correspondance de suite de chiffrement, le VDA rejette la connexion.
Le VDA prend en charge trois ensembles de suites de chiffrement (également appelés modes de conformité) : GOV (gouvernement), COM (commercial) et ALL (tout). Les suites de chiffrement acceptables dépendent du mode FIPS Windows ; voir http://support.microsoft.com/kb/811833 pour plus d’informations sur le mode FIPS Windows. Le tableau suivant répertorie les suites de chiffrement compris dans chaque ensemble :
| Suite de chiffrement TLS/DTLS | ALL | 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). Si elles sont sélectionnées par Windows, elles ne peuvent pas être utilisées par Receiver.
Si vous utilisez Citrix Gateway, reportez-vous à la documentation Citrix ADC pour plus d’informations sur la prise en charge de suite de chiffrement pour les communications back-end. Pour plus d’informations sur la prise en charge de la suite de chiffrement TLS, consultez la section Suites de chiffrement disponibles sur les appliances Citrix ADC. Pour plus d’informations sur la prise en charge de la suite de chiffrement DTLS, reportez-vous à la section Prise en charge du chiffrement DTLS.
Demande et installation d’un certificat
- Sur le VDA, ouvrez la console MMC et ajoutez le composant logiciel enfichable Certificats. Lorsque vous y êtes invité, sélectionnez Un compte d’ordinateur.
- Développez Personnel > Certificats, puis utilisez la commande de 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 à partir de l’inscription Active Directory.
-
Sélectionnez le modèle de certificat d’authentification du serveur. L’ordinateur Windows par défaut ou le serveur Web exportable sont tous deux acceptables. Si le modèle a été configuré pour fournir automatiquement les valeurs du sujet, vous pouvez cliquer sur Inscrire sans fournir plus de détails.
-
Pour fournir plus de détails sur 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 nom de domaine complet du VDA
Autre nom : sélectionnez le type DNS et ajoutez le nom de domaine complet du VDA
Remarque :
Utilisez l’inscription automatique des certificats des services de certificats Active Directory pour automatiser l’émission et le déploiement de certificats sur les VDA. Elle est décrite dans la section https://support.citrix.com/article/CTX205473.
Vous pouvez utiliser des certificats génériques pour autoriser un seul certificat à sécuriser plusieurs VDA :
Nom du sujet : sélectionnez le type Nom commun et ajoutez le *.domaine.complet des VDA
Autre nom : sélectionnez le type DNS et ajoutez le *.domaine.complet des VDA
Vous pouvez utiliser des certificats SAN pour autoriser un seul certificat à sécuriser plusieurs VDA spécifiques :
Nom du sujet : sélectionnez le type Nom commun et entrez une chaîne pour identifier l’utilisation du certificat
Autre nom : sélectionnez le type DNS et ajoutez une entrée pour le nom de domaine complet de chaque VDA. Limitez le nombre de noms alternatifs au minimum pour garantir une négociation TLS optimale.
Remarque :
Les certificats génériques et SAN nécessitent que l’option Permettre l’exportation de la clé privée de l’onglet Clé privée soit sélectionné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 résident à cet emplacement, fournissez l’empreinte numérique du certificat au script PowerShell.
Remarque :
À compter de XenApp et XenDesktop 7.16 LTSR, le script PowerShell trouve le certificat approprié en fonction du nom de domaine complet du VDA. Vous n’avez pas besoin de fournir l’empreinte si un seul certificat est présent pour le nom de domaine complet 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 le protocole TLS, le script désactive toutes les règles de pare-feu Windows existantes pour le port TCP spécifié. Ensuite, il ajoute une règle qui permet au service ICA d’accepter les connexions entrantes uniquement sur les ports TLS TCP et UDP. Cela désactive également les règles du Pare-feu Windows pour :
- Citrix ICA (valeur par défaut : 1494)
- Citrix CGP (valeur par défaut : 2598)
- Citrix WebSocket (valeur par défaut : 8008)
Les utilisateurs peuvent uniquement se connecter en utilisant TLS ou DTLS. Ils ne peuvent pas utiliser ICA/HDX, ICA/HDX avec fiabilité de session ou HDX sur WebSocket, sans TLS ou DTLS.
Remarque :
DTLS n’est pas pris en charge avec ICA/HDX Audio via UDP Real-time Transport ou avec ICA/HDX Framehawk.
Voir Ports réseau.
Le script contient des descriptions de la syntaxe suivante, ainsi que d’autres exemples ; vous pouvez utiliser un outil tel que le Bloc-notes++ pour consulter ces informations.
Important :
Spécifiez soit le paramètre Enable ou Disable de même que 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. Soit ce paramètre ou le paramètre Disable est requis. |
| Désactiver | Désactive l’écouteur TLS sur le VDA. Soit ce paramètre ou le paramètre Enable est requis. Si vous spécifiez ce paramètre, aucun autre paramètre n’est valide. |
| CertificateThumbPrint “ |
Empreinte numérique du certificat TLS dans le magasin de certificats, entourée de guillemets. Le script utilise l’empreinte numérique spécifiée pour sélectionner le certificat que vous voulez utiliser. Si ce paramètre est omis, un certificat incorrect est sélectionné. |
| SSLPort |
Port TLS. Valeur par défaut : 443 |
| SSLMinVersion “ |
Version minimale du protocole TLS, entourés de guillemets. Valeurs valides : « TLS_1.0 » (par défaut), « TLS_1.1 » et « TLS_1.2 ». |
| SSLCipherSuite “ |
Suite de chiffrement TLS, entourés de guillemets. Les valeurs valides sont : « GOV », « COM » et « ALL » (par défaut). |
Exemples
Le script suivant installe et active la version de protocole TLS. L’empreinte numérique (représentée en tant que « 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 minimale de TLS 1.2. L’empreinte numérique (représentée en tant que « 12345678987654321 » dans cet exemple) est utilisée pour sélectionner le certificat à utiliser.
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.2"
-SSLCipherSuite "All"
Le script suivant désactive l’écouteur TLS sur le VDA.
Enable-VdaSSL -Disable
Configurer manuellement TLS sur un VDA
Lors de la configuration manuelle de TLS sur un VDA, vous offrez 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 mono-session Windows, ou NT SERVICE\TermService pour un VDA pour OS multi-session Windows. Sur la machine sur laquelle le VDA est installé :
ÉTAPE 1. Lancez la console MMC (Microsoft Management Console) : Démarrer > Exécuter > mmc.exe.
ÉTAPE 2. Ajouter le composant logiciel enfichable Certificats à la console MMC :
- Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable.
- Sélectionnez Certificats et cliquez sur Ajouter.
- Lorsque vous y êtes invité par « Ce composant logiciel enfichable gérera toujours les certificats pour : », choisissez « Le compte d’ordinateur », puis cliquez sur Suivant.
- Lorsque vous y êtes invité par « Sélectionnez l’ordinateur à gérer par ce composant logiciel enfichable », choisissez « Ordinateur local », puis cliquez sur Terminer.
ÉTAPE 3. Sous Certificats (Ordinateur local) > Personnel > Certificats, cliquez avec le bouton droit de la souris 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 (NomConvivial) » où (NomConvivial) 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 mono-session Windows, « PORTICASERVICE »
- Pour un VDA pour OS multi-session Windows, « TERMSERVICE »
ÉTAPE 5. Cliquez deux fois 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 la commande regedit et rendez-vous sur HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Modifier la clé d’empreinte numérique SSL et copiez la valeur de l’empreinte numérique du certificat TLS dans cette valeur binaire. Vous pouvez ignorer sans risque les éléments inconnus dans la boîte de dialogue Modifier la valeur binaire (tels que ‘0000’ et les caractères spéciaux).
- Modifier la clé SSLEnabled et modifiez la valeur DWORD sur 1. (Pour désactiver SSL ultérieurement, changez la valeur DWORD sur 0).
-
Si vous souhaitez modifier les paramètres par défaut (facultatif), utilisez les informations suivantes dans le même chemin d’accès du Registre :
SSLPort DWORD : numéro de port SSL. Valeur par défaut : 443.
SSLMinVersion DWORD : 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Valeur par défaut : 2 (TLS 1.0).
SSLCipherSuite DWORD : 1 = GOV, 2 = COM, 3 = ALL. Valeur par défaut : 3 (ALL).
ÉTAPE 7. Assurez-vous que les ports TLS TCP et UDP sont ouverts dans le Pare-feu Windows s’il ne s’agit pas de la valeur par défaut (443). (Lors de la création de la règle de trafic entrant dans le Pare-feu Windows, assurez-vous que ses propriétés possèdent les entrées sélectionnées « Autoriser la connexion » et « Activé ».)
ÉTAPE 8. Assurez-vous qu’aucune autre application ou service (tel que IIS) utilisent le port TCP TLS.
ÉTAPE 9. Pour les VDA pour OS multi-session Windows, redémarrez la machine pour que les modifications prennent effet. (Il n’est pas nécessaire de redémarrer les machines contenant des VDA pour OS mono-session Windows).
Important :
Une étape supplémentaire est nécessaire lorsque le VDA se trouve sur un serveur Windows Server 2012 R2, Windows Server 2016 ou Windows 10 Anniversary Edition ou une version ultérieure prise en charge. Cela affecte les connexions à partir de Citrix Receiver pour Windows (version 4.6 à 4.9), l’application Citrix Workspace pour HTML5 et l’application Citrix Workspace 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 l’option « curve25519 » n’est pas sélectionnée. Le mode FIPS n’empêche pas l’utilisation de l’option « curve25519 ».
Lorsque ce paramètre de stratégie de groupe est configuré, le VDA sélectionnera une suite de chiffrement uniquement si elle apparaît dans les deux listes : la liste Stratégies de groupe et la liste pour le mode de conformité sélectionné (COM, GOV ou ALL). La suite de chiffrement doit également s’afficher 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 requièrent des suites de chiffrement spécifiques, vous devez les ajouter à la liste 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 le redémarrage du système d’exploitation. Par conséquent, pour les bureaux regroupés, appliquez les modifications de stratégie de groupe pour la configuration TLS à l’image de base.
Configurer TLS sur les groupes de mise à disposition
Effectuez cette procédure pour chaque groupe de mise à disposition qui contient les VDA vous avez configurés pour les connexions TLS.
- À partir de Studio, ouvrez la console PowerShell.
- Exécutez asnp Citrix.* pour charger les applets de commande du produit Citrix.
- Exécutez Get-BrokerAccessPolicyRule -DesktopGroupName ‘<groupe-mise-à-disposition>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
- Exécutez Set-BrokerSite -DnsResolutionEnabled $true.
Résolution des problèmes
Si une erreur de connexion se produit, consultez le journal des événements système du VDA.
Lorsque vous utilisez l’application Citrix Workspace pour Windows, si vous recevez une erreur de connexion qui indique une erreur TLS, désactivez Desktop Viewer et essayez de vous reconnecter. Bien que la connexion échoue encore, une description du problème TLS sous-jacent peut être fournie. Par exemple, vous avez spécifié un modèle incorrect lors de la demande d’un certificat à partir de l’autorité de certification.
La plupart des configurations utilisant HDX Adaptive Transport fonctionnent avec DTLS, y compris celles qui utilisent les dernières versions de application Citrix Workspace, Citrix Gateway et VDA. Certaines configurations qui utilisent DTLS entre application Citrix Workspace et Citrix Gateway et qui utilisent DTLS entre Citrix Gateway et le VDA requièrent des actions supplémentaires.
Des actions supplémentaires sont nécessaires si :
- la version 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 Citrix Gateway prend en charge DTLS sur le VDA, mais la version VDA ne prend pas en charge DTLS (version 7.15 ou antérieure),
-
la version VDA prend en charge DTLS (version 7.16 ou ultérieure), mais la version Citrix Gateway ne prend pas en charge DTLS sur le VDA.
Pour éviter l’échec des connexions de Citrix Receiver, effectuez l’une des opérations suivantes :
- mettre à jour Citrix Receiver vers Receiver pour Windows version 4.10 ou ultérieure, Receiver pour Mac 12.8 ou version ultérieure ou Receiver pour iOS version 7.5 ou ultérieure ; ou,
- mettre à jour Citrix Gateway vers une version qui prend en charge DTLS vers le VDA ; ou,
- mettre à jour le VDA vers la version 7.16 ou ultérieure ; ou,
- désactiver DTLS sur le VDA ; ou,
- désactiver 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 VDA pour désactiver le port UDP 443. Voir Ports réseau.
Communications entre le Controller et le VDA
La protection des messages de Windows Communication Framework (WCF) sécurise les communications entre le Controller et le VDA. Une protection supplémentaire au niveau du transport à l’aide de TLS n’est pas requise. La configuration WCF utilise Kerberos pour l’authentification mutuelle entre le Controller et le VDA. Le cryptage utilise AES en mode CBC avec une clé 256 bits. L’intégrité des messages est assurée par SHA-1.
Selon Microsoft, les protocoles de sécurité utilisés par WCF sont conformes aux normes OASIS (Organization for the Advancement of Structured Information Standards), y compris la stratégie WS-SecurityPolicy 1.2. En outre, Microsoft indique que WCF prend en charge tous les jeux d’algorithmes répertoriés dans la stratégie de sécurité 1.2.
Les communications entre les Controller et les VDA utilisent le jeu d’algorithmes basic256, dont les algorithmes sont indiqués ci-dessus.
Redirection vidéo TLS et HTML5 / Redirection du contenu du navigateur
Vous pouvez utiliser la redirection vidéo HTML5 et la redirection du contenu du navigateur pour rediriger les sites Web HTTPS. Le code JavaScript injecté sur ces sites Web doit établir une connexion TLS avec le service de redirection vidéo Citrix HDX HTML5 qui s’exécute 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 de ce service supprime les certificats.
La redirection vidéo HTML5 est désactivée par défaut.
La redirection du contenu du navigateur est activée par défaut.
Pour plus d’informations sur la redirection de la vidéo pour HTML5, consultez la section Paramètres de stratégie multimédia.