Solución de Problemas de Inspección TLS

Introducción

Este artículo cubre escenarios avanzados de solución de problemas para la Inspección TLS. Antes de continuar, se recomienda revisar la configuración de la Inspección TLS y el comportamiento para entender cómo se procesa y aplica el tráfico.

En condiciones normales, la Inspección TLS no es visible para los usuarios finales. Para verificar si el tráfico está siendo inspeccionado, revise el campo Inspección TLS en los Eventos de Cuenta (1 = inspeccionado, 0 = omitido), revise el emisor del certificado en el navegador (Cato Networks) o utilice los informes de Inspección TLS.

Cato incluye un conjunto de reglas de omisión predeterminadas para aplicaciones, dispositivos y dominios bien conocidos. Estas reglas gestionadas por el sistema no son editables y siempre deben revisarse antes de crear reglas personalizadas. Para detalles adicionales, consulte Reglas de Omisión Predeterminadas

Síntomas

Posibles causas

La mayoría de los problemas de Inspección TLS están relacionados con algunas condiciones comunes.

  • Algunas aplicaciones no son compatibles con la Inspección TLS. Las aplicaciones que utilizan fijación de certificados, validación estricta de TLS o TLS mutuo rechazarán la intercepción y fallarán al conectarse.

  • Los problemas de confianza del certificado en el cliente son otra causa frecuente. Si falta el certificado raíz de Cato, no es confiable o se implementa de manera inconsistente, el tráfico inspeccionado fallará aunque la política sea correcta.

  • En otros casos, el problema se origina en el servidor de destino. Problemas como certificados expirados, cadenas incompletas, desajustes de nombres de host o autoridades de certificación desconocidas pueden no ser siempre visibles en el navegador cuando la Inspección TLS está habilitada, pero todavía son aplicados por el PoP.

  • Los sistemas legacy pueden fallar debido a mismatch del protocolo TLS o cifrado. Las aplicaciones que utilizan versiones obsoletas de TLS o conjuntos de cifrado débiles pueden no cumplir con los requisitos definidos en la política de Inspección TLS.

  • Los sitios web modernos también pueden introducir problemas debido a múltiples dominios dependientes. Si solo se permite o se omite el dominio principal mientras los dominios de soporte están bloqueados o inspeccionados de manera diferente, los usuarios pueden experimentar una carga lenta o contenido faltante.

  • Finalmente, el comportamiento específico de la plataforma juega un papel. Los dispositivos móviles, puntos de conexión BYOD y sistemas Linux pueden comportarse de manera diferente debido a limitaciones de confianza del certificado, validación específica de la aplicación o reglas de omisión predeterminadas.

Solución inicial de problemas

Al investigar problemas relacionados con TLS, el objetivo principal es determinar si el problema se origina en el cliente, la red (Inspección TLS) o el servidor de destino.

1. Aislar el Alcance

Comienze validando si el problema es específico del cliente. Pruebe la misma URL:

  • Desde un navegador diferente
  • Desde otro dispositivo en la misma red
  • Desde el mismo dispositivo en una red diferente (por ejemplo, punto de acceso)

Si el problema se limita a un navegador o dispositivo específico, esto suele indicar una cuestión local de confianza o configuración. Si funciona fuera de la red, el problema probablemente está relacionado con Inspección TLS o aplicación de políticas.

2. Verifique Inspección TLS / Emisor de Certificado

Desde el navegador:

  • Abrir DevTools → pestaña de Seguridad o haga clic en el icono del candado
  • Inspeccione la cadena de certificados

Compruebe el Emisor:

  • Proxy/Enterprise CA (por ejemplo, Cato) → Inspección TLS está activa
  • CA Pública (por ejemplo, DigiCert, Let's Encrypt) → sesión TLS directa

3. Validar Confianza de Certificado en el Cliente

  • Asegúrese de que el certificado raíz de Cato esté correctamente instalado en el punto final.

  • Verifique que el certificado raíz esté en la tienda de confianza del SO:
    • En Windows, abra el Administrador de Certificados de Computadora escribiendo certlm.msc y busque el certificado raíz bajo Autoridades de Certificación Raíz de Confianza
    • En Mac, abra Acceso a Llaveros y busque el certificado raíz bajo el Llavero del Sistema
  • Compruebe la hora y la fecha del sistema
  • Si falta el certificado raíz de Cato en el punto final, descárguelo e instálelo como se explica en Instalación del Certificado Cato en Dispositivos

  • La configuración de confianza incorrecta o faltante causará fallos inmediatos de TLS.

4. Prueba el Entendimiento TLS desde el Cliente

Use herramientas del lado del cliente para simular una conexión TLS e identificar exactamente dónde y por qué falla el enlace. Estas herramientas exponen errores que a menudo están ocultos detrás de mensajes genéricos del navegador.

Ejecute lo siguiente o algo similar desde el punto final afectado:

curl.exe -v https://<dominio>

Si OpenSSL está disponible:

openssl s_client -connect <dominio>:443 -servername <dominio>

Salida Esperada (Éxito)

* Conexión SSL usando TLS1.2 / TLS1.3
* Certificado de servidor:
*  sujeto: CN=www.google.com
*  emisor: CN=GTS CA 1C3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

Es importante determinar primero si el problema está relacionado con el cliente, el servidor de destino o la configuración de Inspección TLS. 

Solución de Problemas Comunes

Nota:
Los problemas enumerados a continuación representan escenarios comunes observados en despliegues de Inspección TLS. Muchos de estos errores son genéricos y pueden o no aplicarse directamente a su entorno específico.
Si los síntomas o resoluciones descritos no coinciden con su caso, se recomienda recopilar datos de diagnóstico (por ejemplo, SSS, HAR y PCAP) de la máquina cliente y abrir un ticket de soporte para un análisis más profundo.

Solución de Problemas de Aplicaciones Fallidas 

Problema: Ciertas aplicaciones fallan al establecer conexiones seguras o dejan de funcionar después de habilitar la Inspección TLS.

Expectativa Comportamental:
Las aplicaciones con controles de seguridad estrictos (por ejemplo, aplicaciones bancarias, herramientas de seguridad de puntos finales) pueden fallar inmediatamente las conexiones, cerrarse silenciosamente o reintentar infinitamente las conexiones. Esto ocurre porque la Inspección TLS introduce un certificado de intermediario, que estas aplicaciones están específicamente diseñadas para detectar y rechazar.

Resolución:
Valide omitiendo la Inspección TLS para un usuario único o IP de origen utilizando una regla en la parte superior de la política. Si la aplicación funciona cuando se omite, cree una exclusión específica (basada en dominio/FQDN) y evite reglas amplias. Además, el Asistente de Configuración de Inspección TLS de Cato puede usarse para omitir dominios sensibles con una configuración mínima. 

Si la aplicación o servidor aplica validación de certificados o requisitos estrictos de TLS, la Inspección TLS no puede aplicarse. En tales casos, el enfoque correcto es omitir permanentemente ese tráfico.

Ejemplo:
Si una aplicación financiera falla al iniciar sesión y funciona inmediatamente después de omitir la Inspección TLS para ese usuario, esto confirma la incompatibilidad: agregue el dominio de la aplicación a la lista de omisiones. 

Solución de Problemas en Advertencia de Certificados del Navegador

Problema: Los usuarios ven advertencias de certificados o las aplicaciones fallan después de habilitar la Inspección TLS.

Expectativa Comportamental:
Los usuarios pueden encontrar advertencias de navegador (por ejemplo, “conexión no segura”) o fallos completos de conexión. El comportamiento puede variar entre dispositivos dependiendo de si el certificado de Cato está correctamente instalado.

Resolución:
Asegúrese de que el certificado raíz de Inspección TLS de Cato esté instalado y confiable en todos los puntos finales. Implemente usando GPO/MDM y verifique la cadena completa de certificados en el cliente.

Si se usan certificados privados/internos, asegúrese de que sean confiados correctamente o siga los procedimientos relevantes de manejo de certificados de Inspección TLS.

Si el comportamiento es inconsistente, valide omitiendo la Inspección TLS para un usuario único o dispositivo para confirmar el impacto relacionado con los certificados.

Consulte Asegurar Tráfico con Inspección TLS Usando Certificados Privados si utiliza certificados privados en su organización. 

Solución de Problemas en Incompatibilidad de Nombres de Host

Problema: Los usuarios encuentran errores de certificados o bloqueos de conexiones debido a incompatibilidad de nombres de host cuando acceden a ciertos sitios web, especialmente cuando la Inspección TLS está habilitada.

Expectativa Comportamental:
Cuando un servidor presenta un certificado cuyo Nombre Común (CN) o SAN no coincide con el nombre de host solicitado, la conexión se considera inválida.

Sin Inspección TLS, el navegador detecta directamente esta incompatibilidad y muestra una advertencia de certificado.

Con la Inspección TLS habilitada, el navegador establece la sesión TLS con el PoP de Cato en lugar del servidor de origen. El PoP vuelve a firmar el certificado usando la CA Raíz de Cato, haciéndolo parecer válido para el cliente. Como resultado, no se muestra ninguna incompatibilidad en el navegador, incluso si el problema aún existe en el backend.

Resolución:
Valide el comportamiento omitiendo la Inspección TLS para un usuario o IP de origen específico. Si el navegador muestra entonces un error de incompatibilidad de nombre de host, esto confirma que el problema se origina en el servidor de destino.

Dado que la incompatibilidad es causada por la configuración del certificado del servidor, no puede corregirse mediante la Inspección TLS. La acción adecuada es optar por:

  • Permitir el acceso omitiendo la Inspección TLS para el dominio específico, o
  • Bloquear el tráfico basado en políticas si la incompatibilidad se considera un riesgo de seguridad

Evite reglas de omisión amplias y, en su lugar, use exclusiones dirigidas al dominio/FQDN donde sea necesario.

Ejemplo:
Al acceder a https://www.testingmcafeesites.com/, el servidor presenta un certificado para platformsplat1.mcafee.com.

Sin Inspección TLS, el navegador marca inmediatamente una incompatibilidad de nombre de host.

Con la Inspección TLS habilitada, el navegador ve un certificado válido emitido por la CA Raíz de Cato para www.testingmcafeesites.com, por lo que no se muestra ningún error. Sin embargo, el PoP de Cato detecta la incompatibilidad en el back-end y aplica la política configurada (bloquear o advertir).

Solución de Problemas en Carga de Sitios Web o Aplicaciones

Problema: Los sitios web no se cargan, se renderizan parcialmente o se comportan de manera inesperada cuando la Inspección TLS está habilitada.

Expectativa Comportamental:

  • Las páginas pueden colgarse, cargarse indefinidamente o renderizarse parcialmente
  • Los flujos de inicio de sesión/autenticación pueden fallar o repetir un bucle
  • Algunos sitios pueden parecer lentos debido a la sobrecarga de desencriptación/reencriptación TLS
  • El comportamiento puede ser inconsistente (por ejemplo, funciona en una red, falla a través de Cato)

Esto se observa típicamente con aplicaciones web modernas que usan controles de seguridad estrictos o dependencias TLS complejas.

Resolución:
Validar omitiendo la Inspección TLS para un usuario específico o IP de Fuente. Si el sitio funciona al ser omitido, crear una exclusión de dominio/FQDN dirigida.

Evitar reglas de omisión amplias — limitar exclusiones solo a dominios requeridos.

Si la aplicación se basa en mecanismos de seguridad estrictos (por ejemplo, certificados anclados o manejo avanzado de TLS), la inspección puede no ser compatible, y la omisión es el enfoque correcto.

Escenario – Aplicaciones Web Modernas (SaaS):
Algunas plataformas SaaS (por ejemplo, aplicaciones con múltiples dominios/CDNs backend) pueden cargar parcialmente (UI funciona, fallan APIs). En estos casos, identificar todos los dominios requeridos a través de HAR/DevTools y asegurar cobertura completa en la regla de omisión.

Solución de Problemas de Errores de Validación del Certificado de Cato

Problema: Aparecen errores relacionados con TLS de Cato durante la navegación o uso de aplicaciones.

Expectativa de Comportamiento:

Los usuarios pueden encontrar errores genéricos como: 

  • “Conexión segura fallida”
  • “Certificado no confiable”
  • Reinicios inesperados de conexión o desconexiones

Estos errores son típicamente no específicos y no indican claramente si el problema se origina del cliente, servidor, o del proceso de Inspección TLS.

Resolución:
Validar el comportamiento omitiendo temporalmente la Inspección TLS para un solo usuario o IP de fuente.

  • Si el problema se resuelve al ser omitido, esto confirma una falla en la validación del certificado durante la inspección.
  • En casos donde los CA intermedios o emisores no son reconocidos, esto puede deberse a que el certificado aún no está incluido en el paquete de certificados confiables de Cato.

Como medida temporal, se recomienda omitir la Inspección TLS para el dominio/aplicación afectado mientras se abre un caso de soporte.

Cato actualiza continuamente su paquete de certificados confiables en línea con los estándares de la industria y las autoridades de certificación más utilizadas. Si el certificado es válido y ampliamente confiable, es probable que se agregue en una actualización futura.

La remediación permanente debe centrarse en:

  • Asegurar que el servidor presente una cadena de certificados completa y válida.
  • Utilizar certificados emitidos por CAs confiables y bien conocidas.

Si el servidor presenta una cadena de certificados inválida o incompleta, la Inspección TLS bloqueará correctamente la conexión. La remediación debe realizarse en el lado del servidor, o se debe omitir la Inspección TLS si es necesario.

Dominios Recientemente Confiables/Publicados

Los dominios que son recién publicados, actualizados recientemente, o reclasificados en Internet pueden no ser reconocidos consistentemente por todos los motores de reputación, autoridades de certificación, o tiendas de confianza.

Esto puede llevar a escenarios donde el tráfico es bloqueado o señalado —no debido solo a una falla de TLS, sino como resultado de aplicación de seguridad por políticas de Cortafuegos de Internet o confianza incompleta de certificados.

Expectativa de Comportamiento:
Tales dominios pueden:

  • Ser mal clasificados o categorizados de manera inconsistente en motores de seguridad.
  • Presentar certificados que no están completamente propagados o confiables a nivel global.
  • Desencadenar errores TLS durante la inspección debido a cadenas de confianza incompletas.
  • Ser bloqueados en base a política en lugar de un problema real de conectividad.

Este comportamiento es común poco después de que un dominio se activa o pasa por cambios.

Resolución:

  • Validar el certificado directamente desde el punto final para confirmar la legitimidad.
  • Si el dominio se verifica como seguro:
    • Re-categorizarlo a una categoría permitida basada en los requisitos de política, o
    • Crear una regla de omisión/permitir dirigida (evitar exclusiones amplias).
  • Tratar las reglas de omisión como temporales siempre que sea posible.
  • Reevaluar el dominio después de algún tiempo, una vez que su reputación y confianza de certificado estén totalmente establecidos a nivel global.

Nota Clave:
Incluso si un dominio es legítimo, la propagación incompleta del certificado puede aún causar errores relacionados con TLS. En estos casos, el comportamiento es esperado y debe manejarse mediante ajustes controlados de política en lugar de asumir una mala configuración.

Escenario – Cadena de Certificados Incompleta:
Un sitio puede funcionar directamente en un navegador (debido a intermediarios en caché) pero fallar bajo Inspección TLS. Esto indica que el servidor no está presentando la cadena de certificados completa. La resolución es corregir la configuración del servidor o omitir el dominio.

Protocolos No Soportados y Sistemas Legacy

Problema:
Las conexiones fallan para aplicaciones o sistemas que usan versiones de TLS obsoletas o suites de cifrado débiles que no son compatibles bajo Inspección TLS.

Expectativa de Comportamiento:
Las fallas ocurren típicamente durante el apretón de manos TLS y son visibles directamente en el navegador o cliente.

Los errores comunes de navegador incluyen:

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Bad Request
No se envió el certificado SSL requerido

En algunos casos:

  • La página puede no cargar completamente
  • La conexión puede reiniciarse inmediatamente
  • Clientes o aplicaciones legacy pueden fallar silenciosamente o mostrar errores de conexión genéricos

Esto sucede porque el cliente o servidor no pueden negociar una versión TLS compatible o suite de cifrado con el PoP de Cato actuando como el MITM.

En los eventos, también notará que el campo de descripción de error TLS está poblado con información específica. 

Para más sobre los errores visite Comprendiendo los errores TLS. 

Resolución:

  • Omitir temporalmente la Inspección TLS para un usuario específico o IP de fuente para validar el comportamiento.
  • Si la aplicación funciona al ser omitida → confirma un desajuste de negociación TLS durante la inspección.

A continuación, validar capacidades TLS usando herramientas externas como  https://www.ssllabs.com/ssltest/.

Compare resultados con su política de Inspección TLS:

  • Versión mínima de TLS permitida
  • Nivel de aplicación de suite de cifrado

Si se confirma:

  • Actualizar o mejorar la aplicación o servidor para soportar versiones TLS modernas y suites de cifrado fuertes
  • Si las mejoras no son factibles, configurar una omisión de Inspección TLS dirigida para la aplicación o dominio afectado.

Nota:
Por defecto, Cato permite un amplio rango de versiones TLS y suites de cifrado. Sin embargo, los administradores pueden imponer controles más estrictos en la política de Inspección TLS (por ejemplo, versión mínima de TLS o fuerza de cifrado), lo que puede hacer que las aplicaciones legacy fallen. Para más información lea aquí.

 

Escenario – Aplicación Interna Legacy:
Una aplicación interna o legacy de terceros puede fallar solo cuando se enruta a través de Cato con Inspección TLS habilitada pero funciona al ser omitida. Esto típicamente indica dependencia de versiones TLS obsoletas, requiriendo actualización de aplicación o omisión permanente.

Solución de Problemas de TLS Específicos del SO (Limitaciones Esperadas)

Problema: Problemas de conectividad, comportamiento inconsistente, o falta de visibilidad de Inspección TLS en ciertos tipos de dispositivos y sistemas operativos (por ejemplo, móvil, BYOD, Linux).

Expectativa de Comportamiento:

El comportamiento varía significativamente dependiendo del sistema operativo y diseño de la aplicación.

Para dispositivos Android y Linux, la Inspección TLS es omitida por defecto debido a limitaciones de confianza de certificados y comportamiento de aplicaciones. Sin embargo, configuraciones más recientes (a través de Configuraciones Avanzadas en CMA) permiten a los administradores aplicar la Inspección TLS en estas plataformas, siempre que se pueda establecer correctamente la confianza del certificado.

Para dispositivos iOS, la Inspección TLS es compatible, pero varias aplicaciones (por ejemplo, plataformas de redes sociales como Instagram, Facebook, y aplicaciones similares) son omitidas por defecto debido al pinning de certificados y las incompatibilidades conocidas. Otras aplicaciones que aplican validación estricta pueden fallar y requerir configuración manual de omisión.

En general:

  • Los navegadores pueden funcionar como se espera una vez que el certificado de Cato esté instalado.
  • Las aplicaciones nativas/móviles pueden fallar inmediatamente debido a pinning de certificados o tiendas de confianza restringidas.
  • El comportamiento puede diferir por aplicación, incluso en el mismo dispositivo.

Resolución:

Estos comportamientos son generalmente esperados y dirigidos por plataformas, no son indicativos de mala configuración.

  • Aplicar la Inspección TLS principalmente a dispositivos gestionados donde la implementación de certificados está controlada.
  • Utilizar soluciones MDM para instalar el certificado de Cato a nivel del sistema (donde se soporta).
  • Ser consciente de las reglas de omisión por defecto para aplicaciones y plataformas bien conocidas.
  • Para aplicaciones que fallan debido a pinning de certificados o validación estricta, configurar una omisión de Inspección TLS dirigida.
  • Al aplicar Inspección TLS en plataformas como Android o Linux, validar la compatibilidad cuidadosamente antes de un despliegue amplio.

Escenario – Falla de Aplicación Móvil:
Una aplicación móvil (por ejemplo, aplicación bancaria o de seguridad) falla al conectarse a través de Cato mientras el navegador funciona. La aplicación aplica pinning de certificados y no confía en el certificado de Cato. Esto es esperado — la acción correcta es omitir la Inspección TLS para esa aplicación o servicio.

Elevación de casos al Soporte de Cato

En caso de que la inspección TLS sea obligatoria para una aplicación debido a razones de cumplimiento o regulatorias, o en caso de que usted crea que el bloqueo TLS es inesperado, por favor envíe un ticket de Soporte con los resultados de los pasos de resolución de problemas anteriores. Incluya la siguiente información en el ticket:

  • Detalles del problema experimentado e impacto general en los usuarios. Marca de tiempo/zona horaria del usuario que experimenta el problema. 
  • Eventos relacionados y configuración de regla Firewall/TLS.
  • Reproduzca el problema y ejecute el Autoservicio de Soporte. Incluya el número de ticket generado por la herramienta.

 

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 0 de 0

0 comentarios