Citrix Virtual Apps and Desktops

Segurança da Camada de Transporte (TLS)

April 27, 2026

Contribuição de:

C C

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:
  - Habilitar conexões TLS entre usuários e VDAs é válido apenas para Sites do 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 problemas sérios que podem exigir a reinstalação do seu 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 aos Cloud Connectors para criptografar o tráfego STA e XML.

Embora existam vários tipos diferentes de autoridades de certificação e métodos de solicitação de certificado 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 Certificados do MMC.

Solicitando e instalando um certificado

No Delivery Controller™, abra o console MMC e adicione o snap-in Certificados. Quando solicitado, selecione “Computer account”.
Expanda “Pessoal” > “Certificados”, em seguida, use o comando do menu de contexto “Todas as Tarefas” > “Solicitar Novo Certificado”.
Clique em “Avançar” para começar 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.

Configurando 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 uma vinculação existente, exclua-a.
```
netsh http delete sslcert ipport=0.0.0.0:443

```
Substitua 0.0.0.0:443 por um endereço IP e porta específicos, se houver um especificado na vinculação existente.
Encontre a impressão digital do certificado que você instalou anteriormente. Para visualizar a impressão digital, 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 a miniatura:
```
$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árias impressões digitais concatenadas e você deverá escolher a impressão digital apropriada.

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árias impressões digitais concatenadas e você deverá escolher a impressão digital apropriada.
Para vincular o certificado à porta, use o comando netsh http add sslcert:
```
netsh http add sslcert ipport=[IP address]:443 certhash=[certificate hash] appid=[application GUID] 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, em vez disso, especificar um endereço IP específico.
- certhash: A impressão digital do certificado que você identificou na etapa anterior.
- appid: O GUID do Citrix Broker Service.
  
  Nota:
  
  Ao renovar um certificado ou revincular, 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 a impressão digital 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, uma alteração de configuração é necessária no Controller para alterar a ordem das suites de cifras 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 de suites de cifras deve incluir as suites de cifras TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ou ambas); e essas suites de cifras devem preceder quaisquer suites de cifras TLS_DHE_.

No Microsoft MSDN, consulte também Priorizando Suites de Cifras Schannel.

Alterar portas HTTP ou HTTPS

Por padrão, o Serviço XML 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. Implantar 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 \<http-port> -WISSLPORT \<https-port>

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

Observação:

Após alterar uma porta, o Studio pode exibir uma mensagem sobre compatibilidade de licença e atualização. 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 tráfego HTTPS apenas

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

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 não esteja definido como 0.

Configurações de TLS em VDAs

Um Grupo de Entrega 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 Grupo de Entrega, certifique-se de já ter configurado o TLS para todos os VDAs nesse Grupo de Entrega.

Ao configurar o TLS em VDAs, as permissões no certificado TLS instalado são alteradas, concedendo ao Serviço ICA® acesso de leitura à chave privada do certificado e informando ao Serviço ICA 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 ativado) deve ser configurado para permitir conexões de entrada nesta porta TCP. Essa configuração é feita automaticamente ao usar o script do 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 conjuntos de cifras TLS permitir.

Um conjunto de cifras seleciona a criptografia usada para uma conexão. Clientes e VDAs podem suportar diferentes conjuntos de cifras. Quando um cliente (aplicativo Citrix Workspace ou StoreFront) se conecta e envia uma lista de conjuntos de cifras TLS suportados, o VDA compara um dos conjuntos de cifras do cliente com um dos conjuntos de cifras em sua própria lista de conjuntos de cifras configurados e aceita a conexão. Se não houver um conjunto de cifras correspondente, o VDA rejeita a conexão.

O VDA suporta três conjuntos de cifras (também conhecidos como modos de conformidade): GOV(erno), COM(ercial) e ALL (todos). Os conjuntos de cifras 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 os conjuntos de cifras em cada conjunto:

Conjunto de cifras TLS/DTLS	ALL	COM	GOV	ALL	COM	GOV
Modo FIPS	Desativado	Desativado	Desativado	Ativado	Ativado	Ativado
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.

Observação:

O VDA não suporta conjuntos de cifras 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 selecionados pelo Windows, eles podem não ser usados pelo Receiver.

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

Solicitando e instalando um certificado

No VDA, abra o console MMC e adicione o snap-in Certificados. Quando solicitado, selecione a conta de Computador.
Expanda Pessoal > Certificados e, em seguida, use o comando do menu de contexto Todas as Tarefas > Solicitar Novo Certificado.
Clique em “Avançar” para começar 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

Observação:

Use o Registro Automático de Certificados dos Serviços de Certificados do Active Directory 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 uma negociação TLS ideal.

Observação:

Tanto os certificados curinga quanto os SAN exigem que “Tornar a chave privada exportável” na guia Chave Privada seja selecionado:

Configurar TLS em um VDA usando o script do 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 do PowerShell.

Observação:

A partir do XenApp e XenDesktop 7.16 LTSR, o script do 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 Suporte > Ferramentas > SslSupport na mídia de instalação.

Ao habilitar o TLS, os conjuntos de cifras DHE são desabilitados. Os conjuntos de cifras ECDHE não são afetados.

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 Serviço ICA 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.

Observação:

O DTLS não é suportado com Áudio ICA/HDX sobre Transporte UDP em Tempo Real, 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 ouvinte TLS no VDA. Este parâmetro ou o parâmetro Disable é obrigatório.
Disable	Desabilita o ouvinte TLS no VDA. Este parâmetro ou o parâmetro Enable é obrigatório. Se você especificar este parâmetro, nenhum outro parâmetro será válido.
CertificateThumbPrint “"	Impressão digital do certificado TLS no armazenamento de certificados, entre aspas. O script usa a impressão digital especificada 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 “"	Conjunto de cifras 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. A impressão digital (representada como “12345678987654321” neste exemplo) é usada para selecionar o certificado a ser usado.

Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
<!--NeedCopy-->

O script a seguir instala e habilita o ouvinte TLS, e especifica a porta TLS 400, o conjunto de cifras GOV e um valor mínimo de protocolo TLS 1.2. A impressão digital (representada como “12345678987654321” neste exemplo) é usada para selecionar o certificado a ser usado.

Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.2"
-SSLCipherSuite "All"
<!--NeedCopy-->

O script a seguir desabilita o ouvinte TLS no VDA.

Enable-VdaSSL -Disable
<!--NeedCopy-->

Configurar o 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 SO de sessão única do Windows, ou NT SERVICE\TermService para um VDA para SO de múltiplas sessões do Windows. 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 (NomeAmigável)”, onde (NomeAmigável) é o nome do seu certificado TLS. Adicione um dos seguintes serviços e conceda acesso de Leitura:

Para um VDA para SO de sessão única do Windows, “PORTICASERVICE”
Para um VDA para SO de múltiplas sessões do Windows, “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 Impressão digital.

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

Edite a chave Impressão digital SSL e copie o valor da impressão digital 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, caso não sejam a porta 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 SO de múltiplas sessões do Windows, reinicie a máquina para que as alterações entrem em vigor. (Você não precisa reiniciar máquinas que contêm VDAs para SO de sessão única do Windows.)

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 compatível. 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 do 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 do Conjunto de Cifras 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
<!--NeedCopy-->

Nota:

Os primeiros seis 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 um conjunto de cifras somente se ele 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). O conjunto de cifras também deve aparecer na lista enviada pelo cliente (Citrix Workspace app 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 conjuntos de cifras específicos, talvez seja necessário adicioná-los a esta lista de Política de Grupo.

Importante:

Embora as alterações da Política de Grupo sejam exibidas quando aplicadas, as alterações da Política de Grupo para a configuração 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 TLS à imagem base.

Configurar o TLS em Grupos de Entrega

Conclua este procedimento para cada Grupo de Entrega que contém VDAs que você configurou para conexões TLS.

No Studio, abra o console do PowerShell.
Execute asnp Citrix.* para carregar os cmdlets do produto Citrix.
Execute Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | 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 Citrix Workspace app 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 o DTLS, incluindo aquelas que usam as versões mais recentes do Citrix Workspace app, Citrix Gateway e o VDA. Algumas configurações que usam DTLS entre o Citrix Workspace app 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 uma das seguintes opções 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, 12.8 ou posterior do Receiver para Mac, ou 7.5 ou posterior do Receiver para iOS; 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 o Controller e o VDA

A proteção em nível de mensagem do Windows Communication Framework (WCF) protege a comunicação entre o Controller e o VDA. Proteção extra em nível de transporte usando TLS não é necessária. 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 o WS-SecurityPolicy 1.2. Além disso, a Microsoft afirma que o WCF suporta todos os conjuntos de algoritmos listados na Política de Segurança 1.2.

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

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

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 Serviço de Redirecionamento de Vídeo HTML5 do Citrix HDX em execução no VDA. Para conseguir isso, o Serviço de Redirecionamento de Vídeo HTML5 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 é desabilitada por padrão. O redirecionamento de conteúdo do navegador é 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?

Segurança da Camada de Transporte (TLS)

April 27, 2026

Contribuição de:

C C

April 27, 2026

Contribuição de:

C C

Neste artigo

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

Isso foi útil?