製品ドキュメント
Citrix Virtual Apps and Desktops
Current Release Service 2511 2507 LTSR 2503 2411 2407 2402 LTSR 2311 2203 LTSR
PDFを表示

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

May 31, 2026
寄稿者: 
C C

Citrix Virtual Apps and Desktopsは、コンポーネント間のTCPベースの接続にトランスポート層セキュリティ (TLS) プロトコルをサポートしています。Citrix Virtual Apps and Desktopsは、アダプティブトランスポートを使用して、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を参照してください。

ControllerへのTLSサーバー証明書のインストール

HTTPSの場合、XML Serviceはクライアント証明書ではなく、サーバー証明書を使用して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. サーバー認証証明書のテンプレートを選択します。テンプレートがサブジェクトの値を自動的に提供するように設定されている場合は、詳細を指定せずに登録をクリックできます。

    証明書要求ダイアログ

  5. 証明書テンプレートのさらに詳細な情報を提供するには、詳細矢印ボタンをクリックして、以下を構成します。

    サブジェクト名: 共通名を選択し、Delivery ControllerのFQDNを追加します。

    代替名：DNSを選択し、デリバリーコントローラーの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
<!--NeedCopy-->

  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
<!--NeedCopy-->

  4. Broker ServiceのSSL/TLSポートを構成し、暗号化に証明書を使用するには、同じPowerShellウィンドウで次のコマンドを実行します。

    $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が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 Cipher Suite Order」ポリシーを編集します。デフォルトでは、このポリシーは「Not Configured」に設定されています。このポリシーを「Enabled」に設定します。
  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サービスは、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トラフィックのみを強制する

XMLサービスが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がすでに構成されていることを確認してください。

VDAsでTLSを構成すると、インストールされているTLS証明書の権限が変更され、ICA®サービスに証明書の秘密キーへの読み取りアクセス権が付与され、ICAサービスに次の情報が通知されます。

  • 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はクライアントの暗号スイートの1つを、自身の構成済み暗号スイートのリストにある暗号スイートの1つと照合し、接続を受け入れます。一致する暗号スイートがない場合、VDAは接続を拒否します。

    VDAは、3つの暗号スイートセット（コンプライアンスモードとも呼ばれます）をサポートしています：GOV（政府）、COM（商用）、およびALL。許容される暗号スイートはWindows FIPSモードにも依存します。Windows FIPSモードの詳細については、http://support.microsoft.com/kb/811833を参照してください。次の表に、各セットの暗号スイートを示します。

TLS/DTLS暗号スイート ALL COM GOV ALL COM GOV
フィップスモード オフ オフ オフ オン オン オン
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のコンピューターまたはWebサーバー（エクスポート可能）のどちらも使用できます。テンプレートがサブジェクトの値を自動的に提供するように設定されている場合は、詳細を指定せずに登録をクリックできます。

    証明書の要求ダイアログ

  5. 証明書テンプレートの詳細を指定するには、詳細をクリックして以下を構成します。

    サブジェクト名 — 種類として共通名を選択し、VDAのFQDNを追加します。

    代替名 — 種類としてDNSを選択し、VDAのFQDNを追加します。

    証明書のプロパティ

    注：

    Active Directory証明書サービス証明書の自動登録を使用して、VDAへの証明書の発行と展開を自動化します。これについては、https://support.citrix.com/article/CTX205473で説明されています。

    ワイルドカード証明書を使用して、単一の証明書で複数のVDAを保護できます。

    サブジェクト名 — 種類として共通名を選択し、VDAの*.primary.domainを入力します。

    代替名 — タイプDNSを選択し、VDAの*.primary.domainを追加します

    証明書要求ワイルドカードダイアログ

    SAN証明書を使用すると、1つの証明書で複数の特定のVDAを保護できます。

    サブジェクト名 — タイプ共通名を選択し、証明書の使用状況を識別するのに役立つ文字列を入力します

    代替名 — タイプDNSを選択し、各VDAのFQDNのエントリを追加します。最適なTLSネゴシエーションを確保するために、代替名の数を最小限に抑えてください。

    証明書要求ダイアログ

    注：

    ワイルドカード証明書とSAN証明書の両方で、秘密キーのタブで秘密キーをエクスポート可能にするを選択する必要があります。

    証明書要求ダイアログ

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

TLS証明書を証明書ストアの「ローカルコンピューター > 個人 > 証明書」領域にインストールします。その場所に複数の証明書がある場合は、証明書のサムプリントをPowerShellスクリプトに指定します。

注：

XenAppおよび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です)
  • シトリックス CGP (デフォルト: 2598)
  • シトリックス ウェブソケット (デフォルト: 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パラメーターのいずれかが必要です。このパラメーターを指定した場合、他のパラメーターは無効です。
証明書サムプリント “" 引用符で囲まれた、証明書ストア内の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暗号スイート、および最小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上の適切なサービス（WindowsシングルセッションOS用VDAの場合はNT SERVICE\PorticaService、WindowsマルチセッションOS用VDAの場合はNT SERVICE\TermService）のTLS証明書の秘密キーに一般的な読み取りアクセス権を付与します。VDAがインストールされているマシンで、次の手順を実行します。

手順1。Microsoft管理コンソール（MMC）を起動します: [スタート] > [ファイル名を指定して実行] > mmc.exe。

手順2。MMCに証明書スナップインを追加します。

  1. [ファイル] > [スナップインの追加と削除] を選択します。
  2. [証明書] を選択し、[追加] をクリックします。
  3. 「このスナップインは常に次の証明書を管理します:」というプロンプトが表示されたら、「コンピューターアカウント」を選択し、[次へ] をクリックします。
  4. 「このスナップインで管理するコンピューターを選択してください」というプロンプトが表示されたら、「ローカルコンピューター」を選択し、[完了] をクリックします。

手順3。[証明書（ローカルコンピューター）] > [個人] > [証明書] で、証明書を右クリックし、[すべてのタスク] > [秘密キーの管理] を選択します。

手順4。アクセス制御リストエディターに「(FriendlyName)の秘密キーのアクセス許可」が表示されます。(FriendlyName)はTLS証明書の名前です。次のいずれかのサービスを追加し、読み取りアクセス権を付与します。

  • ウィンドウズシングルセッションOS向けVDAの場合、「PORTICASERVICE」
  • ウィンドウズマルチセッションOS向けVDAの場合、「TERMSERVICE」

手順5。インストールされているTLS証明書をダブルクリックします。証明書ダイアログで、[詳細] タブを選択し、一番下までスクロールします。[拇印] をクリックします。

STEP 6. Run regedit and go to 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. Default: 2 (TLS 1.0).

    SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Default: 3 (ALL).

手順7. TLSのTCPおよびUDPポートがデフォルトの443でない場合、Windowsファイアウォールで開いていることを確認します。（Windowsファイアウォールで受信規則を作成する際は、そのプロパティで「接続を許可する」と「有効」のエントリが選択されていることを確認してください。）

手順8. 他のアプリケーションやサービス（IISなど）がTLS TCPポートを使用していないことを確認します。

手順9. WindowsマルチセッションOS用VDAの場合、変更を有効にするためにマシンを再起動します。（WindowsシングルセッションOS用VDAを含むマシンを再起動する必要はありません。）

重要:

An extra step is necessary when the VDA is on Windows Server 2012 R2, Windows Server 2016, or Windows 10 Anniversary Edition or later supported release. This affects connections from Citrix Receiver for Windows (version 4.6 through 4.9), Citrix Workspace app for HTML5, and Citrix Workspace app for Chrome. This also includes connections using 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を含む各デリバリーグループに対して、この手順を完了してください。

  1. StudioからPowerShellコンソールを開きます。
  2. Citrix製品のコマンドレットをロードするには、asnp Citrix.* を実行します。
  3. Run Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
  4. Run 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の間でDTLSを使用し、Citrix GatewayとVDAの間でDTLSを使用する一部の構成では、追加の操作が必要です。

次の場合、追加の操作が必要です。

  • Citrix ReceiverのバージョンがHDX Adaptive TransportおよびDTLSをサポートしていること: Windows版 レシーバー （4.7、4.8、4.9）、Mac版 レシーバー （12.5、12.6、12.7）、iOS版 レシーバー （7.2、7.3.x） または Linux版 レシーバー （13.7）

さらに、以下のいずれかに該当する場合:

  • Citrix GatewayのバージョンがVDAへのDTLSをサポートしているが、VDAのバージョンがDTLSをサポートしていない場合（バージョン7.15以前）、

  • VDAのバージョンがDTLSをサポートしているが（バージョン7.16以降）、Citrix GatewayのバージョンがVDAへのDTLSをサポートしていない場合。

Citrix Receiverからの接続が失敗するのを避けるには、以下のいずれかを実行してください。

  • Citrix Receiver を、Windows版 レシーバー バージョン 4.10 以降、Mac版 レシーバー 12.8 以降、または iOS版 レシーバー バージョン 7.5 以降に更新する。または、
  • Citrix Gatewayを、VDAへのDTLSをサポートするバージョンに更新する。または、
  • VDAをバージョン7.16以降に更新する。または、
  • VDAでDTLSを無効にする。または、
  • HDX アダプティブ トランスポート を無効にする。

注：

Receiver for Linuxの適切なアップデートはまだ利用できません。Receiver for Android（バージョン3.12.3）は、Citrix Gateway経由のHDX Adaptive TransportおよびDTLSをサポートしていないため、影響を受けません。

VDAでDTLSを無効にするには、VDAファイアウォール構成を変更してUDPポート443を無効にします。「ネットワークポート」を参照してください。

コントローラーとVDA間の通信

Windows Communication Framework (WCF) のメッセージレベル保護により、ControllerとVDA間の通信が保護されます。TLSを使用した追加のトランスポートレベル保護は必要ありません。WCF構成は、ControllerとVDA間の相互認証にKerberosを使用します。暗号化には256ビットキーのCBCモードAESを使用します。メッセージの整合性にはSHA-1を使用します。

マイクロソフトによると、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ビデオリダイレクトポリシーは、デフォルトで無効になっています。

ブラウザコンテンツリダイレクトは、デフォルトで有効になっています。

HTML5ビデオリダイレクトの詳細については、マルチメディアポリシー設定を参照してください。

トランスポート層セキュリティ (TLS)
May 31, 2026
寄稿者: 
C C
May 31, 2026
寄稿者: 
C C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.