XenApp and XenDesktop

Transport Layer Security (TLS)

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

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

    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 ces permissions.
    • Pour configurer TLS sur les VDA, vous devez être un administrateur Windows sur la machine sur laquelle le VDA est installé.
    • Si vous prévoyez de configurer TLS sur les VDA qui ont été mis à niveau à partir de versions antérieures, désinstallez tous les relais SSL sur ces machines avant de les mettre à niveau.
    • Le script PowerShell permet de configurer TLS sur les VDA statiques ; il ne configure pas TLS sur les VDA regroupés qui sont provisionnés par Machine Creation Services ou Provisioning Services, où l’image de la machine cliente est réinitialisée à chaque redémarrage.

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.

Remarque :

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

  • Pour un accès direct au VDA, Citrix Receiver utilise toujours TLS sur TCP (et non UDP et UDT).
  • Pour un accès indirect au VDA à l’aide de NetScaler Gateway, Citrix Receiver utilise DTLS sur UDP pour les communications avec NetScaler Gateway. Les communications entre NetScaler Gateway et le VDA utilisent UDP sans DTLS. UDT est utilisé.

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

  1. 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.
  2. Développez Personnel > Certificats, puis utilisez la commande de menu contextuel Toutes les tâches > Demander un nouveau certificat.

    Composant logiciel enfichable MMC Certificats

  3. Cliquez sur Suivant pour commencer, puis sur Suivant pour confirmer que vous obtenez le certificat à partir de l’inscription Active Directory.
  4. 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.

    Boîte de dialogue Demander des certificats

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

    Propriétés de certificat

Configuration du port de l’écouteur 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’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 :

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 autres 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. Dans 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 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

http-port est le numéro de port pour le trafic HTTP et https-port le numéro de port pour le trafic HTTPS.

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

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é. Lorsque vous configurez 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.

  • 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 (Citrix Receiver 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.

Trois ensembles de suites de chiffrement (également appelés modes de conformité) sont pris en charge par le VDA : GOV (gouvernement), COM (commercial) et ALL (tout). Les suites de chiffrement acceptables dépendent du mode FIPS Windows ; voir https://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 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 se trouve sur un serveur Windows Server 2012 R2, Windows Server 2016, 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), 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 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 (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 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 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 le protocole TLS, le script désactive toutes les règles du Pare-feu Windows existantes pour le port TCP spécifié avant d’ajouter une règle qui permet au service ICA d’accepter des connexions entrantes sur le port TCP TLS uniquement. 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 ; ils ne peuvent pas utiliser ICA/HDX, ICA/HDX avec 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 de nom de domaine complet est utilisé par défaut.

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>"]
<!--NeedCopy-->
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>” 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> Port TLS. Valeur par défaut : 443
SSLMinVersion “<version>” Version minimale du protocole TLS, entourés de guillemets. Valeurs valides : “SSL_3.0”, “TLS_1.0” (défaut), “TLS_1.1” et “TLS_1.2”. Important : Citrix recommande aux clients de vérifier leur utilisation de SSLv3 et de prendre des mesures pour reconfigurer leurs déploiements pour supprimer la prise en charge de SSLv3, le cas échéant. Consultez l’article CTX200238.
SSLCipherSuite “<suite>” Suite de chiffrement TLS, entourés de guillemets. Valeurs valides : « GOV », « COM » et « ALL » (par défaut)

Exemples

Le script suivant installe et active la version de protocole 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"

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 système d’exploitation de bureau Windows, ou NT SERVICE\TermService pour un VDA pour OS Windows Server. Sur la machine sur laquelle le VDA est installé :

  1. Lancez la console MMC (Microsoft Management Console) : Démarrer > Exécuter > mmc.exe.
  2. Ajouter le composant logiciel enfichable Certificats à la console MMC :

    1. Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable.
    2. Sélectionnez Certificats et cliquez sur Ajouter.
    3. 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.
    4. Lorsque vous y êtes invité par Sélectionnez l’ordinateur à gérer par ce composant logiciel enfichable, choisissez Ordinateur local, puis cliquez sur Terminer.
  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.

  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 système d’exploitation de bureau Windows, « PORTICASERVICE »
    • Pour un VDA pour OS de serveur Windows, « TERMSERVICE »
  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.

  6. Exécutez la commande regedit et rendez-vous sur HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

    1. 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).
    2. Modifier la clé SSLEnabled et modifiez la valeur DWORD sur 1. (Pour désactiver SSL ultérieurement, changez la valeur DWORD sur 0).
    3. 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.2, 3 = TLS 1.1, 4 = TLS 1.2. Valeur par défaut : 2 (TLS 1.2).

      SSLCipherSuite DWORD : 1 = GOV, 2 = COM, 3 = ALL. Valeur par défaut : 3 (ALL).

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

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

  9. Pour les VDA pour OS Windows Server, 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 système d’exploitation de bureau Windows).

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.

  1. À partir de Studio, ouvrez la console PowerShell.
  2. Exécutez asnp Citrix.* pour charger les applets de commande du produit Citrix.
  3. Exécutez Get-BrokerAccessPolicyRule -DesktopGroupName 'delivery-group-name' | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
  4. 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 Citrix Receiver pour Windows, si vous recevez une erreur de connexion (comme 1030) qui indique une erreur TLS, désactivez Desktop Viewer et essayez de vous reconnecter. Bien que la connexion échoue toujours, 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.

Communications entre le Controller et le VDA

Les communications entre le Controller et le VDA sont sécurisées par la protection 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 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.

TLS et redirection vidéo HTML5

Vous pouvez utiliser la redirection vidéo HTML5 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.

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