Transport Layer Security（TLS）
Citrix Virtual Apps and Desktopsは、コンポーネント間のTCPベースの接続でTLS（Transport Layer Security）プロトコルをサポートしています。Citrix Virtual Apps and Desktopsは、アダプティブトランスポートを使用して、UDPベースのICA/HDX接続用のDTLS（Datagram Transport Layer Security）プロトコルもサポートしています。
TLSとDTLSは似ており、同じデジタル証明書をサポートします。TLSを使用するようにCitrix Virtual AppsサイトまたはCitrix Virtual Desktopsサイトを設定すると、DTLSも使用するように設定されます。次の手順を使用します。これらの手順は、TLSとDTLSの両方に共通していますが、以下の点が異なります。
-
サーバー証明書を入手して、すべてのDelivery Controller上にインストールして登録します。さらに、TLS証明書のポート構成を行います。詳しくは、「TLSサーバー証明書のControllerへのインストール」を参照してください。
必要な場合は、ControllerでHTTPおよびHTTPSトラフィック用に使用されるポートを変更することもできます。
-
Citrix WorkspaceアプリとVirtual Delivery Agent（VDA）間のTLS接続を有効にします。これを行うには、以下のタスクを実行する必要があります：
- VDAがインストールされたマシン上でTLSを構成します（便宜上、VDAがインストールされたマシンをここでは「VDA」と呼びます）。概要については、「VDA上のTLS設定」を参照してください。TLS/DTLSを設定するには、Citrix提供のPowerShellスクリプトを使用することを強くお勧めします。詳しくは、「VDA上のTLS構成：PowerShellスクリプトの使用」を参照してください。ただし、TLS/DTLSを手動で構成する場合は、「VDA上のTLS構成：手作業による構成」を参照してください。
-
VDAが追加されているデリバリーグループでTLSを構成します。これを行うには、StudioでいくつかのPowerShellコマンドレットを実行します。詳しくは、「デリバリーグループのTLSの構成」を参照してください。
以下の要件および考慮事項があります：
- ユーザーとVDA間のTLS接続を有効にするのは、XenApp 7.6サイト、XenDesktop 7.6サイト、およびこれ以降のリリースでのみ必要です。
- デリバリーグループおよびVDA上のTLSは、コンポーネントのインストール、サイトの作成、およびマシンカタログとデリバリーグループの作成を行った後で構成します。
- デリバリーグループでTLSを構成するには、Controllerのアクセス規則を変更するための権限が必要です。すべての管理権限を実行できる管理者には必要な権限が付与されています。
- VDA上のTLSを構成するには、そのマシン上のWindows管理者権限が必要です。
- Machine Creation ServicesまたはProvisioning ServicesによってプロビジョニングされたプールされたVDAでは、VDAマシンイメージは再起動時にリセットされ、以前のTLS設定は失われます。VDAを再起動するたびにPowerShellスクリプトを実行して、TLS設定を再構成してください。
警告：
Windowsレジストリの編集を含むタスクの場合：レジストリの編集を誤ると、深刻な問題が発生する可能性があり、オペレーティングシステムの再インストールが必要になる場合もあります。レジストリエディターの誤用による障害に対して、Citrixでは一切責任を負いません。レジストリエディターは、お客様の責任と判断の範囲でご使用ください。また、レジストリファイルのバックアップを作成してから、レジストリを編集してください。
サイトデータベース接続のTLSを有効にする方法については、CTX137556を参照してください。
TLSサーバー証明書のControllerへのインストール
HTTPS接続を使用する場合、XML Serviceはサーバー証明書を使用することでTLS機能をサポートしますが、クライアント証明書はサポートしません。このセクションでは、Delivery ControllerでのTLS証明書の取得とインストールについて説明します。同じ手順をCloud Connectorに適用して、STAおよびXMLトラフィックを暗号化できます。
証明機関にはさまざまな種類があり、そこに証明書を要求する方法もさまざまですが、この資料ではMicrosoft証明機関について説明します。Microsoft証明機関は、サーバー認証の目的で発行された証明書テンプレートを保有している必要があります。
Microsoft証明機関が、Active DirectoryドメインまたはDelivery Controllerが参加している信頼されたフォレストに統合されている場合は、証明書MMCスナップインの証明書登録ウィザードから証明書を取得できます。
証明書の要求とインストール
- Delivery Controllerで、MMCコンソールを開き、証明書スナップインを追加します。プロンプトが表示されたら、［コンピューターアカウント］を選択します。
-
［個人］>［証明書］ を展開し、［すべてのタスク］>［新しい証明書の要求］ コンテキストメニューコマンドを使用します。
- ［次へ］ をクリックして開始し、［次へ］ をクリックして、Active Directoryの登録から証明書を取得していることを確認します。
-
サーバー認証証明書のテンプレートを選択します。［件名］の値が自動的に入力されるようにテンプレートが設定されている場合は、詳細を指定せずに ［登録］ をクリックできます。
-
証明書テンプレートの詳細情報を入力するには、［詳細］ 矢印ボタンをクリックし、次の項目を構成します：
サブジェクト名： 共通名を選択し、Delivery Controllerの完全修飾ドメイン名を追加します。
代替名： DNSを選択し、Delivery Controllerの完全修飾ドメイン名を追加します。
SSL/TLSリスナーポートの構成
- マシンの管理者としてPowerShellコマンドウィンドウを開きます。
-
ブローカーサービスアプリケーションGUIDを取得するには、次のコマンドを実行します：
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--> -
同じPowerShellウィンドウで次のコマンドを実行して、以前にインストールした証明書の拇印を取得します：
$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--> -
同じPowerShellウィンドウで次のコマンドを実行して、ブローカーサービスのSSL/TLSポートを構成し、暗号化用の証明書を使用します：
$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-->
正しく構成された場合、最後のコマンド.netsh http show sslcertの出力に、リスナーが正しいIP:portを使用していること、およびApplication IDがブローカーサービスアプリケーションGUIDと一致していることが示されます。
サーバーがDelivery Controllerにインストールされた証明書を信頼している場合、StoreFront Delivery ControllerおよびCitrix Gateway STAバインディングで、HTTPではなくHTTPSを使用するように構成できます。
注：
ControllerをWindows Server 2016にインストールし、StoreFrontをWindows Server 2012 R2にインストールする場合は、TLSの暗号の組み合わせ順を変更するために、Controllerで構成を変更する必要があります。この構成の変更は、他のバージョンのWindows Serverの組み合わせのControllerとStoreFrontでは必要ありません。
暗号の組み合わせの順序一覧には、 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384またはTLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256の暗号の組み合わせ（またはこの両方）を含める必要があります。これらの暗号の組み合わせは、TLS_DHE_の暗号の組み合わせより前に配置する必要があります。
- Microsoftのグループポリシーエディターを使用して、［コンピューターの構成］>［管理用テンプレート］>［ネットワーク］>［SSL構成設定］ の順に参照します。
- 「SSL暗号の順位」ポリシーを編集します。デフォルトでは、このポリシーは［未構成］に設定されています。このポリシーを ［有効］ に設定します。
- 暗号の組み合わせを適切な順序に並び替え、使用しない暗号の組み合わせを削除します。
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384またはTLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256のどちらかがすべてのTLS_DHE_暗号の組み合わせより前に配置されていることを確認します。
Microsoft MSDNの「Prioritizing Schannel Cipher Suites」も参照してください。
HTTPまたはHTTPSポートの変更
デフォルトでは、XML ServiceはHTTPトラフィックにはポート80を、HTTPSトラフィックにはポート443を使用します。これらのポート番号を変更することもできますが、信頼されないネットワークにControllerを露出させる場合のセキュリティ上のリスクについて考慮してください。デフォルト構成を変更する場合は、スタンドアロンのStoreFrontサーバーを使用することをお勧めします。
Controllerで使用されるデフォルトのHTTPまたはHTTPSポートを変更するには、Studioで次のコマンドを実行します：
BrokerService.exe -WIPORT \<http-port> -WISSLPORT \<https-port>
ここで、<http-port>はHTTPトラフィックのポート番号で、<https-port>はHTTPSトラフィックのポート番号です。
注：
ポートが変更されると、ライセンスの互換性およびアップグレードに関するメッセージがStudioに表示されます。この問題を解決するには、以下のPowerShellコマンドレットを順に実行してサービスインスタンスを再登録してください：
Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->
HTTPSトラフィックのみに制限する
HTTPトラフィックがXML Serviceで無視されるように構成するには、Controller上の HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\で以下のレジストリ設定を作成してからBroker Serviceを再起動します。
HTTPトラフィックを無視するには、DWORD XmlServicesEnableNonSslを作成して0に設定します。
同様に、HTTPSトラフィックを無視するために作成できるレジストリのDWORD値も存在します：DWORD XmlServicesEnableSsl これは0に設定しないでください。
VDA上のTLS設定
TLSを構成したVDAと構成していないVDAを同一デリバリーグループ内で混在させることはできません。デリバリーグループのTLSを構成する前に、そのグループに属しているすべてのVDA上でTLS構成を完了しておいてください。
VDA上にTLSを構成すると、インストールされているTLS証明書の権限が変更され、その証明書の秘密キーに対する読み取り権限がICA Serviceに付与されます。ICA Serviceには、以下の情報が提供されます：
- TLSで使用される証明書ストア内の証明書。
-
どのTCPポートがTLS接続で使用されるのか。
Windowsファイアウォールを使用する環境では、このTCPでの着信接続が許可されている必要があります。PowerShellスクリプトを使用する場合は、このファイアウォール規則が自動的に構成されます。
-
どのバージョンのTLSプロトコルが許可されるのか。
重要：
SSLv3の使用状況を確認し、必要に応じ、それらの展開を再構成してSSLv3のサポートを削除することをCitrixではお勧めします。CTX200238を参照してください。
サポートされるTLSプロトコルのバージョンは次の通りです：（低いものから）SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、およびTLS 1.3。サポートされるSSLプロトコルを指定するときは、許可する最低バージョンを指定します。
たとえば、最低バージョンとしてTLS 1.1を指定すると、TLS 1.1およびTLS 1.3のプロトコルを使用した接続が許可されます。最低バージョンとしてSSL 3.0を指定すると、サポートされるSSLプロトコルのすべてのバージョンが許可されます。最低バージョンとしてTLS 1.3を指定すると、TLS 1.3の接続のみが許可されます。
DTLS 1.0はTLS 1.1に対応し、DTLS 1.3はTLS 1.3に対応します。
-
どのTLS暗号の組み合わせが許可されるのか。
暗号の組み合わせにより、この接続において使用する暗号化が選択されます。 クライアントとVDAは、暗号スイートの異なる組み合わせをサポートできます。クライアント（Citrix WorkspaceアプリまたはStoreFront）がVDAに接続するときは、そのクライアントがサポートするTLS暗号スイートの一覧をVDAに送信します。VDA側では、構成済みの暗号スイートの独自の一覧内にクライアントのいずれかの暗号スイートと一致するものがあるかどうかがチェックされ、あった場合にのみ接続が確立されます。一致する暗号スイートがない場合、その接続はVDAにより拒否されます。
VDAは、GOV（ernment）、COM（mercial）、およびALLの3つの暗号の組み合わせ（コンプライアンスモードとも呼ばれます）をサポートします。確立できる暗号スイートは、WindowsのFIPSモードによっても異なります。WindowsのFIPSモードについては、http://support.microsoft.com/kb/811833を参照してください。次の表は、各セットの暗号の組み合わせを示しています：
| TLS/DTLS暗号の組み合わせ | ALL | COM | GOV | ALL | COM | GOV |
|---|---|---|---|---|---|---|
| FIPSモード | オフ | オフ | オフ | On | On | On |
| 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 |
* Windows Server 2012 R2ではサポートされていません。
注：
VDAでは、DHE暗号スイート（例：TLS_DHE_RSA_WITH_AES_256_GCM_SHA384、TLS_DHE_RSA_WITH_AES_256_CBC_SHA、TLS_DHE_RSA_WITH_AES_128_GCM_SHA256、TLS_DHE_RSA_WITH_AES_128_CBC_SHA）はサポートされません。これらの暗号スイートがWindowsで選択されても、Citrix Receiverでは使用できません。
Citrix Gatewayを使用している場合、バックエンド通信に対する暗号の組み合わせのサポートについては、Citrix ADCのドキュメントを参照してください。TLSがサポートする暗号の組み合わせについては、「Citrix ADCアプライアンスで利用可能な暗号」を参照してください。DTLSがサポートする暗号の組み合わせについては、「DTLS暗号サポート」を参照してください。
証明書の要求とインストール
- VDAで、MMCコンソールを開き、証明書スナップインを追加します。プロンプトが表示されたら、［コンピューターアカウント］を選択します。
- ［個人］>［証明書］ を展開し、コンテキストメニューコマンドの ［すべてのタスク］>［新しい証明書の要求］ を使用します。
- ［次へ］ をクリックして開始し、［次へ］ をクリックして、Active Directoryの登録から証明書を取得していることを確認します。
-
サーバー認証証明書のテンプレートを選択します。デフォルトのWindowsのComputerまたはWeb Server Exportableの両方が使用できます。［件名］の値が自動的に入力されるようにテンプレートが設定されている場合は、詳細を指定せずに ［登録］ をクリックできます。
-
証明書テンプレートの詳細情報を入力するには、［詳細］ をクリックし、次の項目を構成します：
サブジェクト名 — 種類は ［共通名］ を選択し、VDAの完全修飾ドメイン名を追加します。
代替名 — 種類は ［DNS］ を選択し、VDAの完全修飾ドメイン名を追加します。
注：
Active Directory証明書サービスの証明書の自動登録を使用して、VDAへの証明書の発行と展開を自動化します。これについては、https://support.citrix.com/article/CTX205473に説明があります。
ワイルドカード証明書を使用して、単一の証明書で複数のVDAを保護するように設定できます：
サブジェクト名 — 種類は ［共通名］ を選択し、VDAの「*.primary.domain」を入力します。
代替名 — 種類は ［DNS］ を選択し、VDAの「*.primary.domain」を追加します。
SAN証明書を使用して、単一の証明書で複数の指定のVDAを保護するように設定できます：
サブジェクト名 — 種類は ［共通名］ を選択し、証明書の使用方法を識別するのに役立つ文字列を入力します。
代替名 — 種類は ［DNS］ を選択し、各VDAの完全修飾ドメイン名を入力します。最適なTLSネゴシエーションを確保するために、代替名の数を最小限にします。
注：
ワイルドカード証明書とSAN証明書の両方で、［秘密キー］ タブの ［秘密キーをエクスポート可能にする］ をオンにする必要があります：
VDA上のTLS構成：PowerShellスクリプトの使用
証明書ストアの ［ローカルコンピューター］>［個人］>［証明書］ 領域にあるTLS証明書をインストールします。その場所に複数の証明書が存在する場合は、証明書の拇印をPowerShellスクリプトに指定します。
注：
PowerShellスクリプトは、XenAppおよびXenDesktop 7.16 LTSRから、VDAの完全修飾ドメイン名に基づいて正しい証明書を検索します。VDAの完全修飾ドメイン名に1つの証明書のみが存在する場合は、拇印を指定する必要はありません。
VDA上でEnable-VdaSSL.ps1スクリプトを実行すると、そのVDAでのTLSリスナーを有効または無効にできます。このスクリプトは、インストールメディアの Support > Tools > SslSupport フォルダーに収録されています。
TLSを有効にすると、DHEの暗号の組み合わせは無効になります。 ECDHEの暗号の組み合わせは影響を受けません。
TLSを有効にすると、スクリプトは指定されたTCPポートの既存のWindowsファイアウォール規則をすべて無効にします。その後、ICAサービスがTLS TCPおよびUDPポートでのみ着信接続を受け入れることを許可する新しい規則を追加します。また、スクリプトにより以下のWindowsファイアウォール規則が無効になります：
- Citrix ICA（デフォルトで1494）
- Citrix CGP（デフォルトで2598）
- Citrix WebSocket（デフォルトで8008）
ユーザーはTLSまたはDTLSを使用した場合にのみ接続できるようになります。TLSまたはDTLSを使用しないと、ICA/HDX、セッション画面を保持したICA/HDX、WebSocketを介したHDXを使用することはできません。
注：
DTLSは、ICA/HDXのUDPでのオーディオリアルタイムトランスポート、またはICA/HDX Framehawkではサポートされていません。
「ネットワークポート」を参照してください。
このスクリプト内には、以下の構文および使用例が記載されています。Notepad++などのツールを使用してこれらを参照できます。
重要：
EnableまたはDisableパラメーターとCertificateThumbPrintパラメーターを指定します。その他のパラメーターはオプションです。
構文
Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]
| パラメーター | 説明 |
|---|---|
| Enable | TLSリスナーをVDA上にインストールして有効にします。このパラメーターまたはDisableパラメーターのいずれかを指定する必要があります。 |
| Disable | VDA上のTLSリスナーを無効にします。このパラメーターまたはEnableパラメーターのいずれかを指定する必要があります。このパラメーターを指定した場合、ほかのパラメーターは無視されます。 |
| CertificateThumbPrint “ |
証明書ストア内のTLS証明書の拇印を二重引用符で囲んで指定します。スクリプトは、指定された拇印によって使用する証明書を選択します。このパラメーターを省略すると、不正な証明書が選択されます。 |
| SSLPort |
TLSポート指定します。デフォルト： 443 |
| SSLMinVersion “ |
許可されるTLSプロトコルの最低バージョンを二重引用符で囲んで指定します。有効な値：「TLS_1.0」（デフォルト）、「TLS_1.1」、「TLS_1.3」。 |
| SSLCipherSuite “ |
TLS暗号スイートを二重引用符で囲んで指定します。使用できる値は、「GOV」、「COM」、および「ALL」（デフォルト）です。 |
例
次のスクリプトでは、TLSプロトコルバージョン値をインストールして有効にします。拇印（この例の場合、「12345678987654321」）を指定して、使用する証明書を選択します。
Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
次のスクリプトでは、TLSリスナーをインストールして有効化し、TLSポートとして400、暗号スイートGOV、およびSSLプロトコルの最低バージョンとしてTLS 1.2を設定します。拇印（この例の場合、「12345678987654321」）を指定して、使用する証明書を選択します。
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.3"
-SSLCipherSuite "All"
次のスクリプトでは、VDA上のTLSリスナーを無効にします。
Enable-VdaSSL -Disable
VDA上のTLS構成：手作業による構成
VDA上のTLSを手作業で構成するには、TLS証明書の秘密キーに対する読み取り権限をVDA上のNT SERVICE\PorticaService（WindowsシングルセッションOS対応VDAの場合）またはNT SERVICE\TermService（WindowsマルチセッションOS対応VDAの場合）に付与します。VDAがインストールされたマシン上で、以下の手順を行います：
手順1：Microsoft管理コンソール（MMC）を起動します： ［スタート］>［ファイル名を指定して実行］> mmc.exe。
手順2：MMCに証明書スナップインを追加します。
- ［ファイル］>［スナップインの追加と削除］ の順に選択します。
- ［証明書］ を選択して ［追加］ をクリックします。
- ［このスナップインで管理する証明書］で［コンピューターアカウント］をクリックし、［次へ］をクリックします。
- ［このスナップインで管理するコンピューター］で［ローカルコンピューター］をクリックし、［完了］をクリックします。
手順3：コンソールツリーの ［証明書（ローカルコンピューター）］>［個人］>［証明書］ で証明書を右クリックして、［すべてのタスク］>［秘密キーの管理］ の順に選択します。
手順4：アクセス制御リストエディターで［（FriendlyName）プライベートキーのアクセス許可］ダイアログボックスが開きます。ここで（FriendlyName）は、TLS証明書の名前です。以下のいずれかのサービスを追加して、［読み取り］アクセスを許可します。
- WindowsシングルセッションOS対応VDAでは「PORTICASERVICE」
- WindowsマルチセッションOS対応VDAでは「TERMSERVICE」
手順5：インストールしたTLS証明書をダブルクリックします。［証明書］ダイアログボックスの ［詳細］ タブをクリックして、一番下までスクロールします。［拇印］ をクリックします。
手順6：regeditを実行して、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawdを開きます。
- SSL Thumbprintキーを編集して、TLS証明書の拇印の値をバイナリ値にコピーします。［バイナリ値の編集］ダイアログボックスでは、不明な項目（「0000」や特殊文字など）は無視して構いません。
- SSLEnabledキーを編集して、DWORD値を1に変更します（このDWORD値を0にするとSSLが無効になります）。
-
このレジストリパスでは、必要に応じて以下のデフォルト値を変更できます。
SSLPortのDWORD値 – SSLポート番号。デフォルト：443。
SSLMinVersionのDWORD値 – 1 = SSL 3.0、2 = TLS 1.0、3 = TLS 1.1、4 = TLS 1.3。デフォルト：2（TLS 1.0）。
SSLCipherSuiteのDWORD値 – 1 = GOV、2 = COM、3 = ALL。デフォルト：3（ALL）。
手順7：デフォルトの443以外のTLS TCPポートおよびUDPポートを使用する場合は、そのポートがWindowsファイアウォールで開放されていることを確認します（Windowsファイアウォールで受信規則を作成するときは、［接続を許可する］および［有効］が選択されていることを確認してください）。
手順8：ほかのアプリケーションやサービスなど（IISなど）がそのTLS TCPポートを使用していないことを確認します。
手順9：WindowsマルチセッションOS対応VDAの場合は、変更を適用するためのマシンを再起動します（WindowsシングルセッションOS対応VDAのマシンを再起動する必要はありません）。
重要：
VDAが、Windows Server 2012 R2、Windows Server 2016、Windows 10 Anniversary Edition、または以降のサポートリリースにインストールされている場合は、追加の手順が必要になります。これは、Citrix Receiver for Windows（バージョン4.6～4.9）、HTML5向けCitrix Workspaceアプリ、およびChrome向けCitrix Workspaceアプリからの接続に影響します。これには、Citrix Gatewayを使用した接続も含まれます。
この手順は、Citrix GatewayとVDA間のTLSが設定されている場合、すべてのVDAバージョンでCitrix Gatewayを使用するすべての接続にも必要です。これはCitrix Receiverのすべてのバージョンに影響します。
グループポリシーエディターを使用するVDA（Windows Server 2012 R2、Windows Server 2016、またはWindows 10 Anniversary Edition以降）上で、［コンピューターの構成］>［ポリシー］>［管理用テンプレート］>［ネットワーク］>［SSL構成設定］>［SSL暗号の順位］と移動します。以下の順に選択します：
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
注：
最初の6つの項目は、楕円曲線、P384、またはP256も指定します。［curve25519］が選択されていないことを確認します。 FIPSモードは、「curve25519」の使用を妨げません。
このグループポリシー設定が構成されると、VDAは、暗号の組み合わせを、グループポリシーの一覧と選択されたコンプライアンスモード（COM、GOVまたはALL）の一覧の両方に表示されている場合のみ選択します。また、暗号の組み合わせは、クライアント（Citrix WorkspaceアプリまたはStoreFront）が送信する一覧にも記載されている必要があります。
このグループポリシー構成は、VDA上の他のTLSアプリケーションおよびサービスにも影響します。アプリケーションが特定の暗号スイートを必要とする場合、このグループポリシーの一覧に追加する必要がある場合があります。
重要：
グループポリシーの変更が適用されたときに表示されても、TLS構成のグループポリシーの変更は、オペレーティングシステムの再起動後にのみ有効になります。したがって、プールデスクトップの場合、TLS構成のグループポリシーの変更は基本イメージに適用してください。
デリバリーグループのTLSの構成
TLS接続を構成したVDAを含んでいるすべてのデリバリーグループで、以下の手順を行います。
- StudioからPowerShellコンソールを開きます。
- asnp Citrix.*を実行してCitrix製品のコマンドレットをロードします。
- Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true を実行します。
- Set-BrokerSite -DnsResolutionEnabled $trueを実行します。
トラブルシューティング
接続エラーが発生した場合は、VDAのシステムイベントログを確認してください。
Windows向けCitrix WorkspaceアプリでTLS関連の接続エラーが発生した場合は、Desktop Viewerを無効にしてから接続を再試行してください。接続エラーは解決されないままでも、TLSの問題についての情報が表示される場合があります。たとえば、証明機関に証明書を要求したときに正しくないテンプレートを使用したなどがあります。
HDXアダプティブトランスポートを使用するほとんどの構成は、DTLSで正常に機能します（最新バージョンのCitrix Workspaceアプリ、Citrix Gateway、およびVDAを使用するDTLSなど）。 Citrix WorkspaceアプリとCitrix Gatewayとの間でDTLSを使用する構成、およびCitrix GatewayとVDAとの間でDTLSを使用する構成には、追加で操作が必要な場合があります。
次の場合は、追加で操作が必要になります。
- HDXアダプティブトランスポートおよびDTLSをサポートするCitrix Receiverバージョン：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）、またはReceiver for Linux（13.7）
および、次のいずれかにも該当する場合：
-
Citrix GatewayバージョンでVDAへのDTLSがサポートされていますが、VDAバージョンでDTLS（バージョン7.15以前）がサポートされていません。
-
VDAバージョンでDTLS（バージョン7.16以降）がサポートされていますが、Citrix GatewayバージョンでVDAへのDTLSがサポートされていません。
Citrix Receiverからの接続が失敗しないようにするには、次のいずれかを実行します。
- Citrix Receiverを、Receiver for Windows Version 4.10以降、Receiver for Mac 12.8以降、またはReceiver for iOS Version 7.5以降に更新します。または、
- Citrix Gatewayを、VDAへのDTLSをサポートしているバージョンに更新します。または、
- VDAをバージョン7.16以降に更新します。または、
- VDAでDTLSを無効にします。または、
- HDXアダプティブトランスポートを無効にします。
注：
Receiver for Linux用の適切な更新プログラムは、まだ利用できません。Receiver for Android（バージョン3.12.3）は、HDXアダプティブトランスポート、およびCitrix Gatewayを介したDTLSをサポートしていないため、影響を受けません。
VDAでDTLSを無効にするには、VDAファイアウォール構成を変更してUDPポート443を無効にします。 「ネットワークポート」を参照してください。
ControllerとVDAの間の通信
Windows Communication Framework（WCF）のメッセージレベルの保護によって、ControllerとVDAとの間の通信がセキュリティで保護されます。TLSを使用した追加の移送レベルの保護は必要ありません。WCF構成では、ControllerとVDA間の相互認証にKerberosが使用されます。暗号化には、CBCモードでのAESが256ビットキーで使用されます。メッセージの整合性にはSHA-1が使用されます。
Microsoftによると、WCFで使用されるセキュリティプロトコルは、WS-SecurityPolicy 1.2を含むOASIS（Organization for the Advancement of Structured Information Standards）による標準に準拠しています。 さらに、WCFは『Security Policy 1.2』に表記されているアルゴリズムスイートすべてをサポートしていることも明言されています。
ControllerとVDA間の通信には、上述のアルゴリズムによるbasic256アルゴリズムスイートが使用されます。
TLSおよびHTML5ビデオリダイレクション、およびブラウザーコンテンツリダイレクト
HTML5ビデオリダイレクションおよびブラウザーコンテンツリダイレクトを使用して、HTTPS Webサイトをリダイレクトできます。これらのWebサイトに挿入されたJavaScriptは、VDAで動作するCitrix HDX HTML5ビデオリダイレクトサービスへのTLS接続を確立する必要があります。これを達成するために、HTML5ビデオリダイレクトサービスはVDAの証明書ストアで2つのカスタム証明書を生成します。このサービスを停止すると、証明書が削除されます。
HTML5ビデオリダイレクションポリシーはデフォルトで無効になっています。
Webブラウザーコンテンツリダイレクトは、デフォルトで有効になっています。
HTML5ビデオリダイレクトについて詳しくは、「マルチメディアのポリシー設定」を参照してください。