Citrix Virtual Apps and Desktops 7 2203 LTSR

Transport Layer Security (TLS)

May 31, 2026

Contributeur:

C C

Citrix Virtual Apps and Desktops prend en charge le protocole TLS (Transport Layer Security) pour les connexions TCP entre les 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 le (/fr-fr/citrix-virtual-apps-desktops/2203-ltsr/technical-overview/hdx/adaptive-transport.html).

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. Suivez les procédures ci-dessous ; 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/2203-ltsr/secure/tls.html#install-tls-server-certificates-on-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/2203-ltsr/secure/tls.html#tls-settings-on-vdas). 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/2203-ltsr/secure/tls.html#configure-tls-on-a-vda-using-the-powershell-script). Toutefois, si vous souhaitez configurer TLS/DTLS manuellement, consultez (/fr-fr/citrix-virtual-apps-desktops/2203-ltsr/secure/tls.html#manually-configure-tls-on-a-vda).
- Configurez TLS dans les groupes de mise à disposition 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/2203-ltsr/secure/tls.html#configure-tls-on-delivery-groups).
  
  Exigences et considérations :
  - L’activation des connexions TLS entre les utilisateurs et les VDA n’est valide que 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 sur les VDA après avoir installé les composants, créé un site, créé des catalogues de machines et créé des groupes de mise à disposition.
  - Pour configurer TLS dans les groupes de mise à disposition, 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 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 impliquent de travailler dans le registre Windows, une modification incorrecte du registre peut entraîner de graves problèmes qui pourraient 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 pourront ê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 vers la base de données du site, consultez CTX137556.

Installer les 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 des certificats, 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 Certificats de la console MMC.

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 de 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 de certificat d’authentification de serveur. Si le modèle a été configuré pour fournir automatiquement les valeurs pour 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

Si le composant IIS Windows est installé sur le même serveur, ce qui est le cas lors de l’installation de Web Studio et Director, vous pouvez configurer TLS à l’aide d’IIS. Pour plus d’informations, consultez Activer TLS sur Web Studio et Director. Sinon, pour configurer le certificat à l’aide de PowerShell :

Pour vérifier s’il existe une liaison de certificat, ouvrez une invite de commandes et exécutez netsh http show sslcert :
```
netsh http show sslcert

```
S’il existe une liaison, supprimez-la.
```
netsh http delete sslcert ipport=0.0.0.0:443

```
Remplacez 0.0.0.0:443 par une adresse IP et un port spécifiques s’ils étaient spécifiés dans la liaison existante.
Recherchez l’empreinte numérique du certificat que vous avez installé précédemment. Pour afficher l’empreinte numérique, ouvrez Gérer les certificats de l’ordinateur, accédez au certificat, ouvrez-le et accédez à l’onglet Détails.

Vous pouvez également utiliser PowerShell. Par exemple, le script suivant recherche un certificat dont le nom commun correspond au nom d’hôte du serveur et affiche l’empreinte numérique :
```
$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

```
Si le nom commun du certificat ne correspond pas aux noms d’hôte, cela échouera. S’il existe plusieurs certificats pour le nom d’hôte, cela renvoie plusieurs empreintes numériques concaténées et vous devez choisir l’empreinte numérique appropriée.

L’exemple suivant recherche un certificat par nom convivial :
```
$friendlyName = "My certificate name"
$Thumbprint = (Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.FriendlyName -eq $friendlyNam}).Thumbprint -join ';'
Write-Host -Object "Certificate Thumbprint for $friendlyName: $($Thumbprint)" -Foreground Yellow

```
S’il existe plusieurs certificats avec le nom convivial spécifié, cela renvoie plusieurs empreintes numériques concaténées et vous devez choisir l’empreinte numérique appropriée.
Pour lier le certificat au port, utilisez la commande netsh http add sslcert :
```
netsh http add sslcert ipport=[IP address]:443 certhash=[certificate hash] appid=[application GUID] disablelegacytls=enable

```
- ipport : L’adresse IP et le port. L’utilisation de 0.0.0.0:443 applique cela à toutes les adresses IP. Vous pouvez également spécifier une adresse IP spécifique.
- certhash : L’empreinte numérique du certificat que vous avez identifié à l’étape précédente.
- appid : Le GUID du service Citrix Broker.
  
  Remarque :
  
  Lors du renouvellement d’un certificat ou d’une nouvelle liaison, utilisez le appid spécifique associé au service Broker plutôt qu’un GUID arbitraire.
  
  Pour trouver le appid correct pour le service Citrix Broker :
  1. Ouvrez une fenêtre de commande PowerShell en tant qu’administrateur et exécutez la commande suivante :
    Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" 
  2. Localisez le IdentifyingNumber (GUID) du service Citrix Broker dans la sortie (par exemple, {D333C884-187F-447C-8C67-463F33989C8F}). Utilisez ce GUID pour le paramètre appid.
- disablelegacytls=enable : Désactive les versions héritées de TLS. Ce paramètre est disponible sur Windows 2022 et versions ultérieures. Sur Windows 2022, il désactive TLS 1.0 et 1.1. Sur Windows 2025, cela est inutile car TLS 1.0 et 1.1 sont désactivés par défaut.
Par exemple, exécutez la commande suivante pour lier le certificat avec l’empreinte numérique bc96f958848639fd101a793b87915d5f2829b0b6 au port 443 sur toutes les adresses IP :
```
netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable

```

Une fois HTTPS activé, vous devez configurer tous les déploiements StoreFront et les Netscaler Gateways pour qu’ils utilisent HTTPS au lieu de HTTP pour se connecter au contrôleur de livraison.

Remarque :

Si le contrôleur 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 contrôleur pour changer l’ordre des suites de chiffrement TLS. Cette modification de configuration n’est pas nécessaire pour le contrôleur 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 « 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 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, voir également Priorisation des suites de chiffrement Schannel.

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-->

Forcer uniquement le trafic HTTPS

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 configurés avec TLS et de VDA non configurés avec TLS. 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 des VDA, les autorisations sur le certificat TLS installé sont modifiées, accordant 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. Consultez 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 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, alors les connexions de protocole TLS 1.1 et TLS 1.2 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.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.
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 ; consultez 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	TOUS	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 peuvent ne pas être utilisées 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 (/fr-fr/citrix-adc/13/ssl/ciphers-available-on-the-citrix-adc-appliances). Pour plus d’informations sur la prise en charge des suites de chiffrement DTLS, consultez (/fr-fr/citrix-adc/13/ssl/support-for-dtls-protocol.html#dtls-cipher-support).

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 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 de l’objet, 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 de l’objet — sélectionnez le type Nom commun et ajoutez le FQDN du VDA

Autre nom — 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 saisissez le *.domaine.principal 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 saisissez 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 UDP en temps réel, ou avec ICA/HDX Framehawk.

Consultez 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.
Empreinte du certificat “"	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 à utiliser. Si ce paramètre est omis, un certificat incorrect est sélectionné.
Port SSL	Port TLS. Par défaut : 443
Version minimale SSL “"	Version minimale du protocole TLS, entre guillemets. Valeurs valides : « TLS_1.0 » (par défaut), « TLS_1.1 » et « TLS_1.2 ».
Suite de chiffrement SSL “"	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.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 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 mono-session Windows, ou NT SERVICE\TermService pour un VDA pour OS multi-session Windows. 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 l’invite « Ce composant logiciel enfichable gérera toujours les certificats pour : » s’affiche, choisissez « Compte d’ordinateur », puis cliquez sur Suivant.
Lorsque l’invite « Sélectionnez l’ordinateur que vous souhaitez que ce composant logiciel enfichable gère » s’affiche, 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 donnez-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. 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.2. Par défaut : 2 (TLS 1.0).

SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Par défaut : 3 (TOUS).

ÉTAPE 7. Assurez-vous que les ports TCP et UDP TLS sont ouverts dans le Pare-feu Windows s’ils ne sont pas les ports par défaut 443. (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 (versions 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 « 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 (Citrix Workspace app 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 de 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 Citrix Workspace app 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 peut être fournie. Par exemple, vous avez spécifié un modèle incorrect lors de la demande d’un certificat auprès de l’autorité de certification.)

La plupart des configurations qui utilisent HDX™ Adaptive Transport fonctionnent avec DTLS, y compris celles utilisant les dernières versions de Citrix Workspace app, Citrix Gateway et le VDA. Certaines configurations qui utilisent DTLS entre Citrix Workspace app 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 que 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 la version 4.10 ou ultérieure de Receiver pour Windows, la version 12.8 ou ultérieure de Receiver pour Mac, ou la version 7.5 ou ultérieure de Receiver pour iOS ; 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. Voir Ports réseau.

Communication entre le Controller et le VDA

La protection au niveau du message 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.

TLS et redirection vidéo 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.

La version officielle de la documentation de ce produit est en anglais. Toute version dans une langue autre que l’anglais est fournie uniquement à titre indicatif et peut inclure du contenu traduit automatiquement. Pour en savoir plus, veuillez consulter la clause de non-responsabilité relative à la traduction automatique sur Cloud Software Group home.

Cela vous a-t-il été utile ?

Transport Layer Security (TLS)

May 31, 2026

Contributeur:

C C

May 31, 2026

Contributeur:

C C

Dans cet article

Installer les certificats de serveur TLS sur les contrôleurs
Modifier les ports HTTP ou HTTPS
Paramètres TLS sur les VDA
Communication entre le Controller et le VDA

Cela vous a-t-il été utile ?