Transport Layer Security (TLS)
Citrix Virtual Apps and Desktops unterstützen das Transport Layer Security (TLS)-Protokoll für TCP-basierte Verbindungen zwischen Komponenten. Citrix Virtual Apps and Desktops unterstützen auch das Datagram Transport Layer Security (DTLS)-Protokoll für UDP-basierte ICA/HDX-Verbindungen unter Verwendung von adaptivem Transport.
TLS und DTLS sind ähnlich und unterstützen dieselben digitalen Zertifikate. Wenn Sie eine Citrix Virtual Apps- oder Citrix Virtual Desktops™-Site für die Verwendung von TLS konfigurieren, wird sie auch für die Verwendung von DTLS konfiguriert. Verwenden Sie die folgenden Verfahren; die Schritte sind für TLS und DTLS gleich, sofern nicht anders angegeben:
-
Beschaffen, installieren und registrieren Sie ein Serverzertifikat auf allen Delivery Controllern und konfigurieren Sie einen Port mit dem TLS-Zertifikat. Weitere Informationen finden Sie unter Installieren von TLS-Serverzertifikaten auf Controllern.
Optional können Sie die Ports ändern, die der Controller zum Abhören von HTTP- und HTTPS-Datenverkehr verwendet.
-
Aktivieren Sie TLS-Verbindungen zwischen der Citrix Workspace™-App und Virtual Delivery Agents (VDAs), indem Sie die folgenden Aufgaben ausführen:
- Konfigurieren Sie TLS auf den Maschinen, auf denen die VDAs installiert sind. (Der Einfachheit halber werden weitere Verweise auf Maschinen, auf denen VDAs installiert sind, einfach als „VDAs“ bezeichnet.) Allgemeine Informationen finden Sie unter TLS-Einstellungen auf VDAs. Es wird dringend empfohlen, das von Citrix bereitgestellte PowerShell-Skript zur Konfiguration von TLS/DTLS zu verwenden. Weitere Informationen finden Sie unter Konfigurieren von TLS auf einem VDA mithilfe des PowerShell-Skripts. Wenn Sie TLS/DTLS jedoch manuell konfigurieren möchten, lesen Sie Manuelles Konfigurieren von TLS auf einem VDA.
-
Konfigurieren Sie TLS in den Delivery Groups, die die VDAs enthalten, indem Sie eine Reihe von PowerShell-Cmdlets in Studio ausführen. Weitere Informationen finden Sie unter Konfigurieren von TLS in Delivery Groups.
Anforderungen und Überlegungen:
- Das Aktivieren von TLS-Verbindungen zwischen Benutzern und VDAs ist nur für XenApp 7.6- und XenDesktop 7.6-Sites sowie später unterstützte Releases gültig.
- Konfigurieren Sie TLS in den Delivery Groups und auf den VDAs, nachdem Sie Komponenten installiert, eine Site erstellt, Maschinenkataloge erstellt und Delivery Groups erstellt haben.
- Um TLS in den Delivery Groups zu konfigurieren, müssen Sie über die Berechtigung verfügen, Controller-Zugriffsregeln zu ändern. Ein Volladministrator besitzt diese Berechtigung.
- Um TLS auf den VDAs zu konfigurieren, müssen Sie ein Windows-Administrator auf der Maschine sein, auf der der VDA installiert ist.
- Bei gepoolten VDAs, die von Machine Creation Services™ oder Provisioning Services bereitgestellt werden, wird das VDA-Maschinenimage beim Neustart zurückgesetzt, wodurch frühere TLS-Einstellungen verloren gehen. Führen Sie das PowerShell-Skript bei jedem Neustart des VDAs aus, um die TLS-Einstellungen neu zu konfigurieren.
Warnung:
Bei Aufgaben, die die Arbeit in der Windows-Registrierung umfassen: Eine falsche Bearbeitung der Registrierung kann schwerwiegende Probleme verursachen, die möglicherweise eine Neuinstallation des Betriebssystems erfordern. Citrix® kann nicht garantieren, dass Probleme, die durch die falsche Verwendung des Registrierungs-Editors entstehen, behoben werden können. Verwenden Sie den Registrierungs-Editor auf eigenes Risiko. Sichern Sie die Registrierung unbedingt, bevor Sie sie bearbeiten.
Informationen zum Aktivieren von TLS für die Sitedatenbank finden Sie unter CTX137556.
Installieren von TLS-Serverzertifikaten auf Controllern
Für HTTPS unterstützt der XML-Dienst TLS-Funktionen mithilfe von Serverzertifikaten, nicht Clientzertifikaten. Dieser Abschnitt beschreibt den Erwerb und die Installation von TLS-Zertifikaten in Delivery Controllern. Dieselben Schritte können auf Cloud Connectors angewendet werden, um STA- und XML-Datenverkehr zu verschlüsseln.
Obwohl es verschiedene Arten von Zertifizierungsstellen und Methoden zum Anfordern von Zertifikaten gibt, beschreibt dieser Artikel die Microsoft-Zertifizierungsstelle. Die Microsoft-Zertifizierungsstelle muss eine Zertifikatvorlage mit dem Zweck der Serverauthentifizierung veröffentlicht haben.
Wenn die Microsoft-Zertifizierungsstelle in eine Active Directory-Domäne oder in die vertrauenswürdige Gesamtstruktur integriert ist, der die Delivery Controller beigetreten sind, können Sie ein Zertifikat über den Zertifikatsregistrierungs-Assistenten des MMC-Snap-Ins „Zertifikate“ erwerben.
Anfordern und Installieren eines Zertifikats
- Öffnen Sie auf dem Delivery Controller™ die MMC-Konsole und fügen Sie das Snap-In „Zertifikate“ hinzu. Wählen Sie bei Aufforderung „Computerkonto“ aus.
-
Erweitern Sie Persönlich > Zertifikate, und verwenden Sie dann den Kontextmenübefehl Alle Aufgaben > Neues Zertifikat anfordern.
- Klicken Sie auf Weiter, um zu beginnen, und erneut auf Weiter, um zu bestätigen, dass Sie das Zertifikat über die Active Directory-Registrierung erwerben.
-
Wählen Sie die Vorlage für das Serverauthentifizierungszertifikat aus. Wenn die Vorlage so eingerichtet wurde, dass die Werte für den Betreff automatisch bereitgestellt werden, können Sie auf Registrieren klicken, ohne weitere Details anzugeben.
-
Um weitere Details für die Zertifikatvorlage anzugeben, klicken Sie auf die Pfeilschaltfläche Details und konfigurieren Sie Folgendes:
Antragsstellername: Wählen Sie „Allgemeiner Name“ und fügen Sie den FQDN des Delivery Controllers hinzu.
Alternativer Name: Wählen Sie DNS aus und fügen Sie den FQDN des Delivery Controllers hinzu.
Konfigurieren des SSL/TLS-Listener-Ports
Wenn die IIS-Windows-Komponente auf demselben Server installiert ist, der als Teil von Web Studio und Director installiert ist, können Sie TLS mit IIS konfigurieren. Weitere Informationen finden Sie unter TLS in Web Studio und Director aktivieren. Andernfalls konfigurieren Sie das Zertifikat mit PowerShell wie folgt:
-
Um zu überprüfen, ob ein vorhandenes Zertifikat gebunden ist, öffnen Sie eine Eingabeaufforderung und führen Sie
netsh http show sslcertaus:netsh http show sslcert <!--NeedCopy--> -
Wenn eine vorhandene Bindung vorhanden ist, löschen Sie diese.
netsh http delete sslcert ipport=0.0.0.0:443 <!--NeedCopy-->Ersetzen Sie
0.0.0.0:443durch eine bestimmte IP-Adresse und einen Port, falls in der vorhandenen Bindung eine angegeben wurde. -
Suchen Sie den Fingerabdruck des zuvor installierten Zertifikats. Um den Fingerabdruck anzuzeigen, öffnen Sie Computerzertifikate verwalten, navigieren Sie zum Zertifikat, öffnen Sie es und wechseln Sie zur Registerkarte Details.
Alternativ können Sie PowerShell verwenden. Das folgende Skript sucht beispielsweise nach einem Zertifikat, dessen allgemeiner Name mit dem Hostnamen des Servers übereinstimmt, und gibt den Fingerabdruck aus:
$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-->Wenn der allgemeine Name des Zertifikats nicht mit den Hostnamen übereinstimmt, schlägt dies fehl. Wenn mehrere Zertifikate für den Hostnamen vorhanden sind, werden mehrere Fingerabdrücke aneinandergereiht zurückgegeben, und Sie müssen den entsprechenden Fingerabdruck auswählen.
Das folgende Beispiel sucht nach einem Zertifikat anhand des Anzeigenamens:
$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 <!--NeedCopy-->Wenn mehrere Zertifikate mit dem angegebenen Anzeigenamen vorhanden sind, werden mehrere Fingerabdrücke aneinandergereiht zurückgegeben, und Sie müssen den entsprechenden Fingerabdruck auswählen.
-
Um das Zertifikat an den Port zu binden, verwenden Sie den Befehl
netsh http add sslcert:netsh http add sslcert ipport=[IP address]:443 certhash=[certificate hash] appid=[application GUID] disablelegacytls=enable <!--NeedCopy-->-
ipport: Die IP-Adresse und der Port. Die Verwendung von 0.0.0.0:443 wendet dies auf alle IP-Adressen an. Sie können stattdessen eine bestimmte IP-Adresse angeben. -
certhash: Der Fingerabdruck des Zertifikats, das Sie im vorherigen Schritt identifiziert haben. -
appid: Die GUID des Citrix Broker Service.Hinweis:
Verwenden Sie beim Erneuern eines Zertifikats oder beim erneuten Binden die spezifische
appid, die dem Broker Service zugeordnet ist, anstatt einer beliebigen GUID.So finden Sie die korrekte
appidfür den Citrix Broker Service:-
Öffnen Sie ein PowerShell-Befehlsfenster als Administrator und führen Sie den folgenden Befehl aus:
Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" <!--NeedCopy--> -
Suchen Sie die IdentifyingNumber (GUID) für den Citrix Broker Service in der Ausgabe (zum Beispiel
{D333C884-187F-447C-8C67-463F33989C8F}). Verwenden Sie diese GUID für den Parameterappid.
-
-
disablelegacytls=enable: Deaktiviert ältere TLS-Versionen. Dieser Parameter ist unter Windows 2022 und höher verfügbar. Unter Windows 2022 deaktiviert er TLS 1.0 und 1.1. Unter Windows 2025 ist dies unnötig, da TLS 1.0 und 1.1 standardmäßig deaktiviert sind.
Führen Sie beispielsweise den folgenden Befehl aus, um das Zertifikat mit dem Fingerabdruck
bc96f958848639fd101a793b87915d5f2829b0b6an Port443auf allen IP-Adressen zu binden:netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable <!--NeedCopy--> -
Sobald HTTPS aktiviert ist, sollten Sie alle StoreFront-Bereitstellungen und Netscaler Gateways so konfigurieren, dass sie HTTPS anstelle von HTTP verwenden, um eine Verbindung zum Delivery Controller herzustellen.
Hinweis:
Wenn der Controller unter Windows Server 2016 installiert ist und StoreFront unter Windows Server 2012 R2 installiert ist, ist eine Konfigurationsänderung am Controller erforderlich, um die Reihenfolge der TLS-Chiffriersammlungen zu ändern. Diese Konfigurationsänderung ist für Controller und StoreFront mit anderen Kombinationen von Windows Server-Versionen nicht erforderlich.
Die Liste der Chiffriersammlungsreihenfolge muss die TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 oder TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Chiffriersammlungen (oder beide) enthalten; und diese Chiffriersammlungen müssen allen TLS_DHE_ Chiffriersammlungen vorangehen.
- Navigieren Sie im Microsoft Gruppenrichtlinien-Editor zu Computerkonfiguration > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen.
- Bearbeiten Sie die Richtlinie „SSL-Chiffriersammlungsreihenfolge“. Standardmäßig ist diese Richtlinie auf „Nicht konfiguriert“ eingestellt. Setzen Sie diese Richtlinie auf „Aktiviert“.
- Ordnen Sie die Suiten in der richtigen Reihenfolge an; entfernen Sie alle Cipher-Suiten, die Sie nicht verwenden möchten.
Stellen Sie sicher, dass entweder TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 oder TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 allen TLS_DHE_ Cipher-Suiten vorangestellt ist.
Siehe auch auf Microsoft MSDN: Priorisieren von Schannel-Cipher-Suiten.
HTTP- oder HTTPS-Ports ändern
Standardmäßig lauscht der XML-Dienst auf dem Controller an Port 80 für HTTP-Datenverkehr und an Port 443 für HTTPS-Datenverkehr. Obwohl Sie nicht standardmäßige Ports verwenden können, sollten Sie sich der Sicherheitsrisiken bewusst sein, die mit der Offenlegung eines Controllers gegenüber nicht vertrauenswürdigen Netzwerken verbunden sind. Die Bereitstellung eines eigenständigen StoreFront-Servers ist dem Ändern der Standardeinstellungen vorzuziehen.
Um die vom Controller verwendeten Standard-HTTP- oder HTTPS-Ports zu ändern, führen Sie den folgenden Befehl aus Studio aus:
BrokerService.exe -WIPORT \<http-port> -WISSLPORT \<https-port>
wobei <http-port> die Portnummer für HTTP-Datenverkehr ist und <https-port> die Portnummer für HTTPS-Datenverkehr ist.
Hinweis:
Nach dem Ändern eines Ports zeigt Studio möglicherweise eine Meldung zur Lizenzkompatibilität und zum Upgrade an. Um das Problem zu beheben, registrieren Sie Dienstinstanzen mithilfe der folgenden PowerShell-Cmdlet-Sequenz neu:
Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->
Nur HTTPS-Datenverkehr erzwingen
Wenn der XML-Dienst HTTP-Datenverkehr ignorieren soll, erstellen Sie die folgende Registrierungseinstellung unter HKLM\Software\Citrix\DesktopServer\ auf dem Controller und starten Sie dann den Broker-Dienst neu.
Um HTTP-Datenverkehr zu ignorieren, erstellen Sie den DWORD-Wert XmlServicesEnableNonSsl und setzen Sie ihn auf 0.
Es gibt einen entsprechenden Registrierungs-DWORD-Wert, den Sie erstellen können, um HTTPS-Datenverkehr zu ignorieren: DWORD XmlServicesEnableSsl. Stellen Sie sicher, dass er nicht auf 0 gesetzt ist.
TLS-Einstellungen auf VDAs
Eine Bereitstellungsgruppe darf keine Mischung aus einigen VDAs mit konfigurierter TLS und einigen VDAs ohne konfigurierte TLS enthalten. Bevor Sie TLS für eine Bereitstellungsgruppe konfigurieren, stellen Sie sicher, dass Sie TLS bereits für alle VDAs in dieser Bereitstellungsgruppe konfiguriert haben.
Wenn Sie TLS auf VDAs konfigurieren, werden die Berechtigungen für das installierte TLS-Zertifikat geändert, wodurch der ICA®-Dienst Lesezugriff auf den privaten Schlüssel des Zertifikats erhält und der ICA-Dienst über Folgendes informiert wird:
- Welches Zertifikat im Zertifikatspeicher für TLS verwendet werden soll.
-
Welche TCP-Portnummer für TLS-Verbindungen verwendet werden soll.
Die Windows-Firewall (sofern aktiviert) muss so konfiguriert sein, dass sie eingehende Verbindungen über diesen TCP-Port zulässt. Diese Konfiguration wird für Sie vorgenommen, wenn Sie das PowerShell-Skript verwenden.
-
Welche Versionen des TLS-Protokolls zugelassen werden sollen.
Wichtig:
Citrix empfiehlt, die Verwendung von SSLv3 zu überprüfen und die entsprechenden Bereitstellungen neu zu konfigurieren, um die Unterstützung für SSLv3 gegebenenfalls zu entfernen. Siehe CTX200238.
Die unterstützten TLS-Protokollversionen folgen einer Hierarchie (von der niedrigsten zur höchsten): SSL 3.0, TLS 1.0, TLS 1.1 und TLS 1.2. Geben Sie die minimal zulässige Version an; alle Protokollverbindungen, die diese Version oder eine höhere Version verwenden, sind zulässig.
Wenn Sie beispielsweise TLS 1.1 als Mindestversion angeben, sind TLS 1.1- und TLS 1.2-Protokollverbindungen zulässig. Wenn Sie SSL 3.0 als Mindestversion angeben, sind Verbindungen für alle unterstützten Versionen zulässig. Wenn Sie TLS 1.2 als Mindestversion angeben, sind nur TLS 1.2-Verbindungen zulässig.
DTLS 1.0 entspricht TLS 1.1 und DTLS 1.2 entspricht TLS 1.2.
-
Welche TLS-Cipher-Suites zugelassen werden sollen.
Eine Cipher-Suite wählt die Verschlüsselung aus, die für eine Verbindung verwendet wird. Clients und VDAs können unterschiedliche Sätze von Cipher-Suites unterstützen. Wenn ein Client (Citrix Workspace-App oder StoreFront) eine Verbindung herstellt und eine Liste der unterstützten TLS-Cipher-Suites sendet, gleicht der VDA eine der Cipher-Suites des Clients mit einer der Cipher-Suites in seiner eigenen Liste der konfigurierten Cipher-Suites ab und akzeptiert die Verbindung. Wenn keine übereinstimmende Cipher-Suite vorhanden ist, lehnt der VDA die Verbindung ab.
Der VDA unterstützt drei Sätze von Cipher-Suites (auch als Kompatibilitätsmodi bezeichnet): GOV(ernment), COM(mercial) und ALL. Die zulässigen Cipher-Suites hängen auch vom Windows FIPS-Modus ab; siehe http://support.microsoft.com/kb/811833 für Informationen zum Windows FIPS-Modus. Die folgende Tabelle listet die Cipher-Suites in jedem Satz auf:
| TLS/DTLS-Cipher-Suite | ALLE | COM | GOV | ALLE | COM | GOV |
|---|---|---|---|---|---|---|
| FIPS-Modus | Aus | Aus | Aus | Ein | Ein | Ein |
| 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 |
* Nicht unterstützt in Windows Server 2012 R2.
Hinweis:
Der VDA unterstützt keine DHE-Ciphersuites (z. B. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 und TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Wenn diese von Windows ausgewählt werden, werden sie möglicherweise nicht von Receiver verwendet.
Wenn Sie ein Citrix Gateway verwenden, lesen Sie die Citrix ADC-Dokumentation für Informationen zur Unterstützung von Ciphersuites für die Back-End-Kommunikation. Informationen zur TLS-Ciphersuite-Unterstützung finden Sie unter Verfügbare Ciphers auf den Citrix ADC Appliances. Informationen zur DTLS-Ciphersuite-Unterstützung finden Sie unter DTLS-Cipher-Unterstützung.
Anfordern und Installieren eines Zertifikats
- Öffnen Sie auf dem VDA die MMC-Konsole und fügen Sie das Zertifikate-Snap-In hinzu. Wählen Sie bei Aufforderung die Option Computerkonto.
- Erweitern Sie Persönlich > Zertifikate und verwenden Sie dann den Kontextmenübefehl Alle Aufgaben > Neues Zertifikat anfordern.
- Klicken Sie auf Weiter, um zu beginnen, und erneut auf Weiter, um zu bestätigen, dass Sie das Zertifikat von der Active Directory-Registrierung beziehen.
-
Wählen Sie die Vorlage für das Serverauthentifizierungszertifikat aus. Sowohl die Standard-Windows-Vorlage Computer als auch Webserver exportierbar sind akzeptabel. Wenn die Vorlage so eingerichtet wurde, dass die Werte für den Betreff automatisch bereitgestellt werden, können Sie auf Registrieren klicken, ohne weitere Details anzugeben.
-
Um weitere Details für die Zertifikatvorlage anzugeben, klicken Sie auf Details und konfigurieren Sie Folgendes:
Antragstellername – wählen Sie den Typ Allgemeiner Name und fügen Sie den FQDN des VDA hinzu
Alternativer Name – wählen Sie den Typ DNS und fügen Sie den FQDN des VDA hinzu
Hinweis:
Verwenden Sie die automatische Zertifikatregistrierung der Active Directory-Zertifikatdienste, um die Ausstellung und Bereitstellung von Zertifikaten für die VDAs zu automatisieren. Dies wird in https://support.citrix.com/article/CTX205473 beschrieben.
Sie können Wildcard-Zertifikate verwenden, um mehrere VDAs mit einem einzigen Zertifikat zu sichern:
Betreffname — wählen Sie den Typ Allgemeiner Name und geben Sie die *.primary.domain der VDAs ein
Alternativer Name — wählen Sie den Typ DNS und fügen Sie die *.primary.domain der VDAs hinzu
Sie können SAN-Zertifikate verwenden, um ein einzelnes Zertifikat zur Absicherung mehrerer spezifischer VDAs zu ermöglichen:
Betreffname — wählen Sie den Typ Allgemeiner Name und geben Sie eine Zeichenfolge ein, die zur Identifizierung der Zertifikatnutzung dient
Alternativer Name — wählen Sie den Typ DNS und fügen Sie einen Eintrag für den FQDN jedes VDAs hinzu. Halten Sie die Anzahl der alternativen Namen auf ein Minimum, um eine optimale TLS-Aushandlung zu gewährleisten.
Hinweis:
Sowohl Platzhalter- als auch SAN-Zertifikate erfordern, dass auf der Registerkarte „Privater Schlüssel“ die Option Privaten Schlüssel exportierbar machen ausgewählt ist:
TLS auf einem VDA mithilfe des PowerShell-Skripts konfigurieren
Installieren Sie das TLS-Zertifikat im Bereich „Lokaler Computer > Persönlich > Zertifikate“ des Zertifikatspeichers. Wenn sich mehr als ein Zertifikat an diesem Speicherort befindet, geben Sie den Fingerabdruck des Zertifikats an das PowerShell-Skript weiter.
Hinweis:
Ab XenApp und XenDesktop 7.16 LTSR findet das PowerShell-Skript das richtige Zertifikat basierend auf dem FQDN des VDAs. Sie müssen den Fingerabdruck nicht angeben, wenn nur ein einzelnes Zertifikat für den VDA-FQDN vorhanden ist.
Das Skript Enable-VdaSSL.ps1 aktiviert oder deaktiviert den TLS-Listener auf einem VDA. Dieses Skript ist im Ordner Support > Tools > SslSupport auf dem Installationsmedium verfügbar.
Wenn Sie TLS aktivieren, werden DHE-Cipher-Suites deaktiviert. ECDHE-Cipher-Suites sind davon nicht betroffen.
Wenn Sie TLS aktivieren, deaktiviert das Skript alle vorhandenen Windows-Firewallregeln für den angegebenen TCP-Port. Anschließend wird eine neue Regel hinzugefügt, die dem ICA-Dienst erlaubt, eingehende Verbindungen nur über die TLS-TCP- und UDP-Ports zu akzeptieren. Es deaktiviert auch die Windows-Firewallregeln für:
- Citrix ICA (Standard: 1494)
- Citrix CGP (Standard: 2598)
- Citrix WebSocket (Standard: 8008)
Dies hat zur Folge, dass Benutzer nur über TLS oder DTLS eine Verbindung herstellen können. Sie können ICA/HDX, ICA/HDX mit Sitzungszuverlässigkeit oder HDX über WebSocket nicht ohne TLS oder DTLS verwenden.
Hinweis:
DTLS wird nicht mit ICA/HDX Audio über UDP Real-time Transport oder mit ICA/HDX Framehawk unterstützt.
Siehe Netzwerkports.
Das Skript enthält die folgenden Syntaxbeschreibungen sowie zusätzliche Beispiele; Sie können ein Tool wie Notepad++ verwenden, um diese Informationen zu überprüfen.
Wichtig:
Geben Sie entweder den Parameter Enable oder Disable und den Parameter CertificateThumbPrint an. Die anderen Parameter sind optional.
Syntax
Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]
| Parameter | Beschreibung |
|---|---|
| Aktivieren | Installiert und aktiviert den TLS-Listener auf dem VDA. Entweder dieser Parameter oder der Parameter „Disable“ ist erforderlich. |
| Deaktivieren | Deaktiviert den TLS-Listener auf dem VDA. Entweder dieser Parameter oder der Parameter „Enable“ ist erforderlich. Wenn Sie diesen Parameter angeben, sind keine anderen Parameter gültig. |
| ZertifikatFingerabdruck “ |
Fingerabdruck des TLS-Zertifikats im Zertifikatspeicher, in Anführungszeichen eingeschlossen. Das Skript verwendet den angegebenen Fingerabdruck, um das zu verwendende Zertifikat auszuwählen. Wenn dieser Parameter weggelassen wird, wird ein falsches Zertifikat ausgewählt. |
| SSL-Port |
TLS-Port. Standard: 443 |
| SSL-Mindestversion “ |
Mindestversion des TLS-Protokolls, in Anführungszeichen eingeschlossen. Gültige Werte: „TLS_1.0“ (Standard), „TLS_1.1“ und „TLS_1.2“. |
| SSL-Chiffrensuite “ |
TLS-Cipher-Suite, in Anführungszeichen eingeschlossen. Gültige Werte: „GOV“, „COM“ und „ALL“ (Standard). |
Beispiele
Das folgende Skript installiert und aktiviert den Wert der TLS-Protokollversion. Der Fingerabdruck (in diesem Beispiel dargestellt als „12345678987654321“) wird verwendet, um das zu verwendende Zertifikat auszuwählen.
Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
Das folgende Skript installiert und aktiviert den TLS-Listener und gibt TLS-Port 400, die GOV-Cipher-Suite und einen minimalen TLS 1.2-Protokollwert an. Der Thumbprint (in diesem Beispiel als „12345678987654321“ dargestellt) wird verwendet, um das zu verwendende Zertifikat auszuwählen.
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.2"
-SSLCipherSuite "All"
Das folgende Skript deaktiviert den TLS-Listener auf dem VDA.
Enable-VdaSSL -Disable
TLS auf einem VDA manuell konfigurieren
Wenn Sie TLS auf einem VDA manuell konfigurieren, gewähren Sie dem entsprechenden Dienst auf jedem VDA generischen Lesezugriff auf den privaten Schlüssel des TLS-Zertifikats: NT SERVICE\PorticaService für einen VDA für Windows Single-session OS oder NT SERVICE\TermService für einen VDA für Windows Multi-session OS. Auf dem Computer, auf dem der VDA installiert ist:
SCHRITT 1. Starten Sie die Microsoft Management Console (MMC): Start > Ausführen > mmc.exe.
SCHRITT 2. Fügen Sie das Zertifikate-Snap-In zur MMC hinzu:
- Wählen Sie Datei > Snap-In hinzufügen/entfernen.
- Wählen Sie Zertifikate und klicken Sie dann auf Hinzufügen.
- Wenn Sie mit „Dieses Snap-In verwaltet immer Zertifikate für:“ aufgefordert werden, wählen Sie „Computerkonto“ und klicken Sie dann auf Weiter.
- Wenn Sie mit „Wählen Sie den Computer aus, den dieses Snap-In verwalten soll“ aufgefordert werden, wählen Sie „Lokaler Computer“ und klicken Sie dann auf Fertig stellen.
SCHRITT 3. Klicken Sie unter Zertifikate (Lokaler Computer) > Persönlich > Zertifikate mit der rechten Maustaste auf das Zertifikat und wählen Sie dann Alle Aufgaben > Private Schlüssel verwalten.
SCHRITT 4. Der Zugriffssteuerungslisten-Editor zeigt „Berechtigungen für private Schlüssel von (FriendlyName)“ an, wobei (FriendlyName) der Name Ihres TLS-Zertifikats ist. Fügen Sie einen der folgenden Dienste hinzu und erteilen Sie ihm Lesezugriff:
- Für einen VDA für Windows Single-session OS: „PORTICASERVICE“
- Für einen VDA für Windows Multi-session OS: „TERMSERVICE“
SCHRITT 5. Doppelklicken Sie auf das installierte TLS-Zertifikat. Wählen Sie im Zertifikatsdialog die Registerkarte Details und scrollen Sie dann nach unten. Klicken Sie auf Thumbprint.
SCHRITT 6. Führen Sie regedit aus und navigieren Sie zu HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Bearbeiten Sie den Schlüssel SSL Thumbprint und kopieren Sie den Wert des Fingerabdrucks des TLS-Zertifikats in diesen Binärwert. Sie können unbekannte Elemente im Dialogfeld „Binärwert bearbeiten“ (z. B. „0000“ und Sonderzeichen) bedenkenlos ignorieren.
- Bearbeiten Sie den Schlüssel SSLEnabled und ändern Sie den DWORD-Wert in 1. (Um SSL später zu deaktivieren, ändern Sie den DWORD-Wert in 0.)
-
Wenn Sie die Standardeinstellungen ändern möchten (optional), verwenden Sie im selben Registrierungspfad Folgendes:
SSLPort DWORD – SSL-Portnummer. Standard: 443.
SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Standard: 2 (TLS 1.0).
SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Standard: 3 (ALL).
SCHRITT 7. Stellen Sie sicher, dass die TLS-TCP- und UDP-Ports in der Windows-Firewall geöffnet sind, falls sie nicht dem Standard 443 entsprechen. (Wenn Sie die eingehende Regel in der Windows-Firewall erstellen, stellen Sie sicher, dass in ihren Eigenschaften die Einträge „Verbindung zulassen“ und „Aktiviert“ ausgewählt sind.)
SCHRITT 8. Stellen Sie sicher, dass keine anderen Anwendungen oder Dienste (wie IIS) den TLS-TCP-Port verwenden.
SCHRITT 9. Starten Sie bei VDAs für Windows Multi-Session OS die Maschine neu, damit die Änderungen wirksam werden. (Sie müssen Maschinen mit VDAs für Windows Single-Session OS nicht neu starten.)
Wichtig:
Ein zusätzlicher Schritt ist erforderlich, wenn der VDA unter Windows Server 2012 R2, Windows Server 2016 oder Windows 10 Anniversary Edition oder einer späteren unterstützten Version ausgeführt wird. Dies betrifft Verbindungen von Citrix Receiver für Windows (Version 4.6 bis 4.9), Citrix Workspace-App für HTML5 und Citrix Workspace-App für Chrome. Dies schließt auch Verbindungen über Citrix Gateway ein.
Dieser Schritt ist auch für alle Verbindungen über Citrix Gateway für alle VDA-Versionen erforderlich, wenn TLS zwischen Citrix Gateway und dem VDA konfiguriert ist. Dies betrifft alle Citrix Receiver™-Versionen.
Gehen Sie auf dem VDA (Windows Server 2012 R2, Windows Server 2016 oder Windows 10 Anniversary Edition oder höher) im Gruppenrichtlinien-Editor zu Computerkonfiguration > Richtlinien > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen > SSL-Chiffre-Suite-Reihenfolge. Wählen Sie die folgende Reihenfolge:
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
Hinweis:
Die ersten sechs Elemente geben auch die elliptische Kurve P384 oder P256 an. Stellen Sie sicher, dass „curve25519“ nicht ausgewählt ist. Der FIPS-Modus verhindert die Verwendung von „curve25519“ nicht.
Wenn diese Gruppenrichtlinieneinstellung konfiguriert ist, wählt der VDA eine Cipher Suite nur aus, wenn sie in beiden Listen erscheint: der Gruppenrichtlinienliste und der Liste für den ausgewählten Kompatibilitätsmodus (COM, GOV oder ALL). Die Cipher Suite muss auch in der vom Client (Citrix Workspace-App oder StoreFront) gesendeten Liste erscheinen.
Diese Gruppenrichtlinienkonfiguration wirkt sich auch auf andere TLS-Anwendungen und -Dienste auf dem VDA aus. Wenn Ihre Anwendungen bestimmte Cipher Suites erfordern, müssen Sie diese möglicherweise dieser Gruppenrichtlinienliste hinzufügen.
Wichtig:
Auch wenn Gruppenrichtlinienänderungen bei ihrer Anwendung angezeigt werden, treten Gruppenrichtlinienänderungen für die TLS-Konfiguration erst nach einem Neustart des Betriebssystems in Kraft. Daher sollten Sie bei gepoolten Desktops die Gruppenrichtlinienänderungen für die TLS-Konfiguration auf das Basisimage anwenden.
TLS auf Delivery Groups konfigurieren
Führen Sie dieses Verfahren für jede Delivery Group aus, die VDAs enthält, die Sie für TLS-Verbindungen konfiguriert haben.
- Öffnen Sie in Studio die PowerShell-Konsole.
- Führen Sie asnp Citrix.* aus, um die Citrix-Produkt-Cmdlets zu laden.
- Führen Sie Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true aus.
- Führen Sie Set-BrokerSite -DnsResolutionEnabled $true aus.
Problembehandlung
Wenn ein Verbindungsfehler auftritt, überprüfen Sie das Systemereignisprotokoll auf dem VDA.
Wenn Sie die Citrix Workspace-App für Windows verwenden und einen Verbindungsfehler erhalten, der auf einen TLS-Fehler hinweist, deaktivieren Sie Desktop Viewer und versuchen Sie dann erneut, eine Verbindung herzustellen. Obwohl die Verbindung weiterhin fehlschlägt, wird möglicherweise eine Erklärung des zugrunde liegenden TLS-Problems bereitgestellt. (Beispiel: Sie haben beim Anfordern eines Zertifikats von der Zertifizierungsstelle eine falsche Vorlage angegeben.)
Die meisten Konfigurationen, die HDX™ Adaptive Transport verwenden, funktionieren erfolgreich mit DTLS, einschließlich derer, die die neuesten Versionen der Citrix Workspace-App, von Citrix Gateway und des VDA verwenden. Einige Konfigurationen, die DTLS zwischen der Citrix Workspace-App und Citrix Gateway sowie DTLS zwischen Citrix Gateway und dem VDA verwenden, erfordern zusätzliche Maßnahmen.
Zusätzliche Maßnahmen sind erforderlich, wenn:
- die Citrix Receiver-Version HDX Adaptive Transport und DTLS unterstützt: Receiver for Windows (4.7, 4.8, 4.9), Receiver for Mac (12.5, 12.6, 12.7), Receiver for iOS (7.2, 7.3.x) oder Receiver for Linux (13.7)
und eine der folgenden Bedingungen ebenfalls zutrifft:
-
die Citrix Gateway-Version DTLS zum VDA unterstützt, die VDA-Version jedoch kein DTLS unterstützt (Version 7.15 oder früher),
-
die VDA-Version DTLS unterstützt (Version 7.16 oder höher), die Citrix Gateway-Version jedoch kein DTLS zum VDA unterstützt.
Um zu verhindern, dass Verbindungen von Citrix Receiver fehlschlagen, führen Sie eine der folgenden Aktionen aus:
- aktualisieren Sie Citrix Receiver auf Receiver for Windows Version 4.10 oder höher, Receiver for Mac 12.8 oder höher oder Receiver for iOS Version 7.5 oder höher; oder
- aktualisieren Sie Citrix Gateway auf eine Version, die DTLS zum VDA unterstützt; oder
- aktualisieren Sie den VDA auf Version 7.16 oder höher; oder
- deaktivieren Sie DTLS am VDA; oder
- deaktivieren Sie HDX Adaptive Transport.
Hinweis:
Ein geeignetes Update für Receiver for Linux ist noch nicht verfügbar. Receiver for Android (Version 3.12.3) unterstützt HDX Adaptive Transport und DTLS über Citrix Gateway nicht und ist daher nicht betroffen.
Um DTLS am VDA zu deaktivieren, ändern Sie die VDA-Firewallkonfiguration, um UDP-Port 443 zu deaktivieren. Siehe Netzwerkports.
Kommunikation zwischen Controller und VDA
Der Windows Communication Framework (WCF)-Nachrichtenschutz sichert die Kommunikation zwischen dem Controller und dem VDA. Ein zusätzlicher Transportebenen-Schutz mittels TLS ist nicht erforderlich. Die WCF-Konfiguration verwendet Kerberos zur gegenseitigen Authentifizierung zwischen Controller und VDA. Die Verschlüsselung verwendet AES im CBC-Modus mit einem 256-Bit-Schlüssel. Die Nachrichtenintegrität verwendet SHA-1.
Laut Microsoft entsprechen die von WCF verwendeten Sicherheits-Protokolle den Standards von OASIS (Organization for the Advancement of Structured Information Standards), einschließlich WS-SecurityPolicy 1.2. Zusätzlich gibt Microsoft an, dass WCF alle in Security Policy 1.2 aufgeführten Algorithmus-Suites unterstützt.
Die Kommunikation zwischen Controller und VDA verwendet die basic256-Algorithmus-Suite, deren Algorithmen wie oben angegeben sind.
TLS und HTML5-Videoumleitung sowie Browserinhaltsumleitung
Sie können die HTML5-Videoumleitung und die Browserinhaltsumleitung verwenden, um HTTPS-Websites umzuleiten. Das in diese Websites injizierte JavaScript muss eine TLS-Verbindung zum Citrix HDX HTML5 Video Redirection Service herstellen, der auf dem VDA ausgeführt wird. Um dies zu erreichen, generiert der HTML5 Video Redirection Service zwei benutzerdefinierte Zertifikate im Zertifikatspeicher auf dem VDA. Beim Beenden des Dienstes werden die Zertifikate entfernt.
Die Richtlinie für die HTML5-Videoumleitung ist standardmäßig deaktiviert.
Die Browserinhaltsumleitung ist standardmäßig aktiviert.
Weitere Informationen zur HTML5-Videoumleitung finden Sie unter Multimedia-Richtlinieneinstellungen.