Transport Layer Security (TLS)

Citrix Virtual Apps and Desktops admiten el protocolo Transport Layer Security (TLS) para las conexiones por TCP entre los componentes. Citrix Virtual Apps and Desktops también admiten el protocolo Datagram Transport Layer Security (DTLS) para las conexiones ICA o HDX por UDP cuando se utiliza el transporte adaptable.

TLS y DTLS son similares y admiten los mismos certificados digitales. Configurar un sitio Citrix Virtual Apps o Citrix Virtual Desktops para usar TLS también lo configura para usar DTLS. Siga estos procedimientos; son los mismos pasos tanto para TLS como para DTLS (excepto donde se indique):

• Obtener, instalar y registrar un certificado de servidor en todos los Delivery Controllers y configurar un puerto con el certificado TLS. Para obtener más información, consulte Instalar certificados de servidor TLS en los Controllers.

  Si lo quiere, puede cambiar los puertos que Controller utiliza para escuchar el tráfico HTTP y HTTPS.

• Habilite las conexiones TLS entre la aplicación Citrix Workspace y los agentes VDA (Virtual Delivery Agent) completando las siguientes tareas:

  • Configure TLS en las máquinas donde los VDA están instalados. (Para simplificar, en adelante se usará “VDA” para hacer referencia a la máquina donde está instalado un VDA.) Para obtener información general, consulte Parámetros de TLS en los VDA. Se recomienda que utilice el script de PowerShell suministrado por Citrix para configurar TLS o DTLS. Para obtener información detallada, consulte Configurar TLS en un VDA mediante el script de PowerShell. Sin embargo, si quiere configurar TLS o DTLS manualmente, consulte Configurar TLS manualmente en un VDA.

  • Configure TLS en los grupos de entrega que contienen los VDA mediante la ejecución de un conjunto de cmdlets de PowerShell en Studio. Para obtener más información, consulte Configuración de TLS en los grupos de entrega.

    Requisitos y consideraciones:

    • El hecho de habilitar conexiones TLS entre los usuarios y los VDA solo es válido para los sitios de XenApp 7.6 y XenDesktop 7.6 y 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 a los Controllers. Un administrador total tiene este permiso.
    • Para configurar TLS en los VDA, debe ser un administrador Windows en la máquina donde está instalado el VDA.
    • En agentes VDA agrupados y aprovisionados por Machine Creation Services o Provisioning Services, la imagen de la máquina del VDA se restablece en el proceso de reinicio, lo que provoca la pérdida de la configuración anterior de TLS. Ejecute el script de PowerShell cada vez que se reinicie el VDA para volver a configurar los parámetros de TLS.

Advertencia:

Para las tareas que impliquen modificar el Registro de Windows, tenga cuidado: si se modifica de forma incorrecta, pueden producirse problemas graves que obliguen a reinstalar el sistema operativo. Citrix no puede garantizar que los problemas derivados de la utilización inadecuada del Editor del Registro puedan resolverse. Si utiliza el Editor del Registro, será bajo su propia responsabilidad. Haga una copia de seguridad del Registro antes de modificarlo.

Para obtener información acerca de la habilitación de TLS para la base de datos del sitio, consulte CTX137556.

Instalar certificados de servidor TLS en los Controllers

Para HTTPS, XML Service admite las funciones de TLS cuando se usan certificados de servidor, no cuando se usan certificados de cliente. En esta sección, se describe la adquisición e instalación de certificados TLS en Delivery Controllers. Los mismos pasos se pueden aplicar a Cloud Connectors para cifrar el tráfico STA y XML.

Aunque hay varios tipos diferentes de entidades de certificación y métodos para solicitar certificados de ellas, en este artículo se describe la entidad emisora de certificados de Microsoft. La entidad de certificación de Microsoft debe tener una plantilla de certificado publicada con el propósito Autenticación de servidor.

Si la entidad 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, se puede adquirir un certificado desde el asistente para inscripción de certificados del complemento MMC Certificados.

Solicitar e instalar un certificado

1. En el Delivery Controller, abra la consola de MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.

2. Expanda Personal > Certificados y, a continuación, utilice la opción de menú contextual Todas las tareas > Solicitar un nuevo certificado.

   

3. Haga clic en Siguiente para comenzar y en Siguiente para confirmar que va a adquirir el certificado de inscripción en Active Directory.

4. Seleccione la plantilla para 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 datos.

   

5. 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 agregue el FQDN del Delivery Controller.

   

Configurar el puerto de escucha SSL/TLS

1. Abra una ventana de comandos de PowerShell como administrador de la máquina.

2. Ejecute los siguientes comandos para obtener el GUID de aplicación de Broker Service:

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

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

4. Ejecute los siguientes comandos en la misma ventana de PowerShell para configurar el puerto SSL/TLS de Broker Service 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, el resultado del último comando .netsh http show sslcert muestra que el agente de escucha utiliza el IP:port correcto y que Application ID es el GUID de aplicación de Broker Service.

Si los servidores confían en el certificado instalado en los Delivery Controllers, ahora puede configurar los vínculos de Delivery Controllers de StoreFront y Citrix Gateway STA para que utilicen HTTPS, en lugar de HTTP.

Nota:

Si el Controller está instalado en Windows Server 2016 o Windows Server 2019, y StoreFront está instalado en Windows Server 2012 R2, es necesario cambiar la configuración en el Controller o en StoreFront para cambiar el orden de los conjuntos de cifrado TLS. Este cambio de configuración no es necesario para Controller ni StoreFront con otras combinaciones de versiones de Windows Server.

La lista ordenada de los conjuntos de cifrado debe incluir el conjunto de cifrado TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (o ambos) o conjuntos de cifrado TLS_ECDHE similares, y estos conjuntos deben preceder los conjuntos de cifrado TLS_DHE.

1. Desde el editor de directivas de grupo de Microsoft, vaya a Configuración del equipo > Plantillas administrativas > Red > Opciones de configuración SSL.
2. Modifique la directiva “Orden de conjuntos de cifrado SSL”. De manera predeterminada, esta directiva está establecida en “No configurada”. Habilite esta directiva.
3. Ordene los conjuntos de cifrado; quite aquellos conjuntos que no quiera usar.

Compruebe que TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 o un conjunto de cifrado TLS_ECDHE similar preceda los conjuntos de cifrado TLS_DHE.

En Microsoft MSDN, también puede consultar Prioritizing Schannel Cipher Suites.

Cambiar puertos HTTP o HTTPS

De forma predeterminada, el XML Service en el Controller escucha en los puertos 80 para el tráfico HTTP y 443 para el tráfico HTTPS. Aunque se pueden utilizar otros puertos distintos de los predeterminados, tenga en cuenta los riesgos de seguridad que implica la exposición de un Controller a redes que no son de confianza. Antes que cambiar los valores predeterminados, es preferible implementar un servidor de StoreFront independiente.

Para cambiar los puertos HTTP o HTTPS predeterminados que usa el Controller, ejecute el comando siguiente en Studio:

BrokerService.exe -WIPORT <puerto http> -WISSLPORT <puerto https>

<puerto http> es el número de puerto para el tráfico HTTP y <puerto https> es el número de puerto para el tráfico HTTPS.

Nota:

Después de cambiar de un puerto, Studio puede mostrar un mensaje acerca de la actualización y la compatibilidad de licencias. Para resolver el problema, vuelva a registrar las instancias de servicio mediante esta secuencia de cmdlet de PowerShell:

Get-ConfigRegisteredServiceInstance -ServiceType Broker -Binding XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance
Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |
Register-ConfigServiceInstance
<!--NeedCopy-->

Solo aplicar el tráfico HTTPS

Si quiere que XML Service ignore el tráfico HTTP, cree el siguiente parámetro de Registro en HKLM\Software\Citrix\DesktopServer\ en el Controller y reinicie el Broker Service.

Para ignorar el tráfico HTTP, cree DWORD XmlServicesEnableNonSsl y dele el valor 0.

Se puede crear el valor DWORD de Registro correspondiente para ignorar el tráfico HTTPS: DWORD XmlServicesEnableSsl. Compruebe que no está establecido en 0.

Parámetros de TLS en agentes VDA

Un grupo de entrega no puede incluir una mezcla de VDA con TLS configurado y VDA sin TLS configurado. Antes de configurar TLS para un grupo de entrega, debe haber configurado TLS para todos los VDA en ese grupo de entrega.

Si configura TLS en los VDA, cambian los permisos en el certificado TLS instalado, lo que da 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 hay que usar para TLS.

• Qué número de puerto TCP hay que usar para las conexiones TLS.

  El Firewall de Windows (si está habilitado) debe estar configurado para permitir conexiones entrantes en este puerto TCP. Esta configuración se lleva a cabo cuando se usa el script de PowerShell.

• Qué versiones del protocolo TLS se deben permitir.

  Importante:

  Citrix recomienda revisar el uso de SSL 3 y volver a configurar las implementaciones para retirar la compatibilidad con SSL 3 donde corresponda. Consulte CTX200238.

  Las versiones compatibles con el protocolo TLS siguen una jerarquía (de menor a mayor): SSL 3.0, TLS 1.0, TLS 1.1 y TLS 1.2. Debe especificar la versión mínima permitida; se permitirán todas las conexiones que usen esa versión del protocolo o una versión más alta.

  Por ejemplo, si especifica TLS 1.1 como la versión mínima, se permitirán conexiones con TLS 1.1 y TLS 1.2. Si elige SSL 3.0 como la versión mínima, se permitirán conexiones con todas las versiones admitidas. Si especifica TLS 1.2 como la versión mínima, solo se permiten conexiones con TLS 1.2.

  DTLS 1.0 corresponde a TLS 1.1, mientras que DTLS 1.2 corresponde a TLS 1.2.

• Qué conjuntos de cifrado TLS se deben permitir.

  El conjunto de cifrado selecciona el cifrado que se usa para una conexión. Los clientes y los agentes VDA pueden admitir varios grupos diferentes de conjuntos de cifrado. Cuando un cliente (la aplicación Citrix Workspace o StoreFront) se conecta y envía una lista de los conjuntos de cifrado TLS compatibles, el VDA asigna uno de los conjuntos de cifrado del cliente a uno de los conjuntos de cifrado en su propia lista de conjuntos de cifrado configurados y acepta la conexión. Si no encaja ningún conjunto de cifrado, el VDA rechazará la conexión.

  El VDA admite tres grupos de conjuntos de cifrado (también conocidos como modos de conformidad): GOV (Government o Gobierno), COM (Commercial o Comercial) y ALL (Todos). Los conjuntos de cifrado que se aceptan 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 tabla siguiente muestra los conjuntos de cifrado en cada grupo:

* No se admite en 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 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Si Windows lo selecciona, es posible que Receiver no los utilice.

Si utiliza Citrix Gateway, consulte la documentación de Citrix ADC para obtener información sobre la disponibilidad del conjunto de cifrado para la comunicación back-end. Para obtener información sobre la disponibilidad del conjunto de cifrado TLS, consulte Cifrados disponibles en los dispositivos Citrix ADC. Para obtener información sobre la disponibilidad del conjunto de cifrado DTLS, consulte Compatibilidad con cifrado DTLS.

Solicitar e instalar un certificado

1. En el VDA, abra la consola de MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.
2. Expanda Personal > Certificados y, a continuación, utilice el comando de menú contextual Todas las tareas > Solicitar un nuevo certificado.
3. Haga clic en Siguiente para comenzar y en Siguiente para confirmar que va a adquirir el certificado de inscripción en Active Directory.

4. Seleccione la plantilla para Certificado de autenticación de servidor. Tanto el equipo Windows predeterminado como el servidor web exportable son aceptables. Si la plantilla se ha configurado para proporcionar automáticamente los valores para Asunto, puede hacer clic en Inscribir sin proporcionar más datos.

   

5. 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 nombre de dominio completo (FQDN) del VDA

   Nombre alternativo: Seleccione el tipo DNS y agregue el FQDN del VDA

   

   Nota:

   Use la función de inscripción automática de certificados de Servicios de certificados de Active Directory para automatizar la emisión y la 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 cubra varios VDA:

   Nombre del sujeto: Seleccione el tipo Nombre común e introduzca el dominio *.primary.domain de los VDA

   Nombre alternativo: Seleccione el tipo DNS y agregue el dominio *.primary.domain de los VDA

   

   Puede usar certificados SAN para permitir que un solo certificado cubra diversos VDA específicos:

   Nombre del sujeto: Seleccione el tipo Nombre común e introduzca una cadena que ayude a identificar el uso del certificado

   Nombre alternativo: Seleccione el tipo DNS y agregue una entrada para el FQDN de cada VDA. Mantenga el número de nombres alternativos al mínimo para garantizar una negociación de TLS óptima.

   

   Nota:

   Tanto los certificados comodín como los certificados SAN requieren que se seleccione Hacer exportable la clave privada en la ficha Clave privada:

   

Configurar TLS en un VDA mediante el script de PowerShell

Instale el certificado TLS en Equipo local > Personal > área 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 busca el certificado correcto basándose en el nombre de dominio completo del VDA. No es necesario facilitar la huella digital cuando existe solo un certificado para el FQDN del VDA.

El script Enable-VdaSSL.ps1 habilita o inhabilita la escucha de TLS en un VDA. Este script está disponible en la carpeta Support > Tools > SslSupport de los medios de instalación.

Cuando habilita TLS, los conjuntos de cifrado DHE se inhabilitan. Los conjuntos de cifrado ECDHE no se ven afectados.

Al habilitar TLS, el script inhabilita todas las reglas de Firewall de Windows para el puerto TCP especificado. A continuación, agrega una nueva regla que permite al servicio ICA aceptar conexiones entrantes solo en los puertos UDP y TCP de TLS. También inhabilita las reglas de Firewall de Windows para:

• Citrix ICA (predeterminado: 1494)
• Citrix CGP (predeterminado: 2598)
• Citrix WebSocket (predeterminado: 8008)

La consecuencia es que los usuarios solo pueden conectarse con TLS o DTLS. No pueden usar ICA/HDX, ICA/HDX con fiabilidad de la sesión o HDX por WebSocket, sin TLS o DTLS.

Nota:

No se admite el protocolo DTLS con audio ICA/HDX por protocolo UDP de transporte 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 consultar esta información.

Importante:

Debe indicar el parámetro Enable o Disable, así como el parámetro CertificateThumbPrint. Los demás parámetros son opcionales.

Sintaxis

Transport Layer Security (TLS)

Citrix Virtual Apps and Desktops admiten el protocolo Transport Layer Security (TLS) para las conexiones por TCP entre los componentes. Citrix Virtual Apps and Desktops también admiten el protocolo Datagram Transport Layer Security (DTLS) para las conexiones ICA o HDX por UDP cuando se utiliza el transporte adaptable.

TLS y DTLS son similares y admiten los mismos certificados digitales. Configurar un sitio Citrix Virtual Apps o Citrix Virtual Desktops para usar TLS también lo configura para usar DTLS. Siga estos procedimientos; son los mismos pasos tanto para TLS como para DTLS (excepto donde se indique):

• Obtener, instalar y registrar un certificado de servidor en todos los Delivery Controllers y configurar un puerto con el certificado TLS. Para obtener más información, consulte Instalar certificados de servidor TLS en los Controllers.

  Si lo quiere, puede cambiar los puertos que Controller utiliza para escuchar el tráfico HTTP y HTTPS.

• Habilite las conexiones TLS entre la aplicación Citrix Workspace y los agentes VDA (Virtual Delivery Agent) completando las siguientes tareas:

  • Configure TLS en las máquinas donde los VDA están instalados. (Para simplificar, en adelante se usará “VDA” para hacer referencia a la máquina donde está instalado un VDA.) Para obtener información general, consulte Parámetros de TLS en los VDA. Se recomienda que utilice el script de PowerShell suministrado por Citrix para configurar TLS o DTLS. Para obtener información detallada, consulte Configurar TLS en un VDA mediante el script de PowerShell. Sin embargo, si quiere configurar TLS o DTLS manualmente, consulte Configurar TLS manualmente en un VDA.

  • Configure TLS en los grupos de entrega que contienen los VDA mediante la ejecución de un conjunto de cmdlets de PowerShell en Studio. Para obtener más información, consulte Configuración de TLS en los grupos de entrega.

    Requisitos y consideraciones:

    • El hecho de habilitar conexiones TLS entre los usuarios y los VDA solo es válido para los sitios de XenApp 7.6 y XenDesktop 7.6 y 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 a los Controllers. Un administrador total tiene este permiso.
    • Para configurar TLS en los VDA, debe ser un administrador Windows en la máquina donde está instalado el VDA.
    • En agentes VDA agrupados y aprovisionados por Machine Creation Services o Provisioning Services, la imagen de la máquina del VDA se restablece en el proceso de reinicio, lo que provoca la pérdida de la configuración anterior de TLS. Ejecute el script de PowerShell cada vez que se reinicie el VDA para volver a configurar los parámetros de TLS.

Advertencia:

Para las tareas que impliquen modificar el Registro de Windows, tenga cuidado: si se modifica de forma incorrecta, pueden producirse problemas graves que obliguen a reinstalar el sistema operativo. Citrix no puede garantizar que los problemas derivados de la utilización inadecuada del Editor del Registro puedan resolverse. Si utiliza el Editor del Registro, será bajo su propia responsabilidad. Haga una copia de seguridad del Registro antes de modificarlo.

Para obtener información acerca de la habilitación de TLS para la base de datos del sitio, consulte CTX137556.

Instalar certificados de servidor TLS en los Controllers

Para HTTPS, XML Service admite las funciones de TLS cuando se usan certificados de servidor, no cuando se usan certificados de cliente. En esta sección, se describe la adquisición e instalación de certificados TLS en Delivery Controllers. Los mismos pasos se pueden aplicar a Cloud Connectors para cifrar el tráfico STA y XML.

Aunque hay varios tipos diferentes de entidades de certificación y métodos para solicitar certificados de ellas, en este artículo se describe la entidad emisora de certificados de Microsoft. La entidad de certificación de Microsoft debe tener una plantilla de certificado publicada con el propósito Autenticación de servidor.

Si la entidad 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, se puede adquirir un certificado desde el asistente para inscripción de certificados del complemento MMC Certificados.

Solicitar e instalar un certificado

1. En el Delivery Controller, abra la consola de MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.

2. Expanda Personal > Certificados y, a continuación, utilice la opción de menú contextual Todas las tareas > Solicitar un nuevo certificado.

   

3. Haga clic en Siguiente para comenzar y en Siguiente para confirmar que va a adquirir el certificado de inscripción en Active Directory.

4. Seleccione la plantilla para 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 datos.

   

5. 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 agregue el FQDN del Delivery Controller.

   

Configurar el puerto de escucha SSL/TLS

1. Abra una ventana de comandos de PowerShell como administrador de la máquina.

2. Ejecute los siguientes comandos para obtener el GUID de aplicación de Broker Service:

   <!JEKYLL@5260@0>

3. Ejecute los siguientes comandos en la misma ventana de PowerShell para obtener la huella digital del certificado que instaló anteriormente:

   <!JEKYLL@5260@1>

4. Ejecute los siguientes comandos en la misma ventana de PowerShell para configurar el puerto SSL/TLS de Broker Service y usar el certificado para el cifrado:

   <!JEKYLL@5260@2>

Cuando se configura correctamente, el resultado del último comando <!JEKYLL@5260@3> muestra que el agente de escucha utiliza el <!JEKYLL@5260@4> correcto y que <!JEKYLL@5260@5> es el GUID de aplicación de Broker Service.

Si los servidores confían en el certificado instalado en los Delivery Controllers, ahora puede configurar los vínculos de Delivery Controllers de StoreFront y Citrix Gateway STA para que utilicen HTTPS, en lugar de HTTP.

Nota:

Si el Controller está instalado en Windows Server 2016 o Windows Server 2019, y StoreFront está instalado en Windows Server 2012 R2, es necesario cambiar la configuración en el Controller o en StoreFront para cambiar el orden de los conjuntos de cifrado TLS. Este cambio de configuración no es necesario para Controller ni StoreFront con otras combinaciones de versiones de Windows Server.

La lista ordenada de los conjuntos de cifrado debe incluir el conjunto de cifrado <!JEKYLL@5260@6> o <!JEKYLL@5260@7> (o ambos) o conjuntos de cifrado TLS_ECDHE similares, y estos conjuntos deben preceder los conjuntos de cifrado TLS_DHE.

1. Desde el editor de directivas de grupo de Microsoft, vaya a Configuración del equipo > Plantillas administrativas > Red > Opciones de configuración SSL.
2. Modifique la directiva “Orden de conjuntos de cifrado SSL”. De manera predeterminada, esta directiva está establecida en “No configurada”. Habilite esta directiva.
3. Ordene los conjuntos de cifrado; quite aquellos conjuntos que no quiera usar.

Compruebe que <!JEKYLL@5260@8>, <!JEKYLL@5260@9> o un conjunto de cifrado TLS_ECDHE similar preceda los conjuntos de cifrado TLS_DHE.

En Microsoft MSDN, también puede consultar Prioritizing Schannel Cipher Suites.

Cambiar puertos HTTP o HTTPS

De forma predeterminada, el XML Service en el Controller escucha en los puertos 80 para el tráfico HTTP y 443 para el tráfico HTTPS. Aunque se pueden utilizar otros puertos distintos de los predeterminados, tenga en cuenta los riesgos de seguridad que implica la exposición de un Controller a redes que no son de confianza. Antes que cambiar los valores predeterminados, es preferible implementar un servidor de StoreFront independiente.

Para cambiar los puertos HTTP o HTTPS predeterminados que usa el Controller, ejecute el comando siguiente en Studio:

BrokerService.exe -WIPORT <puerto http> -WISSLPORT <puerto https>

<puerto http> es el número de puerto para el tráfico HTTP y <puerto https> es el número de puerto para el tráfico HTTPS.

Nota:

Después de cambiar de un puerto, Studio puede mostrar un mensaje acerca de la actualización y la compatibilidad de licencias. Para resolver el problema, vuelva a registrar las instancias de servicio mediante esta secuencia de cmdlet de PowerShell:

<!JEKYLL@5260@10>

Solo aplicar el tráfico HTTPS

Si quiere que XML Service ignore el tráfico HTTP, cree el siguiente parámetro de Registro en HKLM\Software\Citrix\DesktopServer\ en el Controller y reinicie el Broker Service.

Para ignorar el tráfico HTTP, cree DWORD XmlServicesEnableNonSsl y dele el valor 0.

Se puede crear el valor DWORD de Registro correspondiente para ignorar el tráfico HTTPS: DWORD XmlServicesEnableSsl. Compruebe que no está establecido en 0.

Parámetros de TLS en agentes VDA

Un grupo de entrega no puede incluir una mezcla de VDA con TLS configurado y VDA sin TLS configurado. Antes de configurar TLS para un grupo de entrega, debe haber configurado TLS para todos los VDA en ese grupo de entrega.

Si configura TLS en los VDA, cambian los permisos en el certificado TLS instalado, lo que da 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 hay que usar para TLS.

• Qué número de puerto TCP hay que usar para las conexiones TLS.

  El Firewall de Windows (si está habilitado) debe estar configurado para permitir conexiones entrantes en este puerto TCP. Esta configuración se lleva a cabo cuando se usa el script de PowerShell.

• Qué versiones del protocolo TLS se deben permitir.

  Importante:

  Citrix recomienda revisar el uso de SSL 3 y volver a configurar las implementaciones para retirar la compatibilidad con SSL 3 donde corresponda. Consulte CTX200238.

  Las versiones compatibles con el protocolo TLS siguen una jerarquía (de menor a mayor): SSL 3.0, TLS 1.0, TLS 1.1 y TLS 1.2. Debe especificar la versión mínima permitida; se permitirán todas las conexiones que usen esa versión del protocolo o una versión más alta.

  Por ejemplo, si especifica TLS 1.1 como la versión mínima, se permitirán conexiones con TLS 1.1 y TLS 1.2. Si elige SSL 3.0 como la versión mínima, se permitirán conexiones con todas las versiones admitidas. Si especifica TLS 1.2 como la versión mínima, solo se permiten conexiones con TLS 1.2.

  DTLS 1.0 corresponde a TLS 1.1, mientras que DTLS 1.2 corresponde a TLS 1.2.

• Qué conjuntos de cifrado TLS se deben permitir.

  El conjunto de cifrado selecciona el cifrado que se usa para una conexión. Los clientes y los agentes VDA pueden admitir varios grupos diferentes de conjuntos de cifrado. Cuando un cliente (la aplicación Citrix Workspace o StoreFront) se conecta y envía una lista de los conjuntos de cifrado TLS compatibles, el VDA asigna uno de los conjuntos de cifrado del cliente a uno de los conjuntos de cifrado en su propia lista de conjuntos de cifrado configurados y acepta la conexión. Si no encaja ningún conjunto de cifrado, el VDA rechazará la conexión.

  El VDA admite tres grupos de conjuntos de cifrado (también conocidos como modos de conformidad): GOV (Government o Gobierno), COM (Commercial o Comercial) y ALL (Todos). Los conjuntos de cifrado que se aceptan 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 tabla siguiente muestra los conjuntos de cifrado en cada grupo:

* No se admite en Windows Server 2012 R2.

Nota:

El VDA no admite conjuntos de cifrado DHE (por ejemplo, <!JEKYLL@5260@14>, <!JEKYLL@5260@15>, <!JEKYLL@5260@16> o <!JEKYLL@5260@17>). Si Windows lo selecciona, es posible que Receiver no los utilice.

Si utiliza Citrix Gateway, consulte la documentación de Citrix ADC para obtener información sobre la disponibilidad del conjunto de cifrado para la comunicación back-end. Para obtener información sobre la disponibilidad del conjunto de cifrado TLS, consulte Cifrados disponibles en los dispositivos Citrix ADC. Para obtener información sobre la disponibilidad del conjunto de cifrado DTLS, consulte Compatibilidad con cifrado DTLS.

Solicitar e instalar un certificado

1. En el VDA, abra la consola de MMC y agregue el complemento Certificados. Cuando se le solicite, seleccione Cuenta de equipo.
2. Expanda Personal > Certificados y, a continuación, utilice el comando de menú contextual Todas las tareas > Solicitar un nuevo certificado.
3. Haga clic en Siguiente para comenzar y en Siguiente para confirmar que va a adquirir el certificado de inscripción en Active Directory.

4. Seleccione la plantilla para Certificado de autenticación de servidor. Tanto el equipo Windows predeterminado como el servidor web exportable son aceptables. Si la plantilla se ha configurado para proporcionar automáticamente los valores para Asunto, puede hacer clic en Inscribir sin proporcionar más datos.

   

5. 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 nombre de dominio completo (FQDN) del VDA

   Nombre alternativo: Seleccione el tipo DNS y agregue el FQDN del VDA

   

   Nota:

   Use la función de inscripción automática de certificados de Servicios de certificados de Active Directory para automatizar la emisión y la 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 cubra varios VDA:

   Nombre del sujeto: Seleccione el tipo Nombre común e introduzca el dominio *.primary.domain de los VDA

   Nombre alternativo: Seleccione el tipo DNS y agregue el dominio *.primary.domain de los VDA

   

   Puede usar certificados SAN para permitir que un solo certificado cubra diversos VDA específicos:

   Nombre del sujeto: Seleccione el tipo Nombre común e introduzca una cadena que ayude a identificar el uso del certificado

   Nombre alternativo: Seleccione el tipo DNS y agregue una entrada para el FQDN de cada VDA. Mantenga el número de nombres alternativos al mínimo para garantizar una negociación de TLS óptima.

   

   Nota:

   Tanto los certificados comodín como los certificados SAN requieren que se seleccione Hacer exportable la clave privada en la ficha Clave privada:

   

Configurar TLS en un VDA mediante el script de PowerShell

Instale el certificado TLS en Equipo local > Personal > área 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 busca el certificado correcto basándose en el nombre de dominio completo del VDA. No es necesario facilitar la huella digital cuando existe solo un certificado para el FQDN del VDA.

El script Enable-VdaSSL.ps1 habilita o inhabilita la escucha de TLS en un VDA. Este script está disponible en la carpeta Support > Tools > SslSupport de los medios de instalación.

Cuando habilita TLS, los conjuntos de cifrado DHE se inhabilitan. Los conjuntos de cifrado ECDHE no se ven afectados.

Al habilitar TLS, el script inhabilita todas las reglas de Firewall de Windows para el puerto TCP especificado. A continuación, agrega una nueva regla que permite al servicio ICA aceptar conexiones entrantes solo en los puertos UDP y TCP de TLS. También inhabilita las reglas de Firewall de Windows para:

• Citrix ICA (predeterminado: 1494)
• Citrix CGP (predeterminado: 2598)
• Citrix WebSocket (predeterminado: 8008)

La consecuencia es que los usuarios solo pueden conectarse con TLS o DTLS. No pueden usar ICA/HDX, ICA/HDX con fiabilidad de la sesión o HDX por WebSocket, sin TLS o DTLS.

Nota:

No se admite el protocolo DTLS con audio ICA/HDX por protocolo UDP de transporte 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 consultar esta información.

Importante:

Debe indicar el parámetro Enable o Disable, así como 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>”]`

Ejemplos

El siguiente script instala y habilita el valor de versión del protocolo TLS. La huella digital (representada como “12345678987654321” en este ejemplo) se utiliza para seleccionar el certificado que se utilizará.

Enable-VdaSSL –Enable -CertificateThumbPrint "12345678987654321"

El siguiente script instala y habilita la escucha de TLS, y especifica el puerto TLS 400, el conjunto de cifrado GOV y una versión de protocolo mínima de TLS 1.2. La huella digital (representada como “12345678987654321” en este ejemplo) se utiliza para seleccionar el certificado que se utilizará.

Enable-VdaSSL – Enable
-CertificateThumbPrint "12345678987654321"
–SSLPort 400 –SSLMinVersion "TLS_1.2"
–SSLCipherSuite "All"

El siguiente script inhabilita la escucha de TLS en el VDA.

Enable-VdaSSL –Disable

Configurar TLS manualmente en un VDA

Al configurar manualmente TLS en un VDA, se concede acceso genérico de lectura a la clave privada del certificado TLS para el servicio apropiado en cada VDA: NT SERVICE\PorticaService para un VDA de SO de sesión única Windows o NT SERVICE\TermService para un VDA de SO multisesión Windows. En la máquina donde está instalado el VDA:

PASO 1. Abra la consola Microsoft Management Console (MMC): Inicio > Ejecutar > mmc.exe.

PASO 2. Agregue el complemento Certificados en la consola MMC:

1. Seleccione Archivo > Agregar o quitar complemento.
2. Seleccione Certificados y haga clic en Agregar.
3. En “Este complemento administrará siempre certificados de”, elija “Cuenta de equipo” y luego haga clic en “Siguiente”.
4. En “Seleccione el equipo que desea administrar con 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 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)”, donde (nombre) es el nombre del certificado TLS. Agregue uno de los siguientes servicios y dele acceso de lectura:

• Para un VDA con SO de sesión única de Windows, “PORTICASERVICE”
• Para un VDA con SO multisesión 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 vaya a la parte inferior. Haga clic en Huella digital.

PASO 6. Ejecute regedit y vaya a HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.

1. Modifique la clave de huella digital SSL Thumbprint y copie en el valor binario la huella digital que figura en el certificado TLS. Puede ignorar los elementos desconocidos del diálogo Modificar valor binario (por ejemplo, ‘0000’ y los caracteres especiales).
2. Modifique la clave SSLEnabled y cambie el valor DWORD a 1 (para inhabilitar SSL más adelante, cambie el valor DWORD a 0).

3. Si quiere cambiar la configuración predeterminada (optativo), use lo siguiente en la misma ruta de Registro:

   SSLPort DWORD – número de puerto SSL. Valor predeterminado: 443.

   SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Valor predeterminado: 2 (TLS 1.0).

   SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Valor predeterminado: 3 (ALL).

PASO 7. Compruebe que los puertos UDP y TCP de TLS están abiertos en el Firewall de Windows, si no son el predeterminado 443 (cuando cree la regla de entrada en el Firewall de Windows, compruebe que tenga seleccionadas las entradas “Permitir la conexión” y “Habilitada” en las propiedades).

PASO 8. Asegúrese de que no hay otros servicios o aplicaciones (por ejemplo, IIS) que estén utilizando el puerto TCP de TLS.

PASO 9. Para los VDA para SO multisesión Windows, reinicie la máquina para que los cambios tengan efecto (no es necesario reiniciar las máquinas que contienen los VDA para SO de sesión única Windows).

Importante:

Se necesita un paso adicional si el VDA está en Windows Server 2012 R2, Windows Server 2016, o bien en Windows 10 Anniversary Edition o una versión posterior compatible. Esto afecta a las conexiones procedentes de la aplicación Citrix Workspace para HTML5 y la aplicación Citrix Workspace para Chrome. También se incluyen las conexiones a través de Citrix Gateway.

Este paso también es necesario para todas las conexiones que pasan por Citrix Gateway, para todas las versiones de VDA, si TLS entre Citrix Gateway y el VDA está configurado.

En el VDA (Windows Server 2012 R2, Windows Server 2016 o Windows 10 Anniversary Edition o versiones posteriores), mediante el Editor de directivas de grupo, vaya a Configuración del equipo > Directivas > Plantillas administrativas > Red > Opciones de configuración SSL > Orden de conjuntos de cifrado SSL. Seleccione el orden siguiente:

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 indican una curva elíptica, P384 o P256. Compruebe que la opción “curve25519” no está seleccionada. El modo FIPS no impide el uso de “curve25519”.

Cuando esta configuración de la directiva de grupo esté configurada, el VDA selecciona un conjunto de cifrado solo si aparece en las dos listas: la lista de la directiva de grupo y la lista del modo de conformidad seleccionado (COM, GOV o ALL). El conjunto de cifrado también debe aparecer en la lista que envíe el cliente (la aplicación Citrix Workspace o StoreFront).

Esta configuración de directiva de grupo también afecta a otras aplicaciones y servicios TLS del VDA. Si sus aplicaciones requieren conjuntos de cifrado determinados, deberá agregarlos a la lista de esta 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 tienen efecto después de reiniciar el sistema operativo. Por lo tanto, para escritorios agrupados, los cambios de directiva de grupo referentes a la configuración de TLS se deben aplicar a la imagen base.

Configurar TLS en grupos de entrega

Lleve a cabo este procedimiento para cada grupo de entrega que contenga VDA configurados para conexiones TLS.

1. Desde Studio, abra la consola de PowerShell.
2. Ejecute asnp Citrix.* para cargar los cmdlets de producto Citrix.
3. Ejecute Get-BrokerAccessPolicyRule -DesktopGroupName ‘<nombre del grupo de entrega>’ | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.
4. Ejecute Set-BrokerSite -DnsResolutionEnabled $true.

Solución de problemas

Si se produce un error de conexión, consulte el registro de eventos del sistema en el VDA.

Cuando usa la aplicación Citrix Workspace para Windows, si recibe un error de conexión que indica un error de TLS, inhabilite Desktop Viewer y, a continuación, intente conectarse de nuevo. Aunque la conexión siga fallando, podrá obtener una explicación del problema de TLS subyacente. Por ejemplo, que especificó una plantilla incorrecta al solicitar un certificado de la entidad de certificación.)

La mayoría de las configuraciones que usan el transporte adaptable HDX funcionan con DTLS, incluidas las que utilizan las versiones más recientes de la aplicación Citrix Workspace, Citrix Gateway y VDA. Algunas configuraciones que usan DTLS entre la aplicación Citrix Workspace y Citrix Gateway, y que usan DTLS entre Citrix Gateway y el VDA, requieren configuración adicional.

Es necesario adoptar medidas adicionales si se producen estos casos:

• La versión de Citrix Gateway admite DTLS al VDA, pero la versión de VDA no admite DTLS (7.15 o anterior)

• La versión de VDA admite DTLS (7.16 o una versión posterior), pero la versión de Citrix Gateway no admite DTLS al VDA

Para evitar errores en las conexiones, lleve a cabo una de estas acciones:

• Actualice Citrix Gateway a una versión que admita DTLS al VDA.
• Actualice el VDA a la versión 7.16 o a una posterior.
• Inhabilite DTLS en el VDA.
• Inhabilite el transporte adaptable HDX.

Nota:

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

Con su protección de mensajes, Windows Communication Framework (WCF) protege la comunicación entre el Controller y el VDA. No se necesita protección adicional de transporte mediante el protocolo TLS. La configuración de WCF usa Kerberos para la autenticación mutua entre el Controller y el VDA. Para el cifrado, se usa AES en el modo CBC con una clave de 256 bits. Para la integridad de los mensajes, se usa SHA-1.

Según Microsoft, los Protocolos de seguridad que utiliza WCF cumplen los estándares de OASIS (Organization for the Advancement of Structured Information Standards), incluidos los WS-SecurityPolicy 1.2. Además, Microsoft afirma que WCF admite todos los conjuntos de algoritmos que constan en Security Policy 1.2.

La comunicación entre el Controller y el VDA usa el conjunto de algoritmos basic256, cuyos algoritmos son como se ha señalado anteriormente.

TLS, la redirección de vídeo HTML5 y la redirección de contenido del explorador web

Puede usar la redirección de vídeo HTML5 y la redirección de contenido del explorador web para redirigir los sitios web HTTPS. El JavaScript insertado en esos sitios web debe establecer una conexión TLS al servicio Citrix HDX HTML5 Video Redirection Service que se ejecuta en el VDA. Para ello, HTML5 Video Redirection Service genera dos certificados personalizados en el almacén de certificados presente en el VDA. Al detener este servicio, también se quitan los certificados.

La directiva de redirección de vídeo HTML5 está inhabilitada de forma predeterminada.

En cambio, la redirección de contenido del explorador web está habilitada de forma predeterminada.

Para obtener más información sobre la redirección de vídeos HTML5, consulte Configuraciones de directiva de Multimedia.