Segurança da Camada de Transporte (TLS)

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 seguintes procedimentos; 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 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 do XenApp 7.6 e XenDesktop 7.6, além de versões posteriores suportadas.
    • 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 por 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 que você reinstale seu sistema operacional. A Citrix® não pode garantir que 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 Serviço XML 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 Certificado do snap-in Certificados do MMC.

Solicitando e instalando um certificado

1. No Delivery Controller™, abra o console MMC e adicione o snap-in Certificados. Quando solicitado, selecione Conta de computador.

2. Expanda Pessoal > Certificados e, em seguida, use o comando do menu de contexto Todas as Tarefas > Solicitar Novo Certificado.

   

3. Clique em Avançar para começar e em Avançar para confirmar que você está adquirindo o certificado do registro do Active Directory.

4. 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.

   

5. 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 do ouvinte 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:

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

   netsh http show sslcert
   <!--NeedCopy-->
   

2. Se houver uma vinculação existente, exclua-a.

   netsh http delete sslcert ipport=0.0.0.0:443
   <!--NeedCopy-->
   

   Substituindo 0.0.0.0:443 por um endereço IP e porta específicos, caso um tenha sido especificado na vinculação existente.

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

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

   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.

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

   • 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 Serviço de Broker da Citrix.

     Nota:

     Ao renovar um certificado ou refazer a vinculação, use o appid específico associado ao Serviço de Broker em vez de um GUID arbitrário.

     Para encontrar o appid correto para o Serviço de Broker da Citrix:

     1. Abra uma janela de comando do PowerShell como administrador e execute o seguinte comando:

         Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker"
         <!--NeedCopy-->
        

     2. Localize o IdentifyingNumber (GUID) para o Serviço de Broker da Citrix 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 o TLS 1.0 e 1.1. No Windows 2025, isso é desnecessário, pois o 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
   <!--NeedCopy-->
   

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_.

1. 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.
2. Edite a política “Ordem da Suite de Cifras SSL”. Por padrão, esta política está definida como “Não Configurado”. Defina esta política como Habilitado.
3. Organize as suites na ordem correta; remova quaisquer suites de cifras suites 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 precede 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. 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 \<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.

Nota:

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 apenas tráfego HTTPS

Se você deseja 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 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 que já configurou o TLS para todos os VDAs nesse Grupo de Entrega.

Ao configurar o TLS nos 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 o Serviço ICA sobre 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. Esta configuração é feita automaticamente 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, TLS 1.2 e TLS 1.3. 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, então as conexões de protocolo TLS 1.1 e TLS 1.3 serão permitidas. Se você especificar SSL 3.0 como a versão mínima, então as conexões para todas as versões suportadas serão permitidas. Se você especificar TLS 1.3 como a versão mínima, apenas as conexões TLS 1.3 serão permitidas.

  DTLS 1.0 corresponde a TLS 1.1, e DTLS 1.3 corresponde a TLS 1.3.

• 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 (Citrix Workspace app 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(ernamental), 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:

* Não suportado no Windows Server 2012 R2.

Nota:

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

1. No VDA, abra o console MMC e adicione o snap-in Certificados. Quando solicitado, selecione Conta de computador.
2. Expanda Pessoal > Certificados e, em seguida, use o comando do menu de contexto Todas as Tarefas > Solicitar Novo Certificado.
3. Clique em Avançar para começar e em Avançar para confirmar que você está adquirindo o certificado do registro do Active Directory.

4. 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.

   

5. 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 o Registro Automático de Certificados dos Serviços de Certificação 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.

   

   Nota:

   Tanto os certificados curinga quanto os SAN exigem que Exportar chave privada na guia Chave Privada seja selecionado:

   

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 a impressão digital 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 a impressão digital 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.

Quando você habilita o TLS, os conjuntos de cifras DHE são desabilitados. Os conjuntos de cifras ECDHE não são afetados.

Quando você habilita 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.

Nota:

O DTLS não é compatível 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>"]

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"

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.3"
-SSLCipherSuite "All"

O script a seguir desabilita o ouvinte TLS no VDA.

Enable-VdaSSL -Disable

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:

1. Selecione Arquivo > Adicionar/Remover Snap-in.
2. Selecione Certificados e clique em Adicionar.
3. Quando solicitado com “Este snap-in sempre gerenciará certificados para:”, escolha “Conta de computador” e clique em Avançar.
4. 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 (FriendlyName)” onde (FriendlyName) é 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 o regedit e vá para HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

1. 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).
2. Edite a chave SSLEnabled e altere o valor DWORD para 1. (Para desabilitar o SSL posteriormente, altere o valor DWORD para 0.)

3. 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.3. 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 TLS TCP e UDP estejam abertas no Firewall do Windows, caso não sejam 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 TLS TCP.

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 contenham 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 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 que usam 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 Computer Configuration > Policies > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. 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 um conjunto de cifras apenas se ele aparecer em ambas as listas: a lista da 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 (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 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 TLS em Grupos de Entrega

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

1. No Studio, abra o console do PowerShell.
2. Execute asnp Citrix.* para carregar os cmdlets do produto Citrix.
3. Execute Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
4. 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 TLS, desative 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.

É necessária uma ação adicional se:

• a versão do Citrix Receiver suporta HDX Adaptive Transport e 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) ou Receiver for 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 for Windows, 12.8 ou posterior do Receiver for Mac, ou 7.5 ou posterior do Receiver for 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,
• desative o DTLS no VDA; ou,
• desative o HDX Adaptive Transport.

Nota:

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

Para desativar o DTLS no VDA, modifique a configuração do firewall do VDA para desativar 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 extra 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 oferece suporte a todos os conjuntos de algoritmos listados em Security Policy 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. A interrupção do 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.