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. Das Konfigurieren einer Citrix Virtual Apps- oder Citrix Virtual Desktops™ Site zur Verwendung von TLS konfiguriert sie auch zur Verwendung von DTLS. Verwenden Sie die folgenden Verfahren; die Schritte sind für TLS und DTLS gemeinsam, 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 mit dem PowerShell-Skript. 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 Full Administrator verfügt über 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 jedes Mal aus, wenn der VDA neu gestartet wird, um die TLS-Einstellungen neu zu konfigurieren.
Warnung:
Für Aufgaben, die die Arbeit in der Windows-Registrierung umfassen: Eine falsche Bearbeitung der Registrierung kann schwerwiegende Probleme verursachen, die möglicherweise eine Neuinstallation Ihres Betriebssystems erfordern. Citrix® kann nicht garantieren, dass Probleme, die aus der falschen Verwendung des Registrierungs-Editors resultieren, gelöst 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 die Beschaffung und Installation von TLS-Zertifikaten in Delivery Controllern. Dieselben Schritte können auf Cloud Connectors angewendet werden, um den STA- und XML-Datenverkehr zu verschlüsseln.
Obwohl es verschiedene Arten von Zertifizierungsstellen und Methoden zur Anforderung 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“ abrufen.
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 abrufen.
-
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:
Antragstellername: 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 wird, 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:
-
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 zusammenhängend 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 zusammenhängend 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 richtige
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 auf Windows Server 2016 installiert ist und StoreFront auf Windows Server 2012 R2 installiert ist, ist eine Konfigurationsänderung am Controller erforderlich, um die Reihenfolge der TLS-Cipher-Suites zu ändern. Diese Konfigurationsänderung ist für Controller und StoreFront mit anderen Kombinationen von Windows Server-Versionen nicht erforderlich.
Die Reihenfolgeliste der Cipher-Suites muss die TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 oder TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Cipher-Suites (oder beide) enthalten; und diese Cipher-Suites müssen allen TLS_DHE_ Cipher-Suites vorangehen.
- Navigieren Sie im Microsoft Gruppenrichtlinien-Editor zu Computerkonfiguration > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen.
- Bearbeiten Sie die Richtlinie „SSL-Cipher-Suite-Reihenfolge“. 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.
Auf Microsoft MSDN siehe auch 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 entstehen, wenn ein Controller nicht vertrauenswürdigen Netzwerken ausgesetzt wird. 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 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 die Dienstinstanzen mit 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 in HKLM\Software\Citrix\DesktopServer\ auf dem Controller und starten Sie anschließend 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 DWORD-Registrierungswert, den Sie erstellen können, um HTTPS-Datenverkehr zu ignorieren: DWORD XmlServicesEnableSsl. Stellen Sie sicher, dass dieser nicht auf 0 gesetzt ist.
TLS-Einstellungen auf VDAs
Eine Bereitstellungsgruppe kann keine Mischung aus VDAs mit konfigurierter TLS und 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® Service Lesezugriff auf den privaten Schlüssel des Zertifikats erhält und der ICA Service ü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 eingehende Verbindungen auf diesem TCP-Port zugelassen werden. 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 (niedrigste bis höchste): SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 und TLS 1.3. 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.3-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.3 als Mindestversion angeben, sind nur TLS 1.3-Verbindungen zulässig.
DTLS 1.0 entspricht TLS 1.1 und DTLS 1.3 entspricht TLS 1.3.
-
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 passende Cipher-Suite vorhanden ist, lehnt der VDA die Verbindung ab.
Der VDA unterstützt drei Sätze von Cipher-Suites (auch als Compliance-Modi 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-Cipher-Suites (zum Beispiel: 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 sie von Windows ausgewählt werden, können sie möglicherweise nicht von Receiver verwendet werden.
Wenn Sie ein Citrix Gateway verwenden, lesen Sie die Citrix ADC-Dokumentation für Informationen zur Unterstützung von Cipher-Suites für die Back-End-Kommunikation. Informationen zur Unterstützung von TLS-Cipher-Suites finden Sie unter Verfügbare Cipher auf den Citrix ADC Appliances. Informationen zur Unterstützung von DTLS-Cipher-Suites 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 Computeraccount.
- 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 beziehen.
-
Wählen Sie die Vorlage für das Serverauthentifizierungszertifikat aus. Sowohl die Standardoptionen von Windows Computer als auch Webserver exportierbar sind akzeptabel. Wenn die Vorlage so eingerichtet wurde, dass sie die Werte für den Betreff automatisch bereitstellt, 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 zum Sichern mehrerer spezifischer VDAs zu ermöglichen:
Betreffname – wählen Sie den Typ Allgemeiner Name und geben Sie eine Zeichenfolge ein, die die Zertifikatsnutzung identifiziert
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 Zertifikatspeicher unter Lokaler Computer > Persönlich > Zertifikate. 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 es dem ICA-Dienst erlaubt, eingehende Verbindungen nur über die TLS-TCP- und UDP-Ports zu akzeptieren. Außerdem werden die Windows-Firewallregeln für Folgendes deaktiviert:
- 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 |
| SSLMinVersion “ |
Minimale TLS-Protokollversion, in Anführungszeichen eingeschlossen. Gültige Werte: „TLS_1.0“ (Standard), „TLS_1.1“ und „TLS_1.3“. |
| SSLCipherSuite “ |
TLS-Cipher-Suite, in Anführungszeichen eingeschlossen. Gültige Werte: „GOV“, „COM“ und „ALL“ (Standard). |
Beispiele
Das folgende Skript installiert und aktiviert die 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 den TLS-Port 400, die GOV-Cipher-Suite und einen minimalen TLS 1.2-Protokollwert an. Der Fingerabdruck (in diesem Beispiel dargestellt als „12345678987654321“) wird verwendet, um das zu verwendende Zertifikat auszuwählen.
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.3"
-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 privaten Schlüssel des TLS-Zertifikats für den entsprechenden Dienst auf jedem VDA generischen Lesezugriff: 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 aus 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 Editor für Zugriffssteuerungslisten 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 Fingerabdruck.
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) 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.3. 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 für VDAs für Windows Multi-session OS den Computer neu, damit die Änderungen wirksam werden. (Sie müssen Computer 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 und 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 Gruppenrichtlinieneditor zu Computerkonfiguration > Richtlinien > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen > SSL-Chiffre-Suite-Reihenfolge. Wählen Sie die folgende Reihenfolge aus:
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 an, P384 oder P256. 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 dann aus, wenn sie in beiden Listen vorkommt: in der Gruppenrichtlinienliste und in 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:
Obwohl Gruppenrichtlinienänderungen bei der Anwendung angezeigt werden, werden Gruppenrichtlinienänderungen für die TLS-Konfiguration erst nach einem Neustart des Betriebssystems wirksam. Wenden Sie daher bei gepoolten Desktops die Gruppenrichtlinienänderungen für die TLS-Konfiguration auf das Basisimage an.
TLS in 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 bei der Verwendung der Citrix Workspace-App für Windows 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 eine falsche Vorlage angegeben, als Sie ein Zertifikat von der Zertifizierungsstelle angefordert haben.)
Die meisten Konfigurationen, die HDX™ Adaptive Transport verwenden, funktionieren erfolgreich mit DTLS, einschließlich derjenigen, die die neuesten Versionen der Citrix Workspace-App, des Citrix Gateway und des VDA verwenden. Einige Konfigurationen, die DTLS zwischen der Citrix Workspace-App und dem Citrix Gateway sowie DTLS zwischen dem 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 für Windows (4.7, 4.8, 4.9), Receiver für Mac (12.5, 12.6, 12.7), Receiver für iOS (7.2, 7.3.x) oder Receiver für 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 vermeiden, dass Verbindungen von Citrix Receiver fehlschlagen, führen Sie eine der folgenden Aktionen aus:
- Aktualisieren Sie Citrix Receiver auf Receiver für Windows Version 4.10 oder höher, Receiver für Mac 12.8 oder höher oder Receiver für 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 auf dem VDA; oder
- Deaktivieren Sie HDX Adaptive Transport.
Hinweis:
Ein geeignetes Update für Receiver für Linux ist noch nicht verfügbar. Receiver für Android (Version 3.12.3) unterstützt HDX Adaptive Transport und DTLS über Citrix Gateway nicht und ist daher nicht betroffen.
Um DTLS auf dem 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) Nachrichtenebenenschutz 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 Algorithmus-Suite basic256, deren Algorithmen wie oben beschrieben 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. Das Beenden des Dienstes entfernt die Zertifikate.
Die Richtlinie zur HTML5-Videoumleitung ist standardmäßig deaktiviert.
Die Browserinhaltsumleitung ist standardmäßig aktiviert.
Weitere Informationen zur HTML5-Videoumleitung finden Sie unter Multimedia-Richtlinieneinstellungen.