トランスポート層セキュリティ (TLS)

最終公開日 : Nov 13, 2026
Citrix Virtual Apps and Desktops は、コンポーネント間の TCP ベースの接続にトランスポート層セキュリティ (TLS) プロトコルをサポートしています。Citrix Virtual Apps and Desktops は、(/ja-jp/citrix-virtual-apps-desktops/2402-ltsr/hdx-transport/adaptive-transport.html) を使用した UDP ベースの ICA/HDX 接続にデータグラムトランスポート層セキュリティ (DTLS) プロトコルもサポートしています。
TLS と DTLS は類似しており、同じデジタル証明書をサポートしています。Citrix Virtual Apps または Citrix Virtual Desktops™ サイトを TLS を使用するように構成すると、DTLS を使用するようにも構成されます。以下の手順を使用してください。特に記載がない限り、手順は TLS と DTLS の両方に共通です。
  • すべての Delivery Controller でサーバー証明書を取得、インストール、登録し、TLS 証明書でポートを構成します。詳細については、「Controller に TLS サーバー証明書をインストールする」を参照してください。
    オプションで、Controller が HTTP および HTTPS トラフィックをリッスンするために使用するポートを変更できます。
  • 次のタスクを完了して、Citrix Workspace™ アプリと Virtual Delivery Agent (VDA) 間の TLS 接続を有効にします。
    • VDA がインストールされているマシンで TLS を構成します。(便宜上、VDA がインストールされているマシンは、以降「VDA」と表記します。) 一般的な情報については、「VDA の TLS 設定」を参照してください。TLS/DTLS の構成には、Citrix が提供する PowerShell スクリプトを使用することを強くお勧めします。詳細については、「PowerShell スクリプトを使用して VDA で TLS を構成する」を参照してください。ただし、TLS/DTLS を手動で構成する場合は、「VDA で TLS を手動で構成する」を参照してください。
    • Studio で一連の PowerShell コマンドレットを実行して、VDA を含むデリバリーグループで TLS を構成します。詳細については、「デリバリーグループで TLS を構成する」を参照してください。
      要件と考慮事項:
      • ユーザーと VDA 間の TLS 接続の有効化は、XenApp 7.6 および XenDesktop 7.6 サイト、およびそれ以降のサポート対象リリースでのみ有効です。
      • コンポーネントのインストール、サイトの作成、マシンカタログの作成、およびデリバリーグループの作成後に、デリバリーグループと VDA で TLS を構成します。
      • デリバリーグループで TLS を構成するには、Controller アクセスルールを変更する権限が必要です。フル管理者にはこの権限があります。
      • VDA で TLS を構成するには、VDA がインストールされているマシンで Windows 管理者である必要があります。
      • Machine Creation Services™ または Provisioning Services によってプロビジョニングされたプールされた VDA では、再起動時に VDA マシンイメージがリセットされ、以前の TLS 設定が失われます。VDA が再起動されるたびに PowerShell スクリプトを実行して、TLS 設定を再構成してください。
警告:
Windows レジストリを操作するタスクの場合、レジストリを誤って編集すると、オペレーティングシステムの再インストールが必要になるような深刻な問題が発生する可能性があります。Citrix® は、レジストリエディターの誤った使用によって生じる問題が解決できることを保証できません。レジストリエディターは自己責任で使用してください。編集する前に必ずレジストリをバックアップしてください。
サイトデータベースへの TLS の有効化については、「CTX137556」を参照してください。
Related information
セキュリティ
Delivery Controller で TLS を有効にするWeb StudioとDirectorでTLSを有効にするユニバーサルプリントサーバーでのトランスポート層セキュリティ (TLS)

コントローラーにTLSサーバー証明書をインストールする

HTTPSの場合、XMLサービスはクライアント証明書ではなくサーバー証明書を使用してTLS機能をサポートします。このセクションでは、Delivery ControllerでのTLS証明書の取得とインストールについて説明します。同じ手順をCloud Connectorに適用して、STAおよびXMLトラフィックを暗号化できます。
さまざまな種類の証明機関と、そこから証明書を要求する方法がありますが、この記事ではMicrosoft証明機関について説明します。Microsoft証明機関は、サーバー認証の目的で公開された証明書テンプレートを持っている必要があります。
Microsoft証明機関がActive Directoryドメイン、またはDelivery Controllerが参加している信頼されたフォレストに統合されている場合、証明書MMCスナップインの証明書登録ウィザードから証明書を取得できます。

証明書の要求とインストール

  1. Delivery Controller™で、MMCコンソールを開き、証明書スナップインを追加します。プロンプトが表示されたら、コンピューターアカウントを選択します。
  2. 個人 > 証明書を展開し、すべてのタスク > 新しい証明書の要求コンテキストメニューコマンドを使用します。
    MMC証明書スナップイン
  3. 開始するには次へをクリックし、Active Directory登録から証明書を取得することを確認するには次へをクリックします。
  4. サーバー認証証明書のテンプレートを選択します。テンプレートがSubjectの値を自動的に提供するように設定されている場合は、詳細を指定せずにEnrollをクリックできます。
    証明書要求ダイアログ
  5. 証明書テンプレートの詳細を指定するには、詳細矢印ボタンをクリックして、以下を構成します。
    Subject name: Common Nameを選択し、Delivery ControllerのFQDNを追加します。
    Alternative name: DNSを選択し、Delivery ControllerのFQDNを追加します。
    証明書のプロパティ

SSL/TLSリスナーポートの構成

  1. マシンの管理者としてPowerShellコマンドウィンドウを開きます。
  2. Broker Serviceアプリケーション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
  3. 以前にインストールした証明書のサムプリントを取得するには、同じ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
  4. 同じPowerShellウィンドウで、Broker Serviceの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
正しく構成されている場合、最後のコマンド .netsh http show sslcert の出力は、リスナーが正しい IP:port を使用しており、Application ID がBroker Serviceアプリケーション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_ の暗号スイートよりも前に配置する必要があります。
  1. Microsoftグループポリシーエディターを使用して、コンピューターの構成 > 管理用テンプレート > ネットワーク > SSL構成設定 に移動します。
  2. 「SSL暗号スイートの順序」ポリシーを編集します。デフォルトでは、このポリシーは「未構成」に設定されています。このポリシーを「有効」に設定します。
  3. スイートを正しい順序に並べ替えます。使用したくない暗号スイートは削除します。
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 または TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 のいずれかが、TLS_DHE_ の暗号スイートよりも前に配置されていることを確認してください。
Microsoft MSDNで、「Schannel暗号スイートの優先順位付け」も参照してください。

HTTPまたはHTTPSポートの変更

デフォルトでは、Controller 上の 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

HTTPS トラフィックのみを強制する

XML Service で HTTP トラフィックを無視させたい場合は、Controller 上の HKLM\Software\Citrix\DesktopServer\ に次のレジストリ設定を作成し、Broker Service を再起動します。
HTTP トラフィックを無視するには、DWORD XmlServicesEnableNonSsl を作成し、0 に設定します。
HTTPS トラフィックを無視するために作成できる対応するレジストリ DWORD 値があります: DWORD XmlServicesEnableSsl。これが 0 に設定されていないことを確認してください。

VDA 上の TLS 設定

デリバリーグループには、TLS が構成されている VDA と TLS が構成されていない VDA が混在することはできません。デリバリーグループに TLS を構成する前に、そのデリバリーグループ内のすべての VDA に TLS が構成されていることを確認してください。
VDA で TLS を構成すると、インストールされている TLS 証明書のアクセス許可が変更され、ICA® Service に証明書の秘密キーへの読み取りアクセス権が付与され、ICA Service に次の情報が通知されます。
  • TLS に使用する証明書ストア内の証明書。
  • TLS 接続に使用する TCP ポート番号。
    Windows ファイアウォール（有効な場合）は、この TCP ポートでの受信接続を許可するように構成する必要があります。この構成は、PowerShell スクリプトを使用すると自動的に行われます。
  • 許可する TLS プロトコルのバージョン。
    重要:
    Citrix は、SSLv3 の使用状況を確認し、必要に応じて SSLv3 のサポートを削除するように展開を再構成することを推奨します。CTX200238を参照してください。
    サポートされている TLS プロトコルバージョンは、階層（最低から最高）に従います: SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、および TLS 1.3。許可される最小バージョンを指定します。そのバージョンまたはそれより高いバージョンを使用するすべてのプロトコル接続が許可されます。
    たとえば、TLS 1.1 を最小バージョンとして指定した場合、TLS 1.1 および TLS 1.3 プロトコル接続が許可されます。SSL 3.0 を最小バージョンとして指定した場合、サポートされているすべてのバージョンの接続が許可されます。TLS 1.3 を最小バージョンとして指定した場合、TLS 1.3 接続のみが許可されます。
    DTLS 1.0 は TLS 1.1 に対応し、DTLS 1.3 は TLS 1.3 に対応します。
  • 許可する TLS 暗号スイート。
    暗号スイートは、接続に使用される暗号化を選択します。クライアントと VDA は、異なる暗号スイートのセットをサポートできます。クライアント（Citrix Workspace アプリまたは StoreFront）が接続し、サポートされている TLS 暗号スイートのリストを送信すると、VDA はクライアントの暗号スイートのいずれかを、自身の構成済み暗号スイートのリストにある暗号スイートのいずれかと照合し、接続を受け入れます。一致する暗号スイートがない場合、VDA は接続を拒否します。
    VDA は、3 つの暗号スイートセット（コンプライアンスモードとも呼ばれます）をサポートしています: GOV（政府）、COM（商用）、および ALL。許容される暗号スイートは、Windows FIPS モードにも依存します。Windows FIPS モードの詳細については、<http://support.microsoft.com/kb/811833>を参照してください。次の表に、各セットの暗号スイートを示します。
TLS/DTLS 暗号スイート ALL COM GOV ALL COM GOV
FIPS モード オフ オフ オフ オン オン オン
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によって選択された場合でも、Receiverでは使用できない場合があります。
Citrix Gatewayを使用している場合は、バックエンド通信の暗号スイートサポートに関する情報について、Citrix ADCのドキュメントを参照してください。TLS暗号スイートのサポートについては、「Citrix ADCアプライアンスで利用可能な暗号」を参照してください。DTLS暗号スイートのサポートについては、「DTLS暗号のサポート」を参照してください。

証明書を要求してインストールする

  1. VDAで、MMCコンソールを開き、証明書スナップインを追加します。プロンプトが表示されたら、コンピューターアカウントを選択します。
  2. 個人 > 証明書を展開し、コンテキストメニューコマンドすべてのタスク > 新しい証明書の要求を使用します。
  3. 「次へ」をクリックして開始し、Active Directory登録から証明書を取得することを確認するために「次へ」をクリックします。
  4. サーバー認証証明書のテンプレートを選択します。デフォルトのWindows ComputerまたはWeb Server Exportableのどちらも使用できます。テンプレートがSubjectの値を自動的に提供するように設定されている場合は、詳細情報を提供せずに「登録」をクリックできます。
    「証明書を要求」ダイアログ(/en-us/citrix-virtual-apps-desktops/2402-ltsr/media/tls-request-certificates.png)
  5. 証明書テンプレートの詳細情報を提供するには、「詳細」をクリックして、以下を構成します。
    サブジェクト名 — 種類を「共通名」に選択し、VDAのFQDNを追加します
    代替名 — 種類を「DNS」に選択し、VDAのFQDNを追加します
    証明書のプロパティ(/en-us/citrix-virtual-apps-desktops/2402-ltsr/media/tls-certificate-properties.png)
    注：
    Active Directory証明書サービス証明書の自動登録を使用して、VDAへの証明書の発行と展開を自動化します。これについては、<https://support.citrix.com/article/CTX205473>で説明されています。
    ワイルドカード証明書を使用して、単一の証明書で複数のVDAを保護できます。
    サブジェクト名 — 種類を「共通名」に選択し、VDAの*.primary.domainを入力します
    代替名 — 種類を「DNS」に選択し、VDAの*.primary.domainを追加します
    ワイルドカード証明書要求ダイアログ(/en-us/citrix-virtual-apps-desktops/2402-ltsr/media/tls-request-certificates-wildcard.png)
    SAN証明書を使用して、単一の証明書で複数の特定のVDAを保護できます。
    サブジェクト名 — 種類を「共通名」に選択し、証明書の使用状況を識別するのに役立つ文字列を入力します
    代替名 — 種類を「DNS」に選択し、各VDAのFQDNのエントリを追加します。最適なTLSネゴシエーションを確保するために、代替名の数を最小限に抑えてください。
    「証明書を要求」ダイアログ(/en-us/citrix-virtual-apps-desktops/2402-ltsr/media/tls-request-certificates-san.png)
    注：
    ワイルドカード証明書とSAN証明書の両方で、タブの秘密キーをエクスポート可能にするが選択されている必要があります。
    「証明書を要求」ダイアログ(/en-us/citrix-virtual-apps-desktops/2402-ltsr/media/tls-certificate-properties-private-key.png)

PowerShellスクリプトを使用してVDAでTLSを構成する

証明書ストアの > > 領域にTLS証明書をインストールします。その場所に複数の証明書がある場合は、証明書のサムプリントをPowerShellスクリプトに指定します。
注：
XenApp and XenDesktop 7.16 LTSR以降、PowerShellスクリプトはVDAのFQDNに基づいて正しい証明書を検索します。VDAのFQDNに対して単一の証明書のみが存在する場合、サムプリントを指定する必要はありません。
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は、UDPリアルタイムトランスポート経由のICA/HDXオーディオ、またはICA/HDX Framehawkではサポートされていません。
ネットワークポートを参照してください。
スクリプトには、以下の構文の説明と追加の例が含まれています。この情報はNotepad++などのツールを使用して確認できます。
重要:
EnableまたはDisableパラメーターと、CertificateThumbPrintパラメーターのいずれかを指定します。その他のパラメーターはオプションです。

構文

Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]
パラメーター 説明
有効にする VDAにTLSリスナーをインストールして有効にします。このパラメーターまたはDisableパラメーターのいずれかが必要です。
無効にする VDA上のTLSリスナーを無効にします。このパラメーターまたはEnableパラメーターのいずれかが必要です。このパラメーターを指定した場合、他のパラメーターは無効になります。
証明書のサムプリント "<thumbprint>" 証明書ストア内のTLS証明書のサムプリントを引用符で囲んで指定します。スクリプトは指定されたサムプリントを使用して、使用する証明書を選択します。このパラメーターを省略すると、誤った証明書が選択されます。
SSLポート <port> 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暗号スイート、および最小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を手動で構成する場合、各VDAの適切なサービスに対して、TLS証明書の秘密キーへの一般的な読み取りアクセス権を付与します。WindowsシングルセッションOS用VDAの場合はNT SERVICE\PorticaService、WindowsマルチセッションOS用VDAの場合はNT SERVICE\TermServiceです。VDAがインストールされているマシンで、次の手順を実行します。
手順 1. Microsoft管理コンソール（MMC）を起動します: スタート > ファイル名を指定して実行 > mmc.exe。
手順 2. MMCに証明書スナップインを追加します。
  1. ファイル > スナップインの追加と削除 を選択します。
  2. 証明書 を選択し、追加 をクリックします。
  3. 「このスナップインで常に管理する証明書は次のとおりです:」というプロンプトが表示されたら、「コンピューターアカウント」を選択し、次へ をクリックします。
  4. 「このスナップインで管理するコンピューターを選択してください」というプロンプトが表示されたら、「ローカルコンピューター」を選択し、完了 をクリックします。
手順 3. 証明書 (ローカルコンピューター) > 個人 > 証明書 の下で、証明書を右クリックし、すべてのタスク > 秘密キーの管理 を選択します。
手順 4. アクセス制御リストエディターに「(FriendlyName) の秘密キーのアクセス許可」が表示されます。(FriendlyName) はTLS証明書の名前です。次のいずれかのサービスを追加し、読み取りアクセス権を付与します。
  • WindowsシングルセッションOS用VDAの場合、「PORTICASERVICE」
  • WindowsマルチセッションOS用VDAの場合、「TERMSERVICE」
ステップ5. インストールされているTLS証明書をダブルクリックします。証明書ダイアログで、タブを選択し、一番下までスクロールします。をクリックします。
ステップ6. regeditを実行し、HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawdに移動します。
  1. SSL Thumbprintキーを編集し、TLS証明書の拇印の値をこのバイナリ値にコピーします。ダイアログボックスの不明な項目（「0000」や特殊文字など）は無視しても問題ありません。
  2. SSLEnabledキーを編集し、DWORD値を1に変更します。(後でSSLを無効にするには、DWORD値を0に変更します。)
  3. デフォルト設定を変更する場合（オプション）は、同じレジストリパスで以下を使用します。
    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. TLSのTCPポートとUDPポートがデフォルトの443でない場合、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)、Citrix Workspace app for HTML5、およびCitrix Workspace app for Chromeからの接続に影響します。Citrix Gatewayを使用する接続も含まれます。
この手順は、Citrix GatewayとVDA間のTLSが構成されている場合、すべてのVDAバージョンでCitrix Gatewayを使用するすべての接続にも必要です。これは、すべてのCitrix Receiver™バージョンに影響します。
VDA (Windows Server 2012 R2、Windows Server 2016、またはWindows 10 Anniversary Edition以降) で、グループポリシーエディターを使用して、 > > > > > に移動します。次の順序を選択します。
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を含む各デリバリーグループに対して、この手順を完了します。
  1. StudioからPowerShellコンソールを開きます。
  2. Citrix製品のコマンドレットを読み込むには、**asnp Citrix.***を実行します。
  3. Get-BrokerAccessPolicyRule -DesktopGroupName '\<delivery-group-name>' \| Set-BrokerAccessPolicyRule -HdxSslEnabled $trueを実行します。
  4. Set-BrokerSite -DnsResolutionEnabled $trueを実行します。

トラブルシューティング

接続エラーが発生した場合は、VDAのシステムイベントログを確認してください。
Windows版Citrix Workspaceアプリを使用しているときに、TLSエラーを示す接続エラーが表示された場合は、Desktop Viewerを無効にしてから、もう一度接続を試してください。接続は引き続き失敗しますが、基になるTLS問題の説明が提供される場合があります。（例：証明機関に証明書を要求する際に、誤ったテンプレートを指定しました。）
HDX™ Adaptive Transportを使用するほとんどの構成は、Citrix Workspaceアプリ、Citrix Gateway、およびVDAの最新バージョンを使用するものを含め、DTLSで正常に動作します。Citrix WorkspaceアプリとCitrix Gateway間、およびCitrix GatewayとVDA間でDTLSを使用する一部の構成では、追加の操作が必要です。
次の場合、追加の操作が必要です。
  • Citrix ReceiverのバージョンがHDX Adaptive TransportおよびDTLSをサポートしている場合：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 バージョン 4.10 以降、Receiver for Mac 12.8 以降、または Receiver for iOS バージョン 7.5 以降に更新する。
  • Citrix Gateway を、VDA への DTLS をサポートするバージョンに更新する。
  • VDA をバージョン 7.16 以降に更新する。
  • VDA で DTLS を無効にする。
  • HDX Adaptive Transport を無効にする。
注：
Receiver for Linux の適切な更新はまだ利用できません。Receiver for Android（バージョン 3.12.3）は、HDX Adaptive Transport および Citrix Gateway 経由の DTLS をサポートしていないため、影響を受けません。
VDA で DTLS を無効にするには、VDA ファイアウォール構成を変更して UDP ポート 443 を無効にします。詳細については、「ネットワークポート」を参照してください。

Controller と VDA 間の通信

Windows Communication Framework (WCF) のメッセージレベル保護により、Controller と VDA 間の通信が保護されます。TLS を使用した追加のトランスポートレベル保護は必要ありません。WCF 構成では、Controller と VDA 間の相互認証に Kerberos を使用します。暗号化には 256 ビットキーの CBC モードで AES を使用します。メッセージの整合性には SHA-1 を使用します。
Microsoft によると、WCF で使用されるセキュリティプロトコルは、WS-SecurityPolicy 1.2 を含む OASIS (Organization for the Advancement of Structured Information Standards) の標準に準拠しています。さらに、Microsoft は、WCF がSecurity Policy 1.2に記載されているすべてのアルゴリズムスイートをサポートしていると述べています。
Controller と VDA 間の通信には basic256 アルゴリズムスイートが使用され、そのアルゴリズムは上記のとおりです。

TLS と HTML5 ビデオリダイレクト、およびブラウザコンテンツリダイレクト

HTML5 ビデオリダイレクトとブラウザコンテンツリダイレクトを使用して、HTTPS Web サイトをリダイレクトできます。これらの Web サイトに挿入された JavaScript は、VDA で実行されている Citrix HDX HTML5 ビデオリダイレクトサービスへの TLS 接続を確立する必要があります。これを実現するために、HTML5 ビデオリダイレクトサービスは、VDA 上の証明書ストアに 2 つのカスタム証明書を生成します。サービスを停止すると、証明書は削除されます。
HTML5 ビデオリダイレクトポリシーは、デフォルトで無効になっています。
ブラウザコンテンツリダイレクトは、デフォルトで有効になっています。
HTML5 ビデオリダイレクトの詳細については、マルチメディアポリシー設定を参照してください。