Horizon Client: error de certificado y fallos por Wi-Fi

Hay dos fallos que arruinan la mañana a quien administra o usa Horizon: el cliente protesta por el certificado del servidor y no deja continuar, o todo funciona con cable y se rompe al pasar a una red Wi-Fi. A menudo son el mismo problema visto desde ángulos distintos, y se resuelven con un método ordenado en lugar de probar cosas al azar.

Un apunte sobre el nombre. Lo que durante años se llamó VMware Horizon es hoy Omnissa Horizon, desde que la división de informática de usuario final se separó de VMware. El producto y los mensajes de error son los mismos, así que esta guía vale tanto si tu cliente aún dice VMware como si ya dice Omnissa. Los puertos, rutas y nombres de menús que aparecen aquí se basan en la documentación pública del fabricante y pueden variar un poco con la versión; compruébalos en tu entorno antes de cambiar nada en producción. Si no tienes claro qué es un escritorio virtual de este tipo, empieza por qué es VDI y cómo funciona.

Primero, averigua en qué fase falla

Una conexión de Horizon tiene dos fases, y los síntomas son distintos en cada una:

Verificación del servidor y autenticación. El cliente se conecta por HTTPS al servidor de conexión (o a la pasarela de acceso), comprueba su certificado y te pide usuario y contraseña. Si el fallo aparece nada más escribir la dirección del servidor, y habla de certificado o de identidad del servidor, estás en esta fase.
Conexión con el escritorio. Ya has iniciado sesión y ves la lista de escritorios, pero al abrir uno la pantalla se queda en negro, aparece un mensaje de que no se puede conectar con el escritorio o la sesión se corta a los pocos segundos. Aquí el culpable suele ser el protocolo de pantalla y los puertos.

Esta distinción ahorra mucho tiempo: los errores de certificado no se resuelven tocando puertos, y los cortes de pantalla no se resuelven cambiando certificados.

Errores de certificado

Qué comprueba el cliente

El cliente de Horizon valida el certificado del servidor de la misma forma que un navegador. Falla si el certificado ha caducado, si el nombre al que te conectas no figura en él, si la autoridad que lo emitió no es de confianza en tu equipo o si la cadena de certificados está incompleta. El comportamiento ante el fallo depende del modo de comprobación configurado en el cliente:

No conectar nunca a servidores que no sean de confianza. Si falla cualquier comprobación, no puedes conectar y el mensaje indica qué comprobaciones han fallado.
Advertir antes de conectar a servidores que no sean de confianza. Puedes continuar tras ver el aviso, lo que es habitual cuando el servidor usa un certificado autofirmado. También avisa si el certificado ha caducado.
No verificar los certificados de identidad del servidor. No se hace ninguna comprobación. Es cómodo, pero deja la conexión sin protección frente a un servidor falso. No lo uses como solución, solo como prueba temporal para confirmar que el problema es el certificado.

En el cliente de Windows, este ajuste está en el menú de opciones, en la configuración de SSL. La descripción oficial de cada modo está en la documentación de Omnissa.

Causas habituales y su arreglo

El nombre no coincide. Si te conectas por IP o por un nombre corto y el certificado se emitió para horizon.empresa.com, la validación falla. Usa siempre el nombre completo que aparece en el certificado, y comprueba que está en el campo de nombres alternativos del sujeto (SAN).
Cadena incompleta. El servidor debe enviar su certificado y los intermedios. Si falta un intermedio, algunos equipos lo resuelven por su cuenta y otros no, y por eso el fallo parece aleatorio. Instala la cadena completa en el servidor.
La entidad emisora no es de confianza. Con una autoridad de certificación interna, el certificado raíz tiene que estar instalado en los equipos cliente. En un dominio se distribuye con una directiva de grupo; en equipos externos hay que instalarlo a mano.
Certificado caducado o revocado. Parece obvio, pero es la causa número uno de las caídas «de la noche a la mañana». Anota las fechas de caducidad en un calendario.
Fecha y hora del cliente incorrectas. Un equipo con la hora desajustada considera caducado un certificado válido. Comprueba la sincronización con w32tm /query /status.
Inspección TLS en el cortafuegos o el proxy. Algunos cortafuegos sustituyen el certificado del servidor por uno propio para poder inspeccionar el tráfico. En la red corporativa los equipos confían en esa entidad, pero en una red Wi-Fi de invitados no, y por eso el error aparece solo ahí.
Certificado por defecto del servidor de conexión. Si nunca se reemplazó el certificado autofirmado de instalación, los clientes no tienen forma de validarlo. Instala un certificado de una autoridad de confianza.
Nombre descriptivo del certificado. En el servidor de conexión de Horizon, el certificado que debe usar el servicio tiene que tener como nombre descriptivo (friendly name) el valor vdm. Si importaste el certificado y el servidor sigue ofreciendo el antiguo, comprueba este detalle, y reinicia después el servicio del servidor de conexión.
Balanceador o pasarela con su propio certificado. Si hay un balanceador de carga o una pasarela de acceso delante, el certificado que ven los clientes es el de ese dispositivo, no el del servidor de conexión.

Cómo inspeccionar el certificado que está viendo el cliente

Antes de cambiar nada, mira qué certificado se está presentando de verdad. Con PowerShell puedes descargarlo desde el propio equipo que falla:

$h = 'horizon.empresa.com'
$tcp = New-Object Net.Sockets.TcpClient($h, 443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient($h)
$cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)
$cert | Format-List Subject, Issuer, NotBefore, NotAfter, Thumbprint
($cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq 'Subject Alternative Name' }).Format($true)
$tcp.Close()

Cambia horizon.empresa.com por tu servidor. Comprueba tres cosas: que el emisor es el que esperas, que las fechas son válidas y que tu nombre aparece en el campo de nombres alternativos. Si el emisor es el de tu cortafuegos o el de otra red, ya tienes la causa. Para validar la cadena y la revocación de un certificado exportado, usa:

certutil -verify -urlfetch certificado.cer

Funciona con cable y falla con Wi-Fi

Cuando la autenticación funciona y el problema aparece al abrir el escritorio, hay que mirar el protocolo de visualización y la red. Horizon usa distintos protocolos y cada uno necesita unos puertos. Esta tabla recoge los habituales, según la documentación del fabricante; los números exactos dependen de tu arquitectura (túnel, balanceadores, pasarela de acceso):

Servicio	Puerto	Observaciones
Autenticación y comprobación del servidor	TCP 443	Es la primera fase; si falla aquí, es un asunto de certificado o de acceso al servidor
Blast Extreme	TCP y UDP 8443 (directo); 443 si pasa por pasarela o túnel	El protocolo más habitual en redes con restricciones
PCoIP	TCP y UDP 4172	Muy sensible a bloqueos de UDP
RDP	TCP 3389	Si se permite como protocolo
Redirección USB	TCP 32111	Solo para dispositivos USB

Por qué el Wi-Fi marca la diferencia

La red inalámbrica es distinta de la de cable en cosas que no se ven a simple vista:

Redes de invitados y portales cautivos. Muchas bloquean UDP o los puertos que no son estándar. El protocolo de pantalla abre una conexión nueva al escritorio, y esa es la que se rechaza.
Aislamiento de clientes y filtrado. Algunas redes impiden conexiones entre dispositivos o limitan los destinos permitidos.
DNS distinto. En la red de cable puede que el nombre del servidor resuelva a una dirección interna, y en el Wi-Fi a otra distinta, o a ninguna. Comprueba con nslookup horizon.empresa.com desde cada red.
VPN y proxy. Un cliente de VPN o un proxy en el Wi-Fi puede interceptar o reencaminar el tráfico y cortar las conexiones UDP.
Calidad de la señal. Pérdida de paquetes y cambios de punto de acceso cortan la sesión de pantalla y se manifiestan como desconexiones.
Ahorro de energía del adaptador. Windows puede apagar parcialmente el adaptador Wi-Fi. Desmarca la opción de permitir que el equipo lo apague en las propiedades del adaptador, pestaña Administración de energía.

Pruebas rápidas, en este orden

Comprueba que el puerto 443 responde. Desde el equipo con el problema, ejecuta Test-NetConnection horizon.empresa.com -Port 443. Si da TcpTestSucceeded: False, es un problema de red previo a Horizon.
Cambia el protocolo de pantalla. En el cliente, abre las opciones del escritorio y elige Blast Extreme en lugar de PCoIP, o al revés. Una red restrictiva suele dejar pasar el tráfico TCP por 443 aunque bloquee UDP. Te servirá además para saber si el problema es el protocolo.
Prueba otra red. Un punto de acceso de móvil es una buena prueba: si funciona con el móvil y no con la Wi-Fi de la oficina, el problema está en esa red y hay que revisar el cortafuegos.
Prueba sin VPN. Desconecta cualquier VPN o proxy y repite.
Comprueba el tamaño de paquete. Con ping -f -l 1400 horizon.empresa.com detectas problemas de fragmentación. Si no responde, reduce el tamaño hasta que lo haga y compara.

Un detalle: Test-NetConnection solo prueba TCP. No puede comprobar UDP, así que para validar ese tráfico la forma práctica es cambiar de protocolo y observar el comportamiento.

Otras causas frecuentes

Versión del cliente. Un cliente muy antiguo puede no ser compatible con un servidor de conexión actual. Actualiza el cliente desde el sitio oficial.
Sesión anterior atascada. Si el escritorio indica que tu sesión sigue activa, restablece el escritorio desde el cliente o cierra la sesión del usuario desde el servidor. Si necesitas hacerlo por línea de comandos, tienes los pasos en cerrar la sesión de un usuario de forma remota.
Agente del escritorio. Si el escritorio virtual no responde, el agente instalado en él puede estar parado. Reinicia el escritorio desde el administrador.
Fallos de autenticación previos a RDP. Si el escritorio acaba conectando por RDP, pueden aparecer errores de nivel de red, como los descritos en la guía de NLA, o el aviso de error interno de Escritorio remoto.

Dónde mirar los registros

Si las pruebas anteriores no aclaran nada, los registros dicen más que cualquier suposición:

Cliente: en la carpeta temporal del usuario (%TEMP%) se crean carpetas cuyo nombre empieza por vmware con los registros del cliente. La ruta exacta puede cambiar según la versión.
Servidor de conexión: los registros suelen estar en C:\ProgramData\VMware\VDM\logs, e indican por qué se rechaza una conexión o cuál es el certificado que se está usando.
Cortafuegos: si el fallo aparece solo en algunas redes, los registros del cortafuegos muestran si se bloquea el tráfico y a qué puerto.

Lista de comprobación

¿El error aparece al escribir el servidor (certificado) o al abrir el escritorio (protocolo y red)?
¿El nombre usado coincide con el certificado, y la cadena y las fechas son correctas?
¿La hora del cliente es la correcta?
¿El cortafuegos o el proxy de esa red sustituye el certificado?
¿Funciona desde otra red o con otro protocolo de pantalla?
¿El DNS devuelve la misma dirección en las dos redes?
¿Hay una VPN activa o un adaptador Wi-Fi con ahorro de energía?
¿El cliente está actualizado?

Cómo evitar que vuelva a pasar

Pon recordatorios con 60 y 30 días de antelación a la caducidad del certificado.
Prueba el acceso desde una red de invitados, desde una red móvil y desde la corporativa antes de dar por buena una configuración.
Documenta qué dispositivos están delante del servidor, como balanceadores, pasarelas o cortafuegos, y qué certificado tiene cada uno.
Usa certificados emitidos por una autoridad de confianza para el acceso desde fuera, y reserva la autoridad interna para el uso interno.