Transport Layer Security (TLS)
O Citrix Virtual Apps and Desktops oferece suporte ao protocolo TLS (Transport Layer Security) para conexões baseadas em TCP entre componentes. O Citrix Virtual Apps and Desktops também oferece suporte ao protocolo DTLS (Datagram Transport Layer Security) para conexões ICA/HDX baseadas em UDP usando transporte adaptativo.
TLS e DTLS são semelhantes e suportam os mesmos certificados digitais. Configurar um site Citrix Virtual Apps ou Citrix Virtual Desktops para usar o TLS também o configura para usar o DTLS. Use os seguintes procedimentos; as etapas são comuns ao TLS e ao 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 em Controllers.
Opcionalmente, você pode alterar as portas que o Controller usa para escutar o tráfego HTTP e HTTPS.
-
Ative as conexões TLS entre o aplicativo Citrix Workspace e os Virtual Delivery Agents (VDAs) realizando as seguintes tarefas:
- Configure o TLS nos computadores onde os VDAs estão instalados. (Para sua comodidade, referências a computadores onde os VDAs estão instalados serão simplesmente mencionadas como “VDAs“.) Para obter informações gerais, consulte Configurações de TLS em VDAs. É altamente recomendável usar o script do PowerShell fornecido pela Citrix para configurar o TLS/DTLS. Para obter detalhes, consulte Configurar o TLS em um VDA usando o script PowerShell. No entanto, se você quiser configurar o TLS/DTLS manualmente, consulte Configurar manualmente o TLS em um VDA.
-
Configure o TLS nos Grupos de Entrega que contêm os VDAs executando um conjunto de cmdlets do PowerShell no Studio. Para obter detalhes, consulte Configurar o TLS em grupos de entrega.
Requisitos e considerações:
- A ativação de conexões TLS entre usuários e VDAs é válida somente para os Sites XenApp 7.6 e XenDesktop 7.6, além das versões posteriores suportadas.
- Configure o TLS nos Grupos de Entrega e nos VDAs depois de instalar componentes, criar um Site, criar catálogos de máquinas e criar Grupos de Entrega.
- Para configurar o TLS nos Grupos de Entrega, 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 no computador onde o VDA está instalado.
- Em VDAs em pool 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 anteriores de TLS sejam perdidas. Execute o script do PowerShell sempre que o VDA for reiniciado para redefinir as configurações de TLS.
Aviso:
Nas tarefas que incluem trabalhar no registro do Windows, tenha muito cuidado: editar o registro incorretamente pode causar sérios problemas que podem exigir que você reinstale 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. Tenha o cuidado de fazer backup do registro antes de editá-lo.
Para obter informações sobre como ativar o TLS no banco de dados do Site, consulte CTX137556.
Instalar certificados de servidor TLS em Controllers
Para HTTPS, o XML Service suporta 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 a partir 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 para fins de Autenticação de Servidor.
Se a Autoridade de Certificação da Microsoft estiver integrada a um domínio do Active Directory ou a uma floresta confiável à qual os Delivery Controllers estão associados, você pode adquirir um certificado no assistente de Registro de Certificado do snap-in do MMC dos Certificados.
Solicitar e instalar um certificado
- No Delivery Controller, abra o console MMC e adicione o snap-in Certificates. Quando solicitado, selecione Conta de computador.
-
Expanda Pessoal > Certificates e, em seguida, use o comando de menu de contexto Todas as tarefas > Solicitar novo certificado.
- Clique em Avançar para começar e, depois, clique em Avançar para confirmar que você está adquirindo o certificado no registro do Active Directory.
-
Selecione o modelo para o certificado de autenticação do servidor. Se o modelo tiver sido configurado para fornecer automaticamente os valores para Entidade, você pode clicar em Inscrever 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 da entidade: selecione o nome comum Common Name e adicione o FQDN do Delivery Controller.
Nome alternativo: selecione o DNS e adicione o FQDN do Delivery Controller.
Configurar a porta de ouvinte SSL/TLS
- Abra uma janela de comando do PowerShell como administrador da máquina.
-
Execute os seguintes comandos para obter GUID do Aplicativo de Serviço de Broker:
New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT $Service_Guid = Get-ChildItem HKCR:\Installer\Products -Recurse -Ea 0 | Where-Object { $key = $\_; $\_.GetValueNames() | ForEach-Object { $key.GetValue($\_) } | Where-Object { $\_ -like 'Citrix Broker Service' } } | Select-Object Name $Service_Guid.Name -match "[A-Z0-9]*$" $Guid = $Matches[0] [GUID]$Formatted_Guid = $Guid Remove-PSDrive -Name HKCR Write-Host "Broker Service Application GUID: $($Formatted_Guid)" -ForegroundColor Yellow <!--NeedCopy--> -
Execute os seguintes comandos na mesma janela do PowerShell para obter a impressão digital do certificado que você instalou anteriormente:
$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--> -
Execute os seguintes comandos na mesma janela do PowerShell para configurar a porta SSL/TLS do Broker Service e usar o certificado para criptografia:
$IPV4_Address = Test-Connection -ComputerName $HostName -Count 1 | Select-Object -ExpandProperty IPV4Address $IPPort = "$($IPV4_Address):443" $SSLxml = "http add sslcert ipport=$IPPort certhash=$Thumbprint appid={$Formatted_Guid}" $SSLxml | netsh . netsh http show sslcert <!--NeedCopy-->
Quando configurada corretamente, a saída do último comando .netsh http show sslcert mostra que o ouvinte está usando o IP:port correto e que Application ID corresponde ao GUID do aplicativo Broker Service.
Se os servidores confiam no certificado instalado nos Delivery Controllers, agora você pode configurar as vinculações de StoreFront Delivery Controllers e Citrix Gateway STA para usar HTTPS em vez de HTTP.
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 será necessária no Controller para alterar a ordem dos pacotes de codificação TLS. Essa alteração de configuração não é necessária para o Controller e o StoreFront com outras combinações de versões do Windows Server.
A lista ordenada de pacotes de codificação deve incluir os pacotes de codificação TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ou ambos); esses pacotes de codificação devem preceder os pacotes de codificação TLS_DHE_.
- Usando o Editor de Política de Grupo da Microsoft, navegue até Configuração do Computador > Modelos Administrativos > Rede > Definições de configuração de SSL.
- Edite a política “Ordem do Pacote de Codificação de SSL”. Por padrão, essa política é definida como “Não configurada”. Defina essa política como Ativado.
- Organize os pacotes na ordem correta; remova os pacotes de codificação 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 qualquer pacote de codificação TLS_DHE_.
No Microsoft MSDN, consulte também Prioritizing Schannel Cipher Suites.
Alterar portas HTTP ou HTTPS
Por padrão, o XML Service no Controller escuta a porta 80 para o tráfego HTTP e a porta 443 para o 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. É preferível implantar um servidor StoreFront autônomo do que 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 o tráfego HTTP e <https-port> é o número da porta para o tráfego HTTPS.
Nota:
Depois de alterar uma porta, o Studio pode exibir uma mensagem sobre compatibilidade e atualização de licenças. Para resolver o problema, registre novamente as instâncias de serviço usando a seguinte sequência de cmdlet do PowerShell:
Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->
Aplicar 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 DWORD XmlServicesEnableNonSsl e defina como 0.
Há um valor DWORD de registro correspondente que você pode criar para ignorar o tráfego HTTPS: DWORD XmlServicesEnableSsl. Assegure-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 VDAs com TLS configurado e VDAs sem TLS configurado. Antes de configurar o TLS para um Grupo de Entrega, assegure-se de que já tenha configurado o TLS para todos os VDAs no Grupo de Entrega.
Quando você configura o TLS em VDAs, as permissões no certificado TLS instalado são alteradas, dando ao serviço ICA acesso de leitura à chave privada do certificado e informando o serviço ICA sobre:
- 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 a conexão de entrada nessa porta TCP. Essa configuração é feita para você quando você usa o script do PowerShell.
-
Quais versões do protocolo TLS permitir.
Importante:
A Citrix recomenda que você revise o seu uso do SSLv3 e reconfigure as implantações para remover o suporte para SSLv3 onde for apropriado. Consulte CTX200238.
As versões do protocolo TLS suportadas seguem uma hierarquia (da mais baixa à 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 que usam essa versão ou uma versão superior são permitidas.
Por exemplo, se você especifica TLS 1.1 como a versão mínima, as conexões de protocolo TLS 1.1 e TLS 1.3 são permitidas. Se você especifica SSL 3.0 como a versão mínima, as conexões a todas as versões suportadas são permitidas. Se você especifica TLS 1.3 como a versão mínima, somente conexões TLS 1.3 são permitidas.
DTLS 1.0 corresponde a TLS 1.1 e DTLS 1.3 corresponde a TLS 1.3.
-
Quais pacotes de codificação TLS permitir.
Um pacote de codificação seleciona a criptografia que é usada para uma conexão. Clientes e VDAs podem suportar diferentes conjuntos de pacotes de codificação. Quando um cliente (aplicativo Citrix Workspace ou StoreFront) se conecta e envia uma lista de pacotes de codificação TLS suportados, o VDA faz a correspondência de um dos pacotes de codificação de cliente com um dos pacotes de codificação em sua própria lista de pacotes de codificação configurados e aceita a conexão. Se não houver um pacote de codificação correspondente, o VDA rejeita a conexão.
O VDA suporta três conjuntos de pacotes de codificação (também conhecidos como modos de conformidade): GOV (governo), COM (comercial) e ALL (todos). Os pacotes de codificação 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 pacotes de codificação em cada conjunto:
| Pacote de codificação 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.
Nota:
O VDA não oferece suporte a Pacotes de Codificação 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, não podem 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 pacotes de codificação para comunicação de back-end. Para obter informações sobre o suporte o pacote de codificação TLS, consulte Ciphers available on the Citrix ADC appliances. Para obter informações sobre o suporte ao pacote de codificação DTLS, consulte DTLS cipher support.
Solicitar e instalar um certificado
- No VDA, abra o console MMC e adicione o snap-in Certificates. Quando solicitado, selecione Conta de computador.
- Expanda Pessoal > Certificates e use o comando de menu de contexto Todas as tarefas > Solicitar novo certificado.
- Clique em Avançar para começar e, depois, clique em Avançar para confirmar que você está adquirindo o certificado no registro do Active Directory.
-
Selecione o modelo para o certificado de autenticação do servidor. Tanto Computer quanto Web Server Exportable, padrão Windows, são aceitáveis. Se o modelo tiver sido configurado para fornecer automaticamente os valores para Subject, você pode clicar em Enroll sem fornecer mais detalhes.
-
Para fornecer mais detalhes para o modelo de certificado, clique em Details e configure o seguinte:
Subject name — selecione o tipo Common name e adicione o FQDN do VDA
Alternative name — selecione o tipo DNS e adicione o FQDN do VDA
Nota:
Use o registro automático do certificado dos Serviços de Certificados do Active Directory para automatizar a emissão e implantação de certificados nos VDAs. Isso está descrito em https://support.citrix.com/article/CTX205473.
Você pode usar certificados curinga para permitir que um único certificado proteja vários VDAs:
Subject name — selecione o tipo Common name e insira *.domínio.primário dos VDAs
Alternative name — selecione o tipo DNS e adicione *.domínio.primário dos VDAs
Você pode usar certificados SAN para permitir que um único certificado proteja vários VDAs específicos:
Subject name — selecione o tipo Common name e insira uma cadeia de caracteres para ajudar a identificar o ouso do certificado
Alternative name — selecione o tipo DNS e adicione uma entrada para o FQDN de cada VDA. Mantenha o número de Alternative Names a um mínimo para garantir a negociação ideal de TLS.
Nota:
Os certificados curinga e SAN exigem que Tornar a chave privada exportável, na guia Chave Privada, esteja selecionado:
Configurar o TLS em um VDA usando o script do PowerShell
Instale o certificado TLS na área de armazenamento de certificados: Computador local > Pessoal > Certificates. Se mais de um certificado residir nesse local, forneça a impressão digital do certificado para o script do PowerShell.
Nota:
Começando com XenApp e XenDesktop 7.16 LTSR, o script do PowerShell localiza o certificado correto com base no FQDN do VDA. Você não precisa fornecer a impressão digital quando somente um único certificado está presente para o VDA FQDN.
O script Enable-VdaSSL.ps1 ativa ou desativa o ouvinte TLS em um VDA. Esse script está disponível na pasta Support > Tools > SslSupport da mídia de instalação.
Quando você ativa o TLS, os pacotes de codificação DHE são desativados. Os pacotes de codificação ECDHE não são afetados.
Quando você habilita o TLS, o script desativa todas as regras de Firewall do Windows existentes da porta TCP especificada. Em seguida, adiciona uma nova regra que permite que o serviço ICA aceite conexões de entrada somente nas portas TLS TCP e UDP Também desativa as regras de Firewall do Windows para:
- Citrix ICA (padrão: 1494)
- Citrix CGP (padrão: 2598)
- Citrix WebSocket (padrão: 8008)
O resultado é 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 por WebSocket, sem TLS ou DTLS.
Nota:
O DTLS não é suportado com o ICA/HDX Audio por 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 ouvinte TLS no VDA. Esse parâmetro ou o parâmetro Disable é necessário. |
| Disable | Desabilita o ouvinte TLS no VDA. Esse parâmetro ou o parâmetro Enable é necessário. Se você especificar esse 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 esse 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.3”. |
| SSLCipherSuite “ |
Pacote de codificação 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"
O script a seguir instala e habilita o ouvinte TLS e especifica a porta TLS 400, o pacote de codificação GOV e o 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 manualmente o TLS 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 VDA para SO Windows de sessão única, ou NT SERVICE\TermService para, VDA para SO Windows multissessão. No computador onde o VDA está instalado:
ETAPA 1. Inicie o Console de Gerenciamento Microsoft (MMC): Iniciar > Executar > mmc.exe.
ETAPA 2. Adicione o snap-in Certificates ao MMC:
- Selecione Arquivo > Adicionar/remover snap-in.
- Selecione Certificados e clique em Adicionar.
- Quando a mensagem “Este snap-in sempre gerenciará certificados para:” for exibida, escolha “Conta de computador” e clique em Avançar.
- Quando a mensagem “Selecione o computador a ser gerenciado pelo snap-in” for exibida, escolha “Computador local” e clique em Finalizar.
ETAPA 3. Em Certificates (Computador local) > Pessoal > Certificates, clique com o botão direito do mouse no certificado e selecione Todas as tarefas > Gerenciar chaves privadas.
ETAPA 4. O Editor de Listas 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 dê acesso de leitura a ele:
- Para VDA para SO de sessão única Windows, “PORTICASERVICE”
- Para VDA para SO multissessão Windows, “TERMSERVICE”
ETAPA 5. Clique duas vezes no certificado TLS instalado. Na caixa de diálogo do certificado, selecione a guia Detalhes e role para baixo. Clique em Impressão digital.
ETAPA 6. Execute regedit e vá para HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Edite a chave de impressão digital do SSL e copie o valor da impressão digital do certificado TLS para esse 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 mais tarde, altere o valor de 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.3. Padrão: 2 (TLS 1.0).
SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Padrão: 3 (ALL).
ETAPA 7. Certifique-se de que as portas TLS TCP e UDP estejam abertas no Firewall do Windows se não forem o padrão 443. (Quando você cria a regra de entrada no Firewall do Windows, assegure que suas propriedades tenham as entradas “Permitir a conexão” e “Habilitada” selecionadas.)
ETAPA 8. Certifique-se de que nenhum outro aplicativo ou serviço (como o IIS) esteja usando a porta TLS TCP.
ETAPA 9. Para VDAs para SO multissessão Windows, reinicie o computador para que as alterações entrem em vigor. (Não é necessário reiniciar os computadores que contêm VDAs para SO de sessão única Windows.)
Importante:
Uma etapa extra é necessária quando o VDA está no Windows Server 2012 R2, Windows Server 2016, Windows 10 Anniversary Edition ou em uma versão mais recente suportada. Isso afeta as conexões do Citrix Receiver para Windows (versão 4.6 a 4.9), aplicativo Citrix Workspace para HTML5 e aplicativo Citrix Workspace para Chrome. Isso também inclui conexões usando o Citrix Gateway.
Essa 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, 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 > Definições de configuração de SSL > Ordem do Pacote de Codificação de SSL. Selecione na 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 essa configuração de Política de Grupo é configurada, o VDA seleciona um pacote de codificação somente se aparecer nas duas listas: lista de Política de Grupo e lista com o modo de conformidade selecionado (COM, GOV ou ALL). O pacote de codificação também deve aparecer na lista enviada pelo cliente (aplicativo Citrix Workspace ou StoreFront).
Essa configuração de política de grupo também afeta outros aplicativos e serviços TLS no VDA. Se seus aplicativos precisarem de pacotes de codificação específicos, será necessário adicioná-los à lista da Política de Grupo.
Importante:
Mesmo que as alterações na Política de Grupo sejam mostradas quando aplicadas, as alterações da Política de Grupo à configuração TLS só entram em vigor após a reinicialização do sistema operacional. Consequentemente, para áreas de trabalho em pool, aplique as alterações da Política de Grupo à configuração TLS para a imagem base.
Configurar TLS em Grupos de Entrega
Siga 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 de produtos 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 indique um erro de TLS, desative o Desktop Viewer e tente conectar-se novamente. Embora a conexão ainda falhe, você poderá ver uma explicação do problema subjacente com o TLS. 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 bem com DTLS, incluindo aquelas que usam as versões mais recentes do aplicativo Citrix Workspace, Citrix Gateway e 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ções adicionais.
Uma 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 uma das seguintes condições ocorrer:
-
a versão 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, siga um destes procedimentos:
- atualize o Citrix Receiver para: Receiver para Windows versão 4.10 ou posterior, 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 compatível com o 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:
A atualização adequada para Receiver para Linux ainda não está disponível. O Receiver para Android (versão 3.12.3) não suporta HDX Adaptive Transport nem DTLS via Citrix Gateway, portanto, ele não é afetado.
Para desabilitar o DTLS no VDA, altere a configuração do firewall do VDA para desabilitar a porta UDP 443. Consulte Portas de rede.
Comunicação entre o controlador e o VDA
A proteção no 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 no nível de transporte usando TLS. A configuração 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.
Segundo a Microsoft, os protocolos de segurança utilizados 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 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 como indicado acima.
Redirecionamento de vídeo TLS e 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 Citrix HDX HTML5 Video Redirection Service em execução no VDA. Para 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 é desativada 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 da política multimídia.