Citrix Virtual Apps and Desktops

Transport Layer Security (TLS)

January 23, 2026

Contribuição de:

O Citrix Virtual Apps and Desktops oferece suporte ao protocolo Transport Layer Security (TLS) para conexões baseadas em TCP entre componentes. O Citrix Virtual Apps and Desktops também oferece suporte ao protocolo Datagram Transport Layer Security (DTLS) para conexões ICA/HDX baseadas em UDP, usando transporte adaptável.

TLS e DTLS são semelhantes e oferecem suporte aos mesmos certificados digitais. A configuração de um Site do Citrix Virtual Apps ou Citrix Virtual Desktops™ para usar TLS também o configura para usar DTLS. Use os procedimentos a seguir; as etapas são comuns a TLS e DTLS, exceto onde indicado:

Obtenha, instale e registre um certificado de servidor em todos os Delivery Controllers e configure uma porta com o certificado TLS. Para obter detalhes, consulte Instalar certificados de servidor TLS nos Controllers.

Opcionalmente, você pode alterar as portas que o Controller usa para escutar o tráfego HTTP e HTTPS.
Habilite as conexões TLS entre o aplicativo Citrix Workspace™ e os Virtual Delivery Agents (VDAs) concluindo as seguintes tarefas:
- Configure o TLS nas máquinas onde os VDAs estão instalados. (Para sua conveniência, referências futuras a máquinas onde os VDAs estão instalados são simplesmente chamadas de “VDAs”.) Para obter informações gerais, consulte Configurações de TLS em VDAs. É altamente recomendável que você use o script PowerShell fornecido pela Citrix para configurar TLS/DTLS. Para obter detalhes, consulte Configurar TLS em um VDA usando o script PowerShell. No entanto, se você quiser configurar TLS/DTLS manualmente, consulte Configurar TLS manualmente em um VDA.
- Configure o TLS nos Delivery Groups que contêm os VDAs executando um conjunto de cmdlets PowerShell no Studio. Para obter detalhes, consulte Configurar TLS em Delivery Groups.
  
  Requisitos e considerações:
  - A habilitação de conexões TLS entre usuários e VDAs é válida apenas para Sites XenApp 7.6 e XenDesktop 7.6, além de versões posteriores compatíveis.
  - Configure o TLS nos Delivery Groups e nos VDAs depois de instalar os componentes, criar um Site, criar catálogos de máquinas e criar Delivery Groups.
  - Para configurar o TLS nos Delivery Groups, você deve ter permissão para alterar as regras de acesso do Controller. Um Administrador Completo tem essa permissão.
  - Para configurar o TLS nos VDAs, você deve ser um administrador do Windows na máquina onde o VDA está instalado.
  - Em VDAs agrupados que são provisionados pelo Machine Creation Services™ ou Provisioning Services, a imagem da máquina VDA é redefinida na reinicialização, fazendo com que as configurações TLS anteriores sejam perdidas. Execute o script PowerShell cada vez que o VDA for reiniciado para reconfigurar as configurações TLS.

Aviso:

Para tarefas que incluem trabalhar no Registro do Windows — editar o Registro incorretamente pode causar sérios problemas que podem exigir a reinstalação do sistema operacional. A Citrix® não pode garantir que os problemas resultantes do uso incorreto do Editor do Registro possam ser resolvidos. Use o Editor do Registro por sua conta e risco. Certifique-se de fazer backup do Registro antes de editá-lo.

Para obter informações sobre como habilitar o TLS para o banco de dados do Site, consulte CTX137556.

Instalar certificados de servidor TLS nos Controllers

Para HTTPS, o XML Service oferece suporte a recursos TLS usando certificados de servidor, não certificados de cliente. Esta seção descreve a aquisição e instalação de certificados TLS em Delivery Controllers. As mesmas etapas podem ser aplicadas a Cloud Connectors para criptografar o tráfego STA e XML.

Embora existam vários tipos diferentes de autoridades de certificação e métodos para solicitar certificados delas, este artigo descreve a Autoridade de Certificação da Microsoft. A Autoridade de Certificação da Microsoft precisa ter um modelo de certificado publicado com a finalidade de Autenticação de Servidor.

Se a Autoridade de Certificação da Microsoft estiver integrada a um domínio do Active Directory ou à floresta confiável à qual os Delivery Controllers estão unidos, você poderá adquirir um certificado do assistente de Registro de Certificados do snap-in MMC.

Solicitar e instalar um certificado

No Delivery Controller™, abra o console MMC e adicione o snap-in “Certificados”. Quando solicitado, selecione “Conta de computador”.
Expanda Pessoal > Certificados e use o comando do menu de contexto Todas as Tarefas > Solicitar Novo Certificado.
Clique em Avançar para iniciar e em Avançar para confirmar que você está adquirindo o certificado do registro do Active Directory.
Selecione o modelo para o certificado de Autenticação de Servidor. Se o modelo tiver sido configurado para fornecer automaticamente os valores para “Assunto”, você pode clicar em Registrar sem fornecer mais detalhes.
Para fornecer mais detalhes para o modelo de certificado, clique no botão de seta Detalhes e configure o seguinte:

Nome do assunto: selecione “Nome Comum” e adicione o FQDN do Delivery Controller.

Nome alternativo: selecione “DNS” e adicione o FQDN do Delivery Controller.

Configurar a porta de escuta SSL/TLS

Se o componente IIS do Windows estiver instalado no mesmo servidor, que é instalado como parte do Web Studio e do Director, você pode configurar o TLS usando o IIS. Para obter mais informações, consulte Habilitar TLS no Web Studio e Director. Caso contrário, para configurar o certificado usando o PowerShell:

Para verificar se há um certificado existente vinculado, abra um prompt de comando e execute netsh http show sslcert:
```
netsh http show sslcert

```
Se houver um vínculo existente, exclua-o.
```
netsh http delete sslcert ipport=0.0.0.0:443

```
Substituindo 0.0.0.0:443 por um endereço IP e porta específicos, se houver um especificado no vínculo existente.
Encontre o thumbprint do certificado que você instalou anteriormente. Para visualizar o thumbprint, abra Gerenciar certificados do computador, navegue até o certificado, abra-o e vá para a guia Detalhes.

Alternativamente, você pode usar o PowerShell. Por exemplo, o script a seguir procura um certificado cujo nome comum corresponde ao nome do host do servidor e imprime o thumbprint:
```
$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

```
Se o nome comum do certificado não corresponder aos nomes de host, isso falhará. Se houver vários certificados para o nome do host, isso retornará vários thumbprints concatenados e você deverá escolher o thumbprint apropriado.

O exemplo a seguir procura um certificado por nome amigável:
```
$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

```
Se houver vários certificados com o nome amigável especificado, isso retornará vários thumbprints concatenados e você deverá escolher o thumbprint apropriado.
Para vincular o certificado à porta, use o comando netsh http add sslcert:
```
netsh http add sslcert ipport=[endereço IP]:443 certhash=[hash do certificado] appid=[GUID do aplicativo] disablelegacytls=enable

```
- ipport: O endereço IP e a porta. Usar 0.0.0.0:443 aplica isso a todos os endereços IP. Você pode especificar um endereço IP específico.
- certhash: O thumbprint do certificado que você identificou na etapa anterior.
- appid: O GUID do Citrix Broker Service.
  
  Nota:
  
  Ao renovar um certificado ou religar, use o appid específico associado ao Broker Service em vez de um GUID arbitrário.
  
  Para encontrar o appid correto para o Citrix Broker Service:
  1. Abra uma janela de comando do PowerShell como administrador e execute o seguinte comando:
    Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" 
  2. Localize o IdentifyingNumber (GUID) para o Citrix Broker Service na saída (por exemplo, {D333C884-187F-447C-8C67-463F33989C8F}). Use este GUID para o parâmetro appid.
- disablelegacytls=enable: Desabilita versões legadas de TLS. Este parâmetro está disponível no Windows 2022 e superior. No Windows 2022, ele desabilita TLS 1.0 e 1.1. No Windows 2025, isso é desnecessário, pois TLS 1.0 e 1.1 são desabilitados por padrão.
Por exemplo, execute o seguinte comando para vincular o certificado com thumbprint bc96f958848639fd101a793b87915d5f2829b0b6 à porta 443 em todos os endereços IP:
```
netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable

```

Uma vez que o HTTPS esteja habilitado, você deve configurar quaisquer implantações do StoreFront e Netscaler Gateways para usar HTTPS em vez de HTTP para se conectar ao delivery controller.

Nota:

Se o Controller estiver instalado no Windows Server 2016 e o StoreFront estiver instalado no Windows Server 2012 R2, é necessária uma alteração de configuração no Controller para alterar a ordem das suites de criptografia TLS. Essa alteração de configuração não é necessária para Controller e StoreFront com outras combinações de versões do Windows Server.

A lista de ordem da suite de criptografia deve incluir as suites de criptografia TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ou ambas); e essas suites de criptografia devem preceder quaisquer suites de criptografia TLS_DHE_.

Usando o Editor de Política de Grupo da Microsoft, navegue até Configuração do Computador > Modelos Administrativos > Rede > Configurações de Configuração SSL.
Edite a política “Ordem da Suite de Criptografia SSL”. Por padrão, esta política é definida como “Não Configurada”. Defina esta política como “Habilitada”.
Organize as suites na ordem correta; remova quaisquer suites de criptografia que você não deseja usar.

Certifique-se de que TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 preceda quaisquer suites de criptografia TLS_DHE_.

Na Microsoft MSDN, consulte também Priorizando Suites de Criptografia Schannel.

Alterar portas HTTP ou HTTPS

Por padrão, o XML Service no Controller escuta na porta 80 para tráfego HTTP e na porta 443 para tráfego HTTPS. Embora você possa usar portas não padrão, esteja ciente dos riscos de segurança de expor um Controller a redes não confiáveis. A implantação de um servidor StoreFront autônomo é preferível a alterar os padrões.

Para alterar as portas HTTP ou HTTPS padrão usadas pelo Controller, execute o seguinte comando no Studio:

BrokerService.exe -WIPORT \<porta-http> -WISSLPORT \<porta-https>

onde <porta-http> é o número da porta para tráfego HTTP e <porta-https> é o número da porta para tráfego HTTPS.

Nota:

Após alterar uma porta, o Studio pode exibir uma mensagem sobre compatibilidade e atualização de licença. Para resolver o problema, registre novamente as instâncias de serviço usando a seguinte sequência de cmdlets do PowerShell:

Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->

Impor apenas tráfego HTTPS

Se você quiser que o XML Service ignore o tráfego HTTP, crie a seguinte configuração de registro em HKLM\Software\Citrix\DesktopServer\ no Controller e reinicie o Broker Service.

Para ignorar o tráfego HTTP, crie o DWORD XmlServicesEnableNonSsl e defina-o como 0.

Existe um valor DWORD de registro correspondente que você pode criar para ignorar o tráfego HTTPS: DWORD XmlServicesEnableSsl. Certifique-se de que ele não esteja definido como 0.

Configurações de TLS em VDAs

Um Delivery Group não pode ter uma mistura de alguns VDAs com TLS configurado e alguns VDAs sem TLS configurado. Antes de configurar o TLS para um Delivery Group, certifique-se de que você já configurou o TLS para todos os VDAs nesse Delivery Group.

Ao configurar o TLS em VDAs, as permissões no certificado TLS instalado são alteradas, concedendo ao ICA® Service acesso de leitura à chave privada do certificado e informando ao ICA Service o seguinte:

Qual certificado no armazenamento de certificados usar para TLS.
Qual número de porta TCP usar para conexões TLS.

O Firewall do Windows (se habilitado) deve ser configurado para permitir a conexão de entrada nesta porta TCP. Esta configuração é feita para você quando você usa o script PowerShell.
Quais versões do protocolo TLS permitir.

Importante:

A Citrix recomenda que você revise o uso do SSLv3 e reconfigure essas implantações para remover o suporte ao SSLv3, quando apropriado. Consulte CTX200238.

As versões de protocolo TLS suportadas seguem uma hierarquia (da mais baixa para a mais alta): SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2. Especifique a versão mínima permitida; todas as conexões de protocolo usando essa versão ou uma versão superior são permitidas.

Por exemplo, se você especificar TLS 1.1 como a versão mínima, as conexões de protocolo TLS 1.1 e TLS 1.2 serão permitidas. Se você especificar SSL 3.0 como a versão mínima, as conexões para todas as versões suportadas serão permitidas. Se você especificar TLS 1.2 como a versão mínima, apenas as conexões TLS 1.2 serão permitidas.

DTLS 1.0 corresponde a TLS 1.1, e DTLS 1.2 corresponde a TLS 1.2.
Quais suites de criptografia TLS permitir.

Uma suite de criptografia seleciona a criptografia usada para uma conexão. Clientes e VDAs podem suportar diferentes conjuntos de suites de criptografia. Quando um cliente (aplicativo Citrix Workspace ou StoreFront) se conecta e envia uma lista de suites de criptografia TLS suportadas, o VDA corresponde uma das suites de criptografia do cliente com uma das suites de criptografia em sua própria lista de suites de criptografia configuradas e aceita a conexão. Se não houver uma suite de criptografia correspondente, o VDA rejeita a conexão.

O VDA suporta três conjuntos de suites de criptografia (também conhecidos como modos de conformidade): GOV(ernment), COM(mercial) e ALL. As suites de criptografia aceitáveis também dependem do modo FIPS do Windows; consulte http://support.microsoft.com/kb/811833 para obter informações sobre o modo FIPS do Windows. A tabela a seguir lista as suites de criptografia em cada conjunto:

Suite de criptografia TLS/DTLS	ALL	COM	GOV	ALL	COM	GOV
Modo FIPS	Desligado	Desligado	Desligado	Ligado	Ligado	Ligado
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

* Não suportado no Windows Server 2012 R2.

Nota:

O VDA não suporta suites de criptografia DHE (por exemplo, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 e TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Se selecionadas pelo Windows, elas podem não ser usadas pelo Receiver.

Se você estiver usando um Citrix Gateway, consulte a documentação do Citrix ADC para obter informações sobre o suporte a suites de criptografia para comunicação de back-end. Para obter informações sobre o suporte a suites de criptografia TLS, consulte Cifras disponíveis nos appliances Citrix ADC. Para obter informações sobre o suporte a suites de criptografia DTLS, consulte Suporte a cifras DTLS.

Solicitar e instalar um certificado

No VDA, abra o console MMC e adicione o snap-in “Certificados”. Quando solicitado, selecione “Conta de computador”.
Expanda Pessoal > Certificados e use o comando do menu de contexto Todas as Tarefas > Solicitar Novo Certificado.
Clique em Avançar para iniciar e em Avançar para confirmar que você está adquirindo o certificado do registro do Active Directory.
Selecione o modelo para o certificado de Autenticação de Servidor. Tanto o padrão do Windows Computador quanto o Servidor Web Exportável são aceitáveis. Se o modelo tiver sido configurado para fornecer automaticamente os valores para “Assunto”, você pode clicar em Registrar sem fornecer mais detalhes.
Para fornecer mais detalhes para o modelo de certificado, clique em Detalhes e configure o seguinte:

Nome do assunto — selecione o tipo Nome comum e adicione o FQDN do VDA

Nome alternativo — selecione o tipo DNS e adicione o FQDN do VDA

Nota:

Use os Serviços de Certificados do Active Directory com Registro Automático de Certificados para automatizar a emissão e implantação de certificados nos VDAs. Isso é descrito em https://support.citrix.com/article/CTX205473.

Você pode usar certificados curinga para permitir que um único certificado proteja vários VDAs:

Nome do assunto — selecione o tipo Nome comum e insira o *.primary.domain dos VDAs

Nome alternativo — selecione o tipo DNS e adicione o *.primary.domain dos VDAs

Você pode usar certificados SAN para permitir que um único certificado proteja vários VDAs específicos:

Nome do assunto — selecione o tipo Nome comum e insira uma string para ajudar a identificar o uso do certificado

Nome alternativo — selecione o tipo DNS e adicione uma entrada para o FQDN de cada VDA. Mantenha o número de nomes alternativos no mínimo para garantir a negociação TLS ideal.

Nota:

Tanto os certificados curinga quanto os SAN exigem que a opção Tornar a chave privada exportável na guia “Chave Privada” seja selecionada:

Configurar TLS em um VDA usando o script PowerShell

Instale o Certificado TLS na área “Computador Local > Pessoal > Certificados” do armazenamento de certificados. Se mais de um certificado residir nesse local, forneça o thumbprint do certificado ao script PowerShell.

Nota:

A partir do XenApp e XenDesktop 7.16 LTSR, o script PowerShell encontra o certificado correto com base no FQDN do VDA. Você não precisa fornecer o thumbprint quando apenas um único certificado está presente para o FQDN do VDA.

O script Enable-VdaSSL.ps1 habilita ou desabilita o listener TLS em um VDA. Este script está disponível na pasta Support > Tools > SslSupport na mídia de instalação.

Ao habilitar o TLS, as suites de criptografia DHE são desabilitadas. As suites de criptografia ECDHE não são afetadas.

Ao habilitar o TLS, o script desabilita todas as regras existentes do Firewall do Windows para a porta TCP especificada. Em seguida, ele adiciona uma nova regra que permite que o ICA Service aceite conexões de entrada apenas nas portas TCP e UDP TLS. Ele também desabilita as regras do Firewall do Windows para:

Citrix ICA (padrão: 1494)
Citrix CGP (padrão: 2598)
Citrix WebSocket (padrão: 8008)

O efeito é que os usuários só podem se conectar usando TLS ou DTLS. Eles não podem usar ICA/HDX, ICA/HDX com Confiabilidade de Sessão ou HDX sobre WebSocket, sem TLS ou DTLS.

Nota:

O DTLS não é suportado com ICA/HDX Audio sobre UDP Real-time Transport, ou com ICA/HDX Framehawk.

Consulte Portas de rede.

O script contém as seguintes descrições de sintaxe, além de exemplos extras; você pode usar uma ferramenta como o Notepad++ para revisar essas informações.

Importante:

Especifique o parâmetro “Enable” ou “Disable” e o parâmetro “CertificateThumbPrint”. Os outros parâmetros são opcionais.

Sintaxe

Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]

Parâmetro	Descrição
Enable	Instala e habilita o listener TLS no VDA. Este parâmetro ou o parâmetro “Disable” é obrigatório.
Disable	Desabilita o listener TLS no VDA. Este parâmetro ou o parâmetro “Enable” é obrigatório. Se você especificar este parâmetro, nenhum outro parâmetro é válido.
CertificateThumbPrint “"	Thumbprint do certificado TLS no armazenamento de certificados, entre aspas. O script usa o thumbprint especificado para selecionar o certificado que você deseja usar. Se este parâmetro for omitido, um certificado incorreto será selecionado.
SSLPort	Porta TLS. Padrão: 443
SSLMinVersion “"	Versão mínima do protocolo TLS, entre aspas. Valores válidos: “TLS_1.0” (padrão), “TLS_1.1” e “TLS_1.2”.
SSLCipherSuite “"	Suite de criptografia TLS, entre aspas. Valores válidos: “GOV”, “COM” e “ALL” (padrão).

Exemplos

O script a seguir instala e habilita o valor da versão do protocolo TLS. O thumbprint (representado como “12345678987654321” neste exemplo) é usado para selecionar o certificado a ser usado.

Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"

O script a seguir instala e habilita o listener TLS e especifica a porta TLS 400, a suite de criptografia GOV e um valor mínimo de protocolo TLS 1.2. O thumbprint (representado como “12345678987654321” neste exemplo) é usado para selecionar o certificado a ser usado.

Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.2"
-SSLCipherSuite "All"

O script a seguir desabilita o listener TLS no VDA.

Enable-VdaSSL -Disable

Configurar TLS manualmente em um VDA

Ao configurar o TLS em um VDA manualmente, você concede acesso de leitura genérico à chave privada do certificado TLS para o serviço apropriado em cada VDA: NT SERVICE\PorticaService para um VDA para Windows Single-session OS, ou NT SERVICE\TermService para um VDA para Windows Multi-session OS. Na máquina onde o VDA está instalado:

PASSO 1. Inicie o console de gerenciamento da Microsoft (MMC): Iniciar > Executar > mmc.exe.

PASSO 2. Adicione o snap-in “Certificados” ao MMC:

Selecione “Arquivo > Adicionar/Remover Snap-in”.
Selecione “Certificados” e clique em “Adicionar”.
Quando solicitado com “Este snap-in sempre gerenciará certificados para:”, escolha “Conta de computador” e clique em “Avançar”.
Quando solicitado com “Selecione o computador que você deseja que este snap-in gerencie”, escolha “Computador local” e clique em “Concluir”.

PASSO 3. Em “Certificados (Computador Local) > Pessoal > Certificados”, clique com o botão direito do mouse no certificado e selecione “Todas as Tarefas > Gerenciar Chaves Privadas”.

PASSO 4. O Editor da Lista de Controle de Acesso exibe “Permissões para chaves privadas de (Nome Amigável)”, onde (Nome Amigável) é o nome do seu certificado TLS. Adicione um dos seguintes serviços e conceda-lhe acesso de Leitura:

Para um VDA para Windows Single-session OS, “PORTICASERVICE”
Para um VDA para Windows Multi-session OS, “TERMSERVICE”

PASSO 5. Clique duas vezes no certificado TLS instalado. Na caixa de diálogo do certificado, selecione a guia “Detalhes” e role até o final. Clique em “Thumbprint”.

PASSO 6. Execute regedit e vá para HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

Edite a chave “SSL Thumbprint” e copie o valor do thumbprint do certificado TLS para este valor binário. Você pode ignorar com segurança itens desconhecidos na caixa de diálogo “Editar Valor Binário” (como ‘0000’ e caracteres especiais).
Edite a chave “SSLEnabled” e altere o valor DWORD para 1. (Para desabilitar o SSL posteriormente, altere o valor DWORD para 0.)
Se você quiser alterar as configurações padrão (opcional), use o seguinte no mesmo caminho do registro:

SSLPort DWORD – Número da porta SSL. Padrão: 443.

SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Padrão: 2 (TLS 1.0).

SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Padrão: 3 (ALL).

PASSO 7. Certifique-se de que as portas TCP e UDP TLS estejam abertas no Firewall do Windows, se não forem as portas padrão 443. (Ao criar a regra de entrada no Firewall do Windows, certifique-se de que suas propriedades tenham as entradas “Permitir a conexão” e “Habilitado” selecionadas.)

PASSO 8. Certifique-se de que nenhum outro aplicativo ou serviço (como o IIS) esteja usando a porta TCP TLS.

PASSO 9. Para VDAs para Windows Multi-session OS, reinicie a máquina para que as alterações entrem em vigor. (Você não precisa reiniciar máquinas que contêm VDAs para Windows Single-session OS.)

Importante:

Uma etapa extra é necessária quando o VDA está no Windows Server 2012 R2, Windows Server 2016 ou Windows 10 Anniversary Edition ou versão posterior suportada. Isso afeta as conexões do Citrix Receiver para Windows (versão 4.6 a 4.9), Citrix Workspace app para HTML5 e Citrix Workspace app para Chrome. Isso também inclui conexões usando o Citrix Gateway.

Esta etapa também é necessária para todas as conexões usando o Citrix Gateway, para todas as versões de VDA, se o TLS entre o Citrix Gateway e o VDA estiver configurado. Isso afeta todas as versões do Citrix Receiver™.

No VDA (Windows Server 2012 R2, Windows Server 2016 ou Windows 10 Anniversary Edition ou posterior), usando o Editor de Política de Grupo, vá para “Configuração do Computador > Políticas > Modelos Administrativos > Rede > Configurações de Configuração SSL > Ordem da Suite de Criptografia SSL”. Selecione a seguinte ordem:

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

Nota:

Os seis primeiros itens também especificam a curva elíptica, P384 ou P256. Certifique-se de que “curve25519” não esteja selecionado. O Modo FIPS não impede o uso de “curve25519”.

Quando esta configuração de Política de Grupo é configurada, o VDA seleciona uma suite de criptografia apenas se ela aparecer em ambas as listas: a lista de Política de Grupo e a lista para o modo de conformidade selecionado (COM, GOV ou ALL). A suite de criptografia também deve aparecer na lista enviada pelo cliente (aplicativo Citrix Workspace ou StoreFront).

Esta configuração de Política de Grupo também afeta outros aplicativos e serviços TLS no VDA. Se seus aplicativos exigirem suites de criptografia específicas, pode ser necessário adicioná-las a esta lista de Política de Grupo.

Importante:

Embora as alterações da Política de Grupo sejam mostradas quando aplicadas, as alterações da Política de Grupo para a configuração de TLS só entram em vigor após a reinicialização do sistema operacional. Portanto, para desktops agrupados, aplique as alterações da Política de Grupo para a configuração de TLS à imagem base.

Configurar TLS em Delivery Groups

Conclua este procedimento para cada Delivery Group que contém VDAs que você configurou para conexões TLS.

No Studio, abra o console PowerShell.
Execute asnp Citrix.* para carregar os cmdlets do produto Citrix.
Execute Get-BrokerAccessPolicyRule -DesktopGroupName ‘<nome-do-grupo-de-entrega>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
Execute Set-BrokerSite -DnsResolutionEnabled $true.

Solução de problemas

Se ocorrer um erro de conexão, verifique o log de eventos do sistema no VDA.

Ao usar o aplicativo Citrix Workspace para Windows, se você receber um erro de conexão que indica um erro de TLS, desabilite o Desktop Viewer e tente conectar novamente. Embora a conexão ainda falhe, uma explicação do problema TLS subjacente pode ser fornecida. Por exemplo, você especificou um modelo incorreto ao solicitar um certificado da autoridade de certificação.

A maioria das configurações que usam o HDX™ Adaptive Transport funciona com sucesso com DTLS, incluindo aquelas que usam as versões mais recentes do aplicativo Citrix Workspace, Citrix Gateway e o VDA. Algumas configurações que usam DTLS entre o aplicativo Citrix Workspace e o Citrix Gateway, e que usam DTLS entre o Citrix Gateway e o VDA, exigem ação adicional.

Ação adicional é necessária se:

a versão do Citrix Receiver suporta HDX Adaptive Transport e DTLS: Receiver para Windows (4.7, 4.8, 4.9), Receiver para Mac (12.5, 12.6, 12.7), Receiver para iOS (7.2, 7.3.x) ou Receiver para Linux (13.7)

e qualquer um dos seguintes também se aplica:

a versão do Citrix Gateway suporta DTLS para o VDA, mas a versão do VDA não suporta DTLS (versão 7.15 ou anterior),
a versão do VDA suporta DTLS (versão 7.16 ou posterior), mas a versão do Citrix Gateway não suporta DTLS para o VDA.

Para evitar que as conexões do Citrix Receiver falhem, faça uma das seguintes ações:

atualize o Citrix Receiver para a versão 4.10 ou posterior do Receiver para Windows, Receiver para Mac 12.8 ou posterior, ou Receiver para iOS versão 7.5 ou posterior; ou,
atualize o Citrix Gateway para uma versão que suporte DTLS para o VDA; ou,
atualize o VDA para a versão 7.16 ou posterior; ou,
desabilite o DTLS no VDA; ou,
desabilite o HDX Adaptive Transport.

Nota:

Uma atualização adequada para o Receiver para Linux ainda não está disponível. O Receiver para Android (versão 3.12.3) não suporta HDX Adaptive Transport e DTLS via Citrix Gateway, e portanto não é afetado.

Para desabilitar o DTLS no VDA, modifique a configuração do firewall do VDA para desabilitar a porta UDP 443. Consulte Portas de rede.

Comunicação entre Controller e VDA

A proteção em nível de mensagem do Windows Communication Framework (WCF) protege a comunicação entre o Controller e o VDA. Não é necessária proteção adicional em nível de transporte usando TLS. A configuração do WCF usa Kerberos para autenticação mútua entre o Controller e o VDA. A criptografia usa AES no modo CBC com uma chave de 256 bits. A integridade da mensagem usa SHA-1.

De acordo com a Microsoft, os protocolos de segurança usados pelo WCF estão em conformidade com os padrões da OASIS (Organization for the Advancement of Structured Information Standards), incluindo WS-SecurityPolicy 1.2. Além disso, a Microsoft afirma que o WCF suporta todas as suites de algoritmos listadas em Security Policy 1.2.

A comunicação entre o Controller e o VDA usa a suite de algoritmos basic256, cujos algoritmos são os mencionados acima.

Redirecionamento de vídeo HTML5 e redirecionamento de conteúdo do navegador com TLS

Você pode usar o redirecionamento de vídeo HTML5 e o redirecionamento de conteúdo do navegador para redirecionar sites HTTPS. O JavaScript injetado nesses sites deve estabelecer uma conexão TLS com o Citrix HDX HTML5 Video Redirection Service em execução no VDA. Para conseguir isso, o HTML5 Video Redirection Service gera dois certificados personalizados no armazenamento de certificados no VDA. Parar o serviço remove os certificados.

A política de redirecionamento de vídeo HTML5 está desabilitada por padrão.

O redirecionamento de conteúdo do navegador está habilitado por padrão.

Para obter mais informações sobre o redirecionamento de vídeo HTML5, consulte Configurações de política de multimídia.

A versão oficial deste conteúdo está em inglês. Parte do conteúdo da documentação da Cloud Software Group é traduzida automaticamente para sua conveniência. A Cloud Software Group não tem controle sobre o conteúdo traduzido automaticamente, que pode conter erros, imprecisões ou linguagem inadequada. Nenhuma garantia de qualquer tipo, expressa ou implícita, é fornecida quanto à precisão, confiabilidade, adequação ou correção de quaisquer traduções feitas do original em inglês para qualquer outro idioma, ou quanto à conformidade do seu produto ou serviço Cloud Software Group com qualquer conteúdo traduzido automaticamente, e nenhuma garantia fornecida sob o contrato de licença de usuário final aplicável ou os termos de serviço, ou qualquer outro contrato com a Cloud Software Group, de que o produto ou serviço esteja em conformidade com qualquer documentação será aplicável na medida em que essa documentação tenha sido traduzida automaticamente. A Cloud Software Group não se responsabiliza por quaisquer danos ou problemas que possam surgir em decorrência do uso de conteúdo traduzido automaticamente.

Isso foi útil?

Transport Layer Security (TLS)

January 23, 2026

Contribuição de:

January 23, 2026

Contribuição de:

Neste artigo

Instalar certificados de servidor TLS nos Controllers
Alterar portas HTTP ou HTTPS
Configurações de TLS em VDAs
Comunicação entre Controller e VDA

Isso foi útil?