Seguridad de la capa de transporte (TLS)
Citrix Virtual Apps and Desktops admite el protocolo Seguridad de la capa de transporte (TLS) para conexiones basadas en TCP entre componentes. Citrix Virtual Apps and Desktops también admite el protocolo Seguridad de la capa de transporte de datagramas (DTLS) para conexiones ICA/HDX basadas en UDP, mediante transporte adaptable.
TLS y DTLS son similares y admiten los mismos certificados digitales. Al configurar un sitio de Citrix Virtual Apps o Citrix Virtual Desktops™ para usar TLS, también se configura para usar DTLS. Siga estos procedimientos; los pasos son comunes tanto para TLS como para DTLS, salvo que se indique lo contrario:
-
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 los 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 grupos de entrega que contienen los VDA ejecutando un conjunto de cmdlets de PowerShell en Studio. Para obtener más información, consulte Configurar TLS en grupos de entrega.
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 grupos de entrega y en los VDA después de instalar los componentes, crear un sitio, crear catálogos de máquinas y crear grupos de entrega.
- Para configurar TLS en los grupos de entrega, 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 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 los ajustes de TLS.
Advertencia:
Para las 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 derivados del uso incorrecto del Editor del Registro puedan resolverse. Utilice el Editor del Registro bajo su propia responsabilidad. 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 las funciones de 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, use 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
Si el componente IIS de Windows está instalado en el mismo servidor, que se instala como parte de Web Studio y Director, puede configurar TLS mediante IIS. Para obtener más información, consulte Habilitar TLS en Web Studio y Director. De lo contrario, para configurar el certificado mediante PowerShell:
-
Para comprobar si hay un certificado existente vinculado, abra un símbolo del sistema y ejecute
netsh http show sslcert:netsh http show sslcert <!--NeedCopy--> -
Si hay un enlace existente, elimínelo.
netsh http delete sslcert ipport=0.0.0.0:443 <!--NeedCopy-->Sustituya
0.0.0.0:443por una dirección IP y un puerto específicos si se especificó uno en el enlace existente. -
Busque la huella digital del certificado que instaló anteriormente. Para ver la huella digital, abra Administrar certificados de equipo, busque el certificado, ábralo y vaya a la ficha Detalles.
Alternativamente, puede usar PowerShell. Por ejemplo, el siguiente script busca un certificado cuyo nombre común coincide con el nombre de host del servidor e imprime la 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-->Si el nombre común del certificado no coincide con los nombres de host, se producirá un error. Si hay varios certificados para el nombre de host, esto devuelve varias huellas digitales concatenadas y debe elegir la huella digital adecuada.
El siguiente ejemplo busca un certificado por nombre descriptivo:
$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-->Si hay varios certificados con el nombre descriptivo especificado, esto devuelve varias huellas digitales concatenadas y debe elegir la huella digital adecuada.
-
Para vincular el certificado al puerto, use el comando
netsh http add sslcert:netsh http add sslcert ipport=[IP address]:443 certhash=[certificate hash] appid=[application GUID] disablelegacytls=enable <!--NeedCopy-->-
ipport: La dirección IP y el puerto. El uso de 0.0.0.0:443 lo aplica a todas las direcciones IP. En su lugar, puede especificar una dirección IP concreta. -
certhash: La huella digital del certificado que identificó en el paso anterior. -
appid: El GUID del servicio Citrix Broker.Nota:
Al renovar un certificado o volver a enlazarlo, utilice el
appidespecífico asociado al servicio Broker en lugar de un GUID arbitrario.Para encontrar el
appidcorrecto para el servicio Citrix Broker:-
Abra una ventana de comandos de PowerShell como administrador y ejecute el siguiente comando:
Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker" <!--NeedCopy--> -
Localice el IdentifyingNumber (GUID) del servicio Citrix Broker en la salida (por ejemplo,
{D333C884-187F-447C-8C67-463F33989C8F}). Utilice este GUID para el parámetroappid.
-
-
disablelegacytls=enable: Deshabilita las versiones heredadas de TLS. Este parámetro está disponible en Windows 2022 y versiones posteriores. En Windows 2022 deshabilita TLS 1.0 y 1.1. En Windows 2025 esto es innecesario, ya que TLS 1.0 y 1.1 están deshabilitados de forma predeterminada.
Por ejemplo, ejecute el siguiente comando para enlazar el certificado con la huella digital
bc96f958848639fd101a793b87915d5f2829b0b6al puerto443en todas las direcciones IP:netsh http add sslcert ipport=0.0.0.0:443 certhash=bc96f958848639fd101a793b87915d5f2829b0b6 appid={91fe7386-e0c2-471b-a252-1e0a805febac} disablelegacytls=enable <!--NeedCopy--> -
Una vez que HTTPS esté habilitado, debe configurar cualquier implementación de StoreFront y Netscaler Gateways para que utilicen HTTPS en lugar de HTTP para conectarse al Delivery Controller.
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 las suites en el orden correcto; elimine las suites 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 preceda a cualquier suite de cifrado TLS_DHE_.
En Microsoft MSDN, consulte también Priorización de suites de cifrado 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 utilizar puertos no predeterminados, tenga en cuenta los riesgos de seguridad que implica exponer un Controller a redes no fiables. 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 algunos VDA con TLS configurado y otros 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.
Al configurar TLS en los VDA, se cambian los permisos del certificado TLS instalado, 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 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 y TLS 1.2. 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 versión mínima, se permiten las conexiones de protocolo TLS 1.1 y TLS 1.2. Si especifica SSL 3.0 como versión mínima, se permiten las conexiones para todas las versiones admitidas. Si especifica TLS 1.2 como versión mínima, solo se permiten las conexiones TLS 1.2.
DTLS 1.0 corresponde a TLS 1.1, y DTLS 1.2 corresponde a TLS 1.2.
-
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 un 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(ernment), COM(mercial) y ALL. 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 | GOB | TODOS | COM | GOB |
|---|---|---|---|---|---|---|
| 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 con conjuntos de cifrado para la comunicación de back-end. Para obtener información sobre la compatibilidad con conjuntos de cifrado TLS, consulte Cifrados disponibles en los dispositivos Citrix ADC. Para obtener información sobre la compatibilidad con conjuntos de cifrado DTLS, consulte Compatibilidad con cifrado DTLS.
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 empezar y en Siguiente para confirmar que está adquiriendo el certificado del registro de Active Directory.
-
Seleccione la plantilla para el certificado de autenticación de servidor. Tanto el valor predeterminado de Windows Equipo como Servidor web exportable son aceptables. Si la plantilla se ha configurado para proporcionar automáticamente los valores de Asunto, puede hacer clic en Inscribir sin proporcionar más detalles.
-
Para proporcionar más detalles para la plantilla de certificado, haga clic en Detalles y configure lo siguiente:
Nombre del sujeto — seleccione el tipo Nombre común y agregue el FQDN del VDA
Nombre alternativo — seleccione el tipo DNS y agregue el FQDN del VDA
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 usar certificados comodín para permitir que un solo certificado proteja varios VDA:
Nombre del asunto — seleccione el tipo Nombre común e introduzca el *.primary.domain de los VDA
Nombre alternativo — seleccione el tipo DNS y añada el *.primary.domain de los VDA
Puede utilizar certificados SAN para permitir que un único certificado proteja varios VDA específicos:
Nombre del asunto — 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 que la clave privada sea exportable en la ficha 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 agente de escucha 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.
Cuando se habilita TLS, el script deshabilita todas las reglas existentes del Firewall de Windows para el puerto TCP especificado. Luego, agrega una nueva regla que permite al servicio ICA aceptar 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 transporte UDP en tiempo real, 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 |
|---|---|
| Enable | Instala y habilita el agente de escucha TLS en el VDA. Se requiere este parámetro o el parámetro Disable. |
| Disable | Inhabilita el agente de escucha TLS en el VDA. Se requiere este parámetro o el parámetro Enable. 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 utilizar. 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.2”. |
| 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 utilizar.
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.2"
-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 las claves privadas de (FriendlyName)”, donde (FriendlyName) 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 sin problemas los elementos desconocidos en el cuadro de diálogo Editar valor binario (como ‘0000’ y los caracteres especiales).
- Edite la clave SSLEnabled y cambie el valor DWORD a 1. (Para inhabilitar SSL más tarde, cambie el valor DWORD a 0).
-
Si quiere 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.2. 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. (Al crear la regla de entrada en el Firewall de Windows, asegúrese de que sus propiedades tengan seleccionadas las entradas “Permitir la conexión” y “Habilitado”.)
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 compatible posterior. Esto afecta a las conexiones de Citrix Receiver para Windows (versión 4.6 a 4.9), Citrix Workspace app para HTML5 y Citrix Workspace app 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), con el Editor de directivas de grupo, vaya a Computer Configuration > Policies > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. 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 seis primeros elementos también especifican la curva elíptica, P384 o P256. Asegúrese de que no se selecciona “curve25519”. 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 de productos de 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 entidad 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 alguna 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 fallen las conexiones de Citrix Receiver, 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,
- inhabilite DTLS en el VDA; o bien,
- inhabilite 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 inhabilitar DTLS en el VDA, modifique la configuración del firewall del VDA para inhabilitar 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 lograr esto, 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 de multimedia.