Problemas de comunicación del extremo de API al usar Zscaler

Introducción

Algunas organizaciones utilizan un firewall restrictivo, como el configurado con Zscaler, para proteger sus extremos de back-end.

Esto puede generar problemas cuando esos extremos intentan acceder a las APIs de API Manager protegidas con TLS. Dado que los sistemas backend pueden no tener acceso a las autoridades de certificación (CA) públicas, algunas organizaciones podrían importar manualmente el certificado de Jitterbit a su almacén de certificados backend. Este enfoque puede generar problemas cuando Jitterbit renueva su certificado.

Jitterbit no recomienda importar el certificado manualmente. Consulte con el equipo de red que administra Zscaler para obtener las mejores prácticas.

Acceder a una CA a través de una red administrada por Zscaler, especialmente cuando el acceso HTTPS está restringido, requiere un conocimiento profundo de las políticas de seguridad de su organización. Debe tener en cuenta estas políticas al considerar las opciones para acceder a las CA en un ambiente restringido.

Entendiendo la intercepción de Zscaler

Zscaler intercepta el tráfico HTTPS mediante SSL/TLS para inspeccionarlo y protegerlo. Esto suele significar:

• Zscaler presenta su propio certificado raíz a los clientes en lugar del certificado del sitio web original.
• La organización debe instalar el certificado raíz de Zscaler en el almacén de certificados de confianza de cualquier dispositivo que acceda a recursos HTTPS.

Opciones para acceder a CA externas en un ambiente restringido

Instalar el certificado raíz de Zscaler

1. Obtenga el certificado raíz de Zscaler de su departamento de TI o del Portal de administración de Zscaler.

2. Instálelo en el almacén de confianza del sistema operativo, navegador o extremo:

   • Windows: Usar certmgr.msc.
   • Linux: Agregar a /usr/local/share/ca-certificates/ y corre update-ca-certificates.
   • macOS: Utilizar el acceso a llaveros.

Utilice una herramienta que admita proxy

Si necesita obtener certificados o comunicarse con un servidor de CA, utilice herramientas compatibles con servidores proxy HTTP (por ejemplo, curl, wget, openssl) y configurarlos para que enrutar a través de Zscaler. Ejemplo usando curl:

curl --proxy http://proxy.company.com:8080 https://ca.example.com

Para OpenSSL, considere configurar un proxy a nivel de sistema o un túnel a través de una herramienta como cntlm.

Solicitar una excepción de política (si es necesario)

Si el acceso a una CA o extremo en particular está bloqueado, puede solicitar una excepción:

• Envíe una solicitud a su equipo de seguridad de red o al administrador de Zscaler para una excepción temporal o permanente.
• Proporcione el nombre de host, el propósito y el puerto (normalmente 443).

Acceso a través de reglas de archivos PAC

Si su ambiente utiliza un archivo de configuración automática de proxy (PAC), sus solicitudes podrían enrutarse de manera diferente según el dominio:

• Verifique las reglas del archivo PAC (por ejemplo, http://proxy.company.com/proxy.pac) para ver si el extremo de CA está bloqueado explícitamente o enrutado incorrectamente.
• Trabajar con TI para modificar el archivo PAC si es necesario.

Utilice una CA interna o un espejo

Algunas organizaciones replican repositorios de CA externos internamente. Compruebe si su organización replica las CA raíz/intermedias dentro de la intranet. Por ejemplo, los hosts internos NGINX o Apache podrían servir certificados raíz mediante HTTP.

Consejos para la solución de problemas

• Utilizar herramientas como openssl s_client -connect ca.example.com:443 para verificar la conectividad y la presentación del certificado.
• Revisar los registros del navegador o del sistema para detectar errores de SSL.
• Utilizar la captura de paquetes (Wireshark o tcpdump) para confirmar si el tráfico llega al servidor de CA o se bloquea a mitad de camino.