Seguridad de la capa de transporte (TLS)
Citrix Virtual Apps and Desktops admiten el protocolo Transport Layer Security (TLS) para conexiones basadas en TCP entre componentes. Citrix Virtual Apps and Desktops también admiten el protocolo Datagram Transport Layer Security (DTLS) para conexiones ICA/HDX basadas en UDP, utilizando transporte adaptativo.
TLS y DTLS son similares y admiten los mismos certificados digitales. Configurar un sitio de Citrix Virtual Apps o Citrix Virtual Desktops™ para usar TLS también lo configura para usar DTLS. Siga los procedimientos siguientes; los pasos son comunes tanto para TLS como para DTLS, excepto donde se indique:
-
Obtenga, instale y registre un certificado de servidor en todos los Delivery Controllers, y configure un puerto con el certificado TLS. Para obtener más información, consulte Instalar certificados de servidor TLS en los Controllers.
Opcionalmente, puede cambiar los puertos que el Controller utiliza para escuchar el tráfico HTTP y HTTPS.
-
Habilite las conexiones TLS entre la aplicación Citrix Workspace™ y los Virtual Delivery Agents (VDA) completando las siguientes tareas:
- Configure TLS en las máquinas donde están instalados los VDA. (Para mayor comodidad, las referencias posteriores a las máquinas donde están instalados los VDA se denominan simplemente “VDA”). Para obtener información general, consulte Configuración de TLS en VDA. Se recomienda encarecidamente que utilice el script de PowerShell proporcionado por Citrix para configurar TLS/DTLS. Para obtener más información, consulte Configurar TLS en un VDA mediante el script de PowerShell. Sin embargo, si desea configurar TLS/DTLS manualmente, consulte Configurar TLS manualmente en un VDA.
-
Configure TLS en los Delivery Groups que contienen los VDA ejecutando un conjunto de cmdlets de PowerShell en Studio. Para obtener más información, consulte Configurar TLS en Delivery Groups.
Requisitos y consideraciones:
- La habilitación de conexiones TLS entre usuarios y VDA solo es válida para sitios de XenApp 7.6 y XenDesktop 7.6, además de las versiones posteriores compatibles.
- Configure TLS en los Delivery Groups y en los VDA después de instalar los componentes, crear un sitio, crear catálogos de máquinas y crear Delivery Groups.
- Para configurar TLS en los Delivery Groups, debe tener permiso para cambiar las reglas de acceso del Controller. Un administrador con todos los permisos tiene este permiso.
- Para configurar TLS en los VDA, debe ser un administrador de Windows en la máquina donde está instalado el VDA.
- En los VDA agrupados que se aprovisionan mediante Machine Creation Services™ o Provisioning Services, la imagen de la máquina VDA se restablece al reiniciar, lo que provoca la pérdida de la configuración TLS anterior. Ejecute el script de PowerShell cada vez que se reinicie el VDA para reconfigurar la configuración TLS.
Advertencia:
Para tareas que incluyen trabajar en el registro de Windows: la edición incorrecta del registro puede causar problemas graves que pueden requerir la reinstalación del sistema operativo. Citrix® no puede garantizar que los problemas resultantes del uso incorrecto del Editor del Registro puedan resolverse. Utilice el Editor del Registro bajo su propio riesgo. Asegúrese de hacer una copia de seguridad del registro antes de editarlo.
Para obtener información sobre cómo habilitar TLS en la base de datos del sitio, consulte CTX137556.
Instalar certificados de servidor TLS en los Controllers
Para HTTPS, el servicio XML admite funciones TLS mediante certificados de servidor, no certificados de cliente. Esta sección describe cómo adquirir e instalar certificados TLS en los Delivery Controllers. Los mismos pasos se pueden aplicar a los Cloud Connectors para cifrar el tráfico STA y XML.
Aunque existen varios tipos diferentes de autoridades de certificación y métodos para solicitar certificados de ellas, este artículo describe la Autoridad de certificación de Microsoft. La Autoridad de certificación de Microsoft debe tener una plantilla de certificado publicada con el propósito de Autenticación de servidor.
Si la Autoridad de certificación de Microsoft está integrada en un dominio de Active Directory o en el bosque de confianza al que están unidos los Delivery Controllers, puede adquirir un certificado desde el asistente de inscripción de certificados del complemento MMC de certificados.
Solicitar e instalar un certificado
- En el Delivery Controller™, abra la consola MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.
-
Expanda Personal > Certificados y, a continuación, utilice el comando del menú contextual Todas las tareas > Solicitar nuevo certificado.
- Haga clic en Siguiente para empezar y en Siguiente para confirmar que está adquiriendo el certificado de la inscripción de Active Directory.
-
Seleccione la plantilla para el certificado de Autenticación de servidor. Si la plantilla se ha configurado para proporcionar automáticamente los valores para Asunto, puede hacer clic en Inscribir sin proporcionar más detalles.
-
Para proporcionar más detalles para la plantilla de certificado, haga clic en el botón de flecha Detalles y configure lo siguiente:
Nombre del asunto: seleccione Nombre común y agregue el FQDN del Delivery Controller.
Nombre alternativo: seleccione DNS y añada el FQDN del Delivery Controller.
Configuración del puerto de escucha SSL/TLS
- Abra una ventana de comandos de PowerShell como administrador de la máquina.
-
Ejecute los siguientes comandos para obtener el GUID de la aplicación del servicio 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--> -
Ejecute los siguientes comandos en la misma ventana de PowerShell para obtener la huella digital del certificado que instaló 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--> -
Ejecute los siguientes comandos en la misma ventana de PowerShell para configurar el puerto SSL/TLS del servicio Broker y usar el certificado para el cifrado:
$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-->
Cuando se configura correctamente, la salida del último comando .netsh http show sslcert muestra que el agente de escucha utiliza el IP:port correcto y que Application ID coincide con el GUID de la aplicación del servicio Broker.
Si los servidores confían en el certificado instalado en los Delivery Controllers, ahora puede configurar los Delivery Controllers de StoreFront™ y los enlaces STA de Citrix Gateway para usar HTTPS en lugar de HTTP.
Nota:
Si el Controller está instalado en Windows Server 2016 y StoreFront está instalado en Windows Server 2012 R2, es necesario realizar un cambio de configuración en el Controller para modificar el orden de los conjuntos de cifrado TLS. Este cambio de configuración no es necesario para Controller y StoreFront con otras combinaciones de versiones de Windows Server.
La lista de orden de conjuntos de cifrado debe incluir los conjuntos de cifrado TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (o ambos); y estos conjuntos de cifrado deben preceder a cualquier conjunto de cifrado TLS_DHE_.
- Con el Editor de directivas de grupo de Microsoft, vaya a Configuración del equipo > Plantillas administrativas > Red > Configuración de SSL.
- Edite la directiva “Orden de conjuntos de cifrado SSL”. De forma predeterminada, esta directiva está establecida en “No configurada”. Establezca esta directiva en Habilitada.
- Organice los conjuntos en el orden correcto; elimine los conjuntos de cifrado que no desee utilizar.
Asegúrese de que TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 precedan a cualquier conjunto de cifrado TLS_DHE_.
En Microsoft MSDN, consulte también Priorización de conjuntos de cifrado de Schannel.
Cambiar puertos HTTP o HTTPS
De forma predeterminada, el Servicio XML del Controller escucha en el puerto 80 para el tráfico HTTP y en el puerto 443 para el tráfico HTTPS. Aunque puede usar puertos no predeterminados, tenga en cuenta los riesgos de seguridad de exponer un Controller a redes que no son de confianza. Es preferible implementar un servidor StoreFront independiente a cambiar los valores predeterminados.
Para cambiar los puertos HTTP o HTTPS predeterminados utilizados por el Controller, ejecute el siguiente comando desde Studio:
BrokerService.exe -WIPORT \<http-port> -WISSLPORT \<https-port>
donde <http-port> es el número de puerto para el tráfico HTTP y <https-port> es el número de puerto para el tráfico HTTPS.
Nota:
Después de cambiar un puerto, Studio podría mostrar un mensaje sobre la compatibilidad de licencias y la actualización. Para resolver el problema, vuelva a registrar las instancias de servicio mediante la siguiente secuencia de cmdlets de PowerShell:
Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->
Aplicar solo tráfico HTTPS
Si desea que el Servicio XML ignore el tráfico HTTP, cree la siguiente configuración de registro en HKLM\Software\Citrix\DesktopServer\ en el Controller y, a continuación, reinicie el Servicio Broker.
Para ignorar el tráfico HTTP, cree el valor DWORD XmlServicesEnableNonSsl y establézcalo en 0.
Existe un valor DWORD de registro correspondiente que puede crear para ignorar el tráfico HTTPS: DWORD XmlServicesEnableSsl. Asegúrese de que no esté establecido en 0.
Configuración de TLS en VDA
Un grupo de entrega no puede tener una mezcla de VDA con TLS configurado y VDA sin TLS configurado. Antes de configurar TLS para un grupo de entrega, asegúrese de haber configurado TLS para todos los VDA de ese grupo de entrega.
Cuando se configura TLS en los VDA, los permisos del certificado TLS instalado se modifican, lo que otorga al servicio ICA® acceso de lectura a la clave privada del certificado e informa al servicio ICA de lo siguiente:
- Qué certificado del almacén de certificados se debe usar para TLS.
-
Qué número de puerto TCP se debe usar para las conexiones TLS.
El Firewall de Windows (si está habilitado) debe configurarse para permitir las conexiones entrantes en este puerto TCP. Esta configuración se realiza automáticamente al usar el script de PowerShell.
-
Qué versiones del protocolo TLS se deben permitir.
Importante:
Citrix recomienda revisar el uso de SSLv3 y reconfigurar esas implementaciones para eliminar la compatibilidad con SSLv3 cuando sea apropiado. Consulte CTX200238.
Las versiones de protocolo TLS admitidas siguen una jerarquía (de menor a mayor): SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.3. Especifique la versión mínima permitida; se permiten todas las conexiones de protocolo que utilicen esa versión o una superior.
Por ejemplo, si especifica TLS 1.1 como la versión mínima, se permiten las conexiones de protocolo TLS 1.1 y TLS 1.3. Si especifica SSL 3.0 como la versión mínima, se permiten las conexiones para todas las versiones admitidas. Si especifica TLS 1.3 como la versión mínima, solo se permiten las conexiones TLS 1.3.
DTLS 1.0 corresponde a TLS 1.1, y DTLS 1.3 corresponde a TLS 1.3.
-
Qué conjuntos de cifrado TLS se deben permitir.
Un conjunto de cifrado selecciona el cifrado que se utiliza para una conexión. Los clientes y los VDA pueden admitir diferentes conjuntos de cifrado. Cuando un cliente (aplicación Citrix Workspace o StoreFront) se conecta y envía una lista de conjuntos de cifrado TLS admitidos, el VDA compara uno de los conjuntos de cifrado del cliente con uno de los conjuntos de cifrado de su propia lista de conjuntos de cifrado configurados y acepta la conexión. Si no hay ningún conjunto de cifrado coincidente, el VDA rechaza la conexión.
El VDA admite tres conjuntos de cifrado (también conocidos como modos de cumplimiento): GOV (gobierno), COM (comercial) y ALL (todos). Los conjuntos de cifrado aceptables también dependen del modo FIPS de Windows; consulte http://support.microsoft.com/kb/811833 para obtener información sobre el modo FIPS de Windows. La siguiente tabla enumera los conjuntos de cifrado de cada conjunto:
| Conjunto de cifrado TLS/DTLS | TODOS | COM | GOV | TODOS | COM | GOV |
|---|---|---|---|---|---|---|
| Modo FIPS | Desactivado | Desactivado | Desactivado | Activado | Activado | Activado |
| 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 |
* No compatible con Windows Server 2012 R2.
Nota:
El VDA no admite conjuntos de cifrado DHE (por ejemplo, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 y TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Si Windows los selecciona, es posible que Receiver no los utilice.
Si utiliza un Citrix Gateway, consulte la documentación de Citrix ADC para obtener información sobre la compatibilidad de conjuntos de cifrado para la comunicación de back-end. Para obtener información sobre la compatibilidad de conjuntos de cifrado TLS, consulte (/es-es/citrix-adc/13/ssl/ciphers-available-on-the-citrix-adc-appliances). Para obtener información sobre la compatibilidad de conjuntos de cifrado DTLS, consulte (/es-es/citrix-adc/13/ssl/support-for-dtls-protocol.html#dtls-cipher-support).
Solicitar e instalar un certificado
- En el VDA, abra la consola MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.
- Expanda Personal > Certificados y, a continuación, utilice el comando del menú contextual Todas las tareas > Solicitar nuevo certificado.
- Haga clic en Siguiente para comenzar y en Siguiente para confirmar que está adquiriendo el certificado de la inscripción de Active Directory.
-
Seleccione la plantilla para el certificado de autenticación de servidor. Tanto la plantilla predeterminada de Windows Equipo como Servidor web exportable son aceptables. Si la plantilla se ha configurado para proporcionar automáticamente los valores para el Asunto, puede hacer clic en Inscribir sin proporcionar más detalles.
Diálogo de solicitud de certificados(/es-es/citrix-virtual-apps-desktops/2402-ltsr/media/tls-request-certificates.png)
-
Para proporcionar más detalles para la plantilla de certificado, haga clic en Detalles y configure lo siguiente:
Nombre del asunto — seleccione el tipo Nombre común y agregue el FQDN del VDA
Nombre alternativo — seleccione el tipo DNS y agregue el FQDN del VDA
Propiedades del certificado(/es-es/citrix-virtual-apps-desktops/2402-ltsr/media/tls-certificate-properties.png)
Nota:
Utilice la inscripción automática de certificados de Active Directory Certificate Services para automatizar la emisión e implementación de certificados en los VDA. Esto se describe en https://support.citrix.com/article/CTX205473.
Puede utilizar certificados comodín para permitir que un solo certificado proteja varios VDA:
Nombre del asunto — seleccione el tipo Nombre común e introduzca el *.dominio.principal de los VDA
Nombre alternativo — seleccione el tipo DNS y añada el *.primary.domain de los VDA
Puede usar certificados SAN para permitir que un solo certificado proteja varios VDA específicos:
Nombre del sujeto — seleccione el tipo Nombre común e introduzca una cadena para ayudar a identificar el uso del certificado
Nombre alternativo — seleccione el tipo DNS y añada una entrada para el FQDN de cada VDA. Mantenga el número de nombres alternativos al mínimo para garantizar una negociación TLS óptima.
Nota:
Tanto los certificados comodín como los SAN requieren que se seleccione Hacer la clave privada exportable en la pestaña Clave privada:
Configurar TLS en un VDA mediante el script de PowerShell
Instale el certificado TLS en el área Equipo local > Personal > Certificados del almacén de certificados. Si hay más de un certificado en esa ubicación, proporcione la huella digital del certificado al script de PowerShell.
Nota:
A partir de XenApp y XenDesktop 7.16 LTSR, el script de PowerShell encuentra el certificado correcto basándose en el FQDN del VDA. No es necesario proporcionar la huella digital cuando solo hay un certificado presente para el FQDN del VDA.
El script Enable-VdaSSL.ps1 habilita o deshabilita el oyente TLS en un VDA. Este script está disponible en la carpeta Support > Tools > SslSupport de los medios de instalación.
Cuando se habilita TLS, los conjuntos de cifrado DHE se deshabilitan. Los conjuntos de cifrado ECDHE no se ven afectados.
Al habilitar TLS, el script deshabilita todas las reglas existentes del Firewall de Windows para el puerto TCP especificado. A continuación, agrega una nueva regla que permite que el servicio ICA acepte conexiones entrantes solo en los puertos TCP y UDP de TLS. También deshabilita las reglas del Firewall de Windows para:
- Citrix ICA (predeterminado: 1494)
- Citrix CGP (predeterminado: 2598)
- Citrix WebSocket (predeterminado: 8008)
El efecto es que los usuarios solo pueden conectarse mediante TLS o DTLS. No pueden usar ICA/HDX, ICA/HDX con fiabilidad de sesión o HDX a través de WebSocket, sin TLS o DTLS.
Nota:
DTLS no es compatible con ICA/HDX Audio a través de UDP Real-time Transport, ni con ICA/HDX Framehawk.
Consulte Puertos de red.
El script contiene las siguientes descripciones de sintaxis, además de ejemplos adicionales; puede usar una herramienta como Notepad++ para revisar esta información.
Importante:
Especifique el parámetro Enable o Disable, y el parámetro CertificateThumbPrint. Los demás parámetros son opcionales.
Sintaxis
Enable-VdaSSL {-Enable | -Disable} -CertificateThumbPrint "<thumbprint>" [-SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"\<suite>"]
| Parámetro | Descripción |
|---|---|
| Habilitar | Instala y habilita el oyente TLS en el VDA. Se requiere este parámetro o el parámetro Deshabilitar. |
| Deshabilitar | Deshabilita el oyente TLS en el VDA. Se requiere este parámetro o el parámetro Habilitar. Si especifica este parámetro, ningún otro parámetro es válido. |
| Huella digital del certificado “ |
Huella digital del certificado TLS en el almacén de certificados, entre comillas. El script utiliza la huella digital especificada para seleccionar el certificado que desea usar. Si se omite este parámetro, se selecciona un certificado incorrecto. |
| Puerto SSL |
Puerto TLS. Predeterminado: 443 |
| Versión mínima de SSL “ |
Versión mínima del protocolo TLS, entre comillas. Valores válidos: “TLS_1.0” (predeterminado), “TLS_1.1” y “TLS_1.3”. |
| Conjunto de cifrado SSL “ |
Conjunto de cifrado TLS, entre comillas. Valores válidos: “GOV”, “COM” y “ALL” (predeterminado). |
Ejemplos
El siguiente script instala y habilita el valor de la versión del protocolo TLS. La huella digital (representada como “12345678987654321” en este ejemplo) se utiliza para seleccionar el certificado que se va a usar.
Enable-VdaSSL -Enable -CertificateThumbPrint "12345678987654321"
El siguiente script instala y habilita el oyente TLS, y especifica el puerto TLS 400, el conjunto de cifrado GOV y un valor de protocolo TLS 1.2 mínimo. La huella digital (representada como “12345678987654321” en este ejemplo) se utiliza para seleccionar el certificado que se va a usar.
Enable-VdaSSL -Enable
-CertificateThumbPrint "12345678987654321"
-SSLPort 400 -SSLMinVersion "TLS_1.3"
-SSLCipherSuite "All"
El siguiente script deshabilita el oyente TLS en el VDA.
Enable-VdaSSL -Disable
Configurar TLS manualmente en un VDA
Al configurar TLS en un VDA manualmente, se concede acceso de lectura genérico a la clave privada del certificado TLS para el servicio adecuado en cada VDA: NT SERVICE\PorticaService para un VDA para SO de sesión única de Windows, o NT SERVICE\TermService para un VDA para SO de multisesión de Windows. En la máquina donde está instalado el VDA:
PASO 1. Inicie la consola de administración de Microsoft (MMC): Inicio > Ejecutar > mmc.exe.
PASO 2. Agregue el complemento Certificados a la MMC:
- Seleccione Archivo > Agregar o quitar complemento.
- Seleccione Certificados y, a continuación, haga clic en Agregar.
- Cuando se le pregunte “Este complemento siempre administrará certificados para:”, elija “Cuenta de equipo” y, a continuación, haga clic en Siguiente.
- Cuando se le pregunte “Seleccione el equipo que desea que administre este complemento”, elija “Equipo local” y, a continuación, haga clic en Finalizar.
PASO 3. En Certificados (equipo local) > Personal > Certificados, haga clic con el botón secundario en el certificado y, a continuación, seleccione Todas las tareas > Administrar claves privadas.
PASO 4. El Editor de la lista de control de acceso muestra “Permisos para claves privadas de (Nombre descriptivo)”, donde (Nombre descriptivo) es el nombre de su certificado TLS. Agregue uno de los siguientes servicios y concédale acceso de lectura:
- Para un VDA para SO de sesión única de Windows, “PORTICASERVICE”
- Para un VDA para SO de multisesión de Windows, “TERMSERVICE”
PASO 5. Haga doble clic en el certificado TLS instalado. En el cuadro de diálogo del certificado, seleccione la ficha Detalles y, a continuación, desplácese hasta la parte inferior. Haga clic en Huella digital.
PASO 6. Ejecute regedit y vaya a HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
- Edite la clave SSL Thumbprint y copie el valor de la huella digital del certificado TLS en este valor binario. Puede ignorar con seguridad los elementos desconocidos en el cuadro de diálogo Editar valor binario (como ‘0000’ y caracteres especiales).
- Edite la clave SSLEnabled y cambie el valor DWORD a 1. (Para deshabilitar SSL más tarde, cambie el valor DWORD a 0).
-
Si desea cambiar la configuración predeterminada (opcional), utilice lo siguiente en la misma ruta del Registro:
SSLPort DWORD – Número de puerto SSL. Predeterminado: 443.
SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.3. Predeterminado: 2 (TLS 1.0).
SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Predeterminado: 3 (ALL).
PASO 7. Asegúrese de que los puertos TCP y UDP de TLS estén abiertos en el Firewall de Windows si no son el 443 predeterminado. (Cuando cree la regla de entrada en el Firewall de Windows, asegúrese de que sus propiedades tengan las entradas “Permitir la conexión” y “Habilitado” seleccionadas).
PASO 8. Asegúrese de que ninguna otra aplicación o servicio (como IIS) esté utilizando el puerto TCP de TLS.
PASO 9. Para los VDA para SO de Windows multisesión, reinicie la máquina para que los cambios surtan efecto. (No es necesario reiniciar las máquinas que contienen VDA para SO de Windows de sesión única).
Importante:
Es necesario un paso adicional cuando el VDA está en Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o una versión posterior compatible. Esto afecta a las conexiones desde Citrix Receiver para Windows (versión 4.6 a 4.9), la aplicación Citrix Workspace para HTML5 y la aplicación Citrix Workspace para Chrome. Esto también incluye las conexiones que utilizan Citrix Gateway.
Este paso también es necesario para todas las conexiones que utilizan Citrix Gateway, para todas las versiones de VDA, si TLS está configurado entre Citrix Gateway y el VDA. Esto afecta a todas las versiones de Citrix Receiver™.
En el VDA (Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o posterior), utilizando el Editor de directivas de grupo, vaya a Configuración del equipo > Directivas > Plantillas administrativas > Red > Configuración de configuración de SSL > Orden de conjuntos de cifrado SSL. Seleccione el siguiente orden:
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:
Los primeros seis elementos también especifican la curva elíptica, P384 o P256. Asegúrese de que “curve25519” no esté seleccionada. El modo FIPS no impide el uso de “curve25519”.
Cuando se configura esta opción de Directiva de grupo, el VDA selecciona un conjunto de cifrado solo si aparece en ambas listas: la lista de Directiva de grupo y la lista del modo de cumplimiento seleccionado (COM, GOV o ALL). El conjunto de cifrado también debe aparecer en la lista enviada por el cliente (Citrix Workspace app o StoreFront).
Esta configuración de Directiva de grupo también afecta a otras aplicaciones y servicios TLS en el VDA. Si sus aplicaciones requieren conjuntos de cifrado específicos, es posible que deba agregarlos a esta lista de Directiva de grupo.
Importante:
Aunque los cambios de Directiva de grupo se muestran cuando se aplican, los cambios de Directiva de grupo para la configuración de TLS solo surten efecto después de reiniciar el sistema operativo. Por lo tanto, para los escritorios agrupados, aplique los cambios de Directiva de grupo para la configuración de TLS a la imagen base.
Configurar TLS en grupos de entrega
Complete este procedimiento para cada grupo de entrega que contenga VDA que haya configurado para conexiones TLS.
- Desde Studio, abra la consola de PowerShell.
- Ejecute asnp Citrix.* para cargar los cmdlets del producto Citrix.
- Ejecute Get-BrokerAccessPolicyRule -DesktopGroupName ‘<delivery-group-name>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
- Ejecute Set-BrokerSite -DnsResolutionEnabled $true.
Solución de problemas
Si se produce un error de conexión, compruebe el registro de eventos del sistema en el VDA.
Cuando utilice Citrix Workspace app para Windows, si recibe un error de conexión que indica un error de TLS, deshabilite Desktop Viewer y, a continuación, intente conectarse de nuevo. Aunque la conexión siga fallando, es posible que se proporcione una explicación del problema de TLS subyacente. Por ejemplo, especificó una plantilla incorrecta al solicitar un certificado a la autoridad de certificación).
La mayoría de las configuraciones que utilizan HDX™ Adaptive Transport funcionan correctamente con DTLS, incluidas las que utilizan las últimas versiones de Citrix Workspace app, Citrix Gateway y el VDA. Algunas configuraciones que utilizan DTLS entre Citrix Workspace app y Citrix Gateway, y que utilizan DTLS entre Citrix Gateway y el VDA, requieren una acción adicional.
Se necesita una acción adicional si:
- la versión de Citrix Receiver es compatible con HDX Adaptive Transport y 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) o Receiver para Linux (13.7)
y también se aplica una de las siguientes opciones:
-
la versión de Citrix Gateway es compatible con DTLS para el VDA, pero la versión del VDA no es compatible con DTLS (versión 7.15 o anterior),
-
la versión del VDA es compatible con DTLS (versión 7.16 o posterior), pero la versión de Citrix Gateway no es compatible con DTLS para el VDA.
Para evitar que las conexiones de Citrix Receiver fallen, realice una de las siguientes acciones:
- actualice Citrix Receiver a la versión 4.10 o posterior de Receiver para Windows, la versión 12.8 o posterior de Receiver para Mac, o la versión 7.5 o posterior de Receiver para iOS; o bien,
- actualice Citrix Gateway a una versión compatible con DTLS para el VDA; o bien,
- actualice el VDA a la versión 7.16 o posterior; o bien,
- deshabilite DTLS en el VDA; o bien,
- deshabilite HDX Adaptive Transport.
Nota:
Todavía no hay disponible una actualización adecuada para Receiver para Linux. Receiver para Android (versión 3.12.3) no es compatible con HDX Adaptive Transport y DTLS a través de Citrix Gateway, por lo que no se ve afectado.
Para deshabilitar DTLS en el VDA, modifique la configuración del firewall del VDA para deshabilitar el puerto UDP 443. Consulte Puertos de red.
Comunicación entre Controller y VDA
La protección a nivel de mensaje de Windows Communication Framework (WCF) protege la comunicación entre el Controller y el VDA. No se requiere protección adicional a nivel de transporte mediante TLS. La configuración de WCF utiliza Kerberos para la autenticación mutua entre el Controller y el VDA. El cifrado utiliza AES en modo CBC con una clave de 256 bits. La integridad del mensaje utiliza SHA-1.
Según Microsoft, los protocolos de seguridad utilizados por WCF cumplen con los estándares de OASIS (Organization for the Advancement of Structured Information Standards), incluido WS-SecurityPolicy 1.2. Además, Microsoft afirma que WCF es compatible con todas las suites de algoritmos enumeradas en Security Policy 1.2.
La comunicación entre el Controller y el VDA utiliza la suite de algoritmos basic256, cuyos algoritmos son los indicados anteriormente.
TLS y redirección de vídeo HTML5, y redirección de contenido del explorador
Puede utilizar la redirección de vídeo HTML5 y la redirección de contenido del explorador para redirigir sitios web HTTPS. El JavaScript inyectado en esos sitios web debe establecer una conexión TLS con el servicio de redirección de vídeo HTML5 de Citrix HDX que se ejecuta en el VDA. Para ello, el servicio de redirección de vídeo HTML5 genera dos certificados personalizados en el almacén de certificados del VDA. Al detener el servicio, se eliminan los certificados.
La directiva de redirección de vídeo HTML5 está inhabilitada de forma predeterminada.
La redirección de contenido del explorador está habilitada de forma predeterminada.
Para obtener más información sobre la redirección de vídeo HTML5, consulte Configuración de directivas multimedia.