Documentation produit
XenApp and XenDesktop
7.15 LTSR
Voir PDF

Transport Layer Security (TLS)

May 20, 2026
Contributeur: 
C C

La configuration d’un site XenApp ou XenDesktop® pour utiliser le protocole Transport Layer Security (TLS) comprend les procédures suivantes :

  • 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 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 les utilisateurs et les Virtual Delivery Agents (VDA) en effectuant les tâches suivantes :

    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 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é.
    • Si vous avez l’intention de configurer TLS sur des VDA qui ont été mis à niveau à partir de versions antérieures, désinstallez tout logiciel de relais SSL sur ces machines avant de les mettre à niveau.
    • Le script PowerShell configure TLS sur les VDA statiques ; il ne configure pas TLS sur les VDA en pool qui sont provisionnés par Machine Creation Services™ ou Provisioning Services, où l’image de la machine est réinitialisée à chaque redémarrage.

Avertissement :

Pour les tâches qui incluent l’édition du registre Windows, une modification incorrecte du registre peut entraîner de graves problèmes pouvant 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 pour la base de données du site, consultez CTX137556.

Remarque :

Si TLS et UDT sont tous deux activés sur le VDA :

  • Pour un accès direct au VDA, Citrix Receiver™ utilise toujours TLS sur TCP (pas UDP et UDT).
  • Pour un accès indirect au VDA à l’aide de NetScaler® Gateway, Citrix Receiver utilise DTLS sur UDP pour la communication avec NetScaler Gateway. La communication entre NetScaler Gateway et le VDA utilise UDP sans DTLS. UDT est utilisé.

Installer les certificats de serveur TLS sur les Controllers

Pour HTTPS, le service XML prend en charge les fonctionnalités TLS à l’aide de certificats de serveur, et non de 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 à l’aide de l’Assistant d’inscription de certificat du composant logiciel enfichable MMC Certificats.

Demande et installation d’un certificat

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

  2. Développez Personnel > Certificats, puis utilisez la commande de menu contextuel Toutes les tâches > Demander un nouveau certificat.

    MMC Certificates snap-in

  3. Cliquez sur Suivant pour commencer, puis sur Suivant pour confirmer que vous acquérez le certificat à partir de l’inscription Active Directory.

  4. Sélectionnez le modèle pour le 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.

    Boîte de dialogue Demander des certificats

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

    Propriétés du certificat

Configuration du port d’écoute SSL/TLS

  1. Ouvrez une fenêtre de commande PowerShell en tant qu’administrateur de la machine.

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

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

  4. 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’il est correctement configuré, la sortie de la dernière commande .netsh http show sslcert indique que l’écouteur utilise le IP:port correct, et que Application ID correspond au GUID de l’application du service Broker.

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.

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). Ces suites de chiffrement doivent précéder toutes les suites de chiffrement TLS_DHE_.

Remarque :

Windows Server 2012 ne prend pas en charge les suites de chiffrement GCM TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

  1. À 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.
  2. 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é.
  3. 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 toutes les suites 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 valeurs 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.

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 | où Binding -eq “XML_HTTPS” | Register-ConfigServiceInstance

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 configurés avec TLS et de VDA non configurés avec TLS. Lorsque vous configurez TLS pour un groupe de mise à disposition, vous devez 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, 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. 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 et TLS 1.2. Vous 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.

  • Quelles suites de chiffrement TLS autoriser.

Une suite de chiffrement sélectionne le chiffrement qui sera utilisé pour une connexion. Les clients et les VDA peuvent prendre en charge différents ensembles de suites de chiffrement. Lorsqu’un client (Citrix Receiver 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.

Trois ensembles de suites de chiffrement (également appelés modes de conformité) sont pris en charge par le VDA : GOV(ernment), COM(mercial) et ALL. Les suites de chiffrement acceptables dépendent également du mode FIPS de Windows ; consultez https://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 GOV COM ALL GOV COM ALL
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_RSA_WITH_AES_256_GCM_SHA384 x   x x   x
TLS_RSA_WITH_AES_128_GCM_SHA256 x x x x x x
TLS_RSA_WITH_AES_256_CBC_SHA256 x   x x   x
TLS_RSA_WITH_AES_256_CBC_SHA x   x x   x
TLS_RSA_WITH_AES_128_CBC_SHA   x x   x x
TLS_RSA_WITH_RC4_128_SHA   x x      
TLS_RSA_WITH_RC4_128_MD5   x x      
TLS_RSA_WITH_3DES_EDE_CBC_SHA x   x x   x

Important :

Une étape supplémentaire est nécessaire lorsque le VDA est sur Windows Server 2012 R2, Windows Server 2016, 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 Receiver pour HTML5 et Citrix Receiver pour Chrome. Cela inclut également les connexions via NetScaler Gateway.

Cette étape est également requise pour toutes les connexions utilisant NetScaler Gateway, pour toutes les versions de VDA, si TLS est configuré entre NetScaler Gateway et le VDA. Cela affecte toutes les versions de Citrix Receiver.

Sur le VDA (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 > 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_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

Remarque :

Les quatre 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 Receiver 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 un VDA à l’aide du script PowerShell

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, le script désactive toutes les règles de pare-feu Windows existantes pour le port TCP spécifié avant d’ajouter une nouvelle règle qui permet au service ICA d’accepter les connexions entrantes uniquement sur le port TCP 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 ; ils ne peuvent pas utiliser ICA/HDX, ICA/HDX avec la fiabilité de session, ou HDX sur WebSocket, sans TLS.

Voir Ports réseau.

Remarque :

Pour les machines sans état, comme les cibles PVS ou les clones MCS, un certificat FQDN est utilisé par défaut.

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>"]
<!--NeedCopy-->
Paramètre Description
Enable Installe et active l’écouteur TLS sur le VDA. Ce paramètre ou le paramètre Disable est requis.
Disable Désactive l’écouteur TLS sur le VDA. 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, 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é.
SSLPort Port TLS. Par défaut : 443
SSLMinVersion “" Version minimale du protocole TLS, entre guillemets. Valeurs valides : « SSL_3.0 », « TLS_1.0 » (par défaut), « TLS_1.1 » et « TLS_1.2 ». Important : Citrix recommande aux clients de revoir leur utilisation de SSLv3 et de prendre des mesures pour reconfigurer leurs déploiements afin de supprimer la prise en charge de SSLv3 le cas échéant. Voir CTX200238.
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 1.2. 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 de bureau Windows, ou NT SERVICE\TermService pour un VDA pour OS de serveur Windows. Sur la machine où le VDA est installé :

  1. Lancez la console de gestion Microsoft (MMC) : Démarrer > Exécuter > mmc.exe.

  2. Ajoutez le composant logiciel enfichable Certificats à la MMC :

    1. Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable.
    2. Sélectionnez Certificats, puis cliquez sur Ajouter.
    3. Lorsque vous êtes invité par Ce composant logiciel enfichable gérera toujours les certificats pour :, choisissez Compte d’ordinateur, puis cliquez sur Suivant.
    4. Lorsque vous êtes invité par Sélectionnez l’ordinateur que vous souhaitez que ce composant logiciel enfichable gère, choisissez Ordinateur local, puis cliquez sur Terminer.

  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.

  4. L’éditeur de liste de contrôle d’accès affiche « Autorisations pour les clés privées de (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 de bureau Windows, « PORTICASERVICE »
    • Pour un VDA pour OS de serveur Windows, « TERMSERVICE »

  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.

  6. Exécutez regedit et accédez à HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

    1. 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).
    2. Modifiez la clé SSLEnabled et remplacez la valeur DWORD par 1. (Pour désactiver SSL ultérieurement, remplacez la valeur DWORD par 0.)

    3. 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 (ALL).

  7. Assurez-vous que le port TCP TLS est ouvert dans le Pare-feu Windows s’il ne s’agit pas du 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.)

  8. Assurez-vous qu’aucune autre application ou service (tel qu’IIS) n’utilise le port TCP TLS.

  9. Pour les VDA pour OS Windows Server, 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 Desktop.)

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.

  1. Depuis Studio, ouvrez la console PowerShell.
  2. Exécutez asnp Citrix.* pour charger les cmdlets du produit Citrix.
  3. Exécutez Get-BrokerAccessPolicyRule -DesktopGroupName 'delivery-group-name' | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
  4. Exécutez Set-BrokerSite -DnsResolutionEnabled $true.

Dépannage

En cas d’erreur de connexion, vérifiez le journal des événements système du VDA.

Lorsque vous utilisez Citrix Receiver pour Windows, si vous recevez une erreur de connexion (telle que 1030) 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écifié un modèle incorrect lors de la demande d’un certificat auprès de l’autorité de certification.

Communication entre le Controller et le VDA

La communication entre le Controller et le VDA est sécurisée par la protection au niveau des messages de Windows Communication Framework (WCF). 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 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

Vous pouvez utiliser la redirection vidéo HTML5 pour rediriger les sites Web HTTPS. Le JavaScript injecté dans ces sites Web doit établir une connexion TLS au 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.

Pour plus d’informations sur la redirection vidéo HTML5, consultez Paramètres de stratégie multimédia.

Transport Layer Security (TLS)
May 20, 2026
Contributeur: 
C C
May 20, 2026
Contributeur: 
C C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.