API-Endpunkt-Kommunikationsprobleme bei Verwendung von Zscaler

Einführung

Einige Organisationen nutzen eine restriktive Firewall, wie sie mit Zscaler konfiguriert ist, um ihre Backend-Endpunkte zu sichern.

Dies kann zu Herausforderungen führen, wenn diese Endpunkte versuchen, auf mit TLS gesicherte API Manager APIs zuzugreifen. Da die Backend-Systeme möglicherweise keinen Zugriff auf öffentliche Zertifizierungsstellen (CAs) haben, importieren einige Organisationen Jitterbit's Zertifikat möglicherweise manuell in ihren Backend-Zertifikatspeicher. Dieser Ansatz kann zu Problemen führen, wenn Jitterbit sein Zertifikat erneuert.

Der Zugriff auf eine CA über ein von Zscaler verwaltetes Netzwerk – besonders wenn der HTTPS-Zugriff eingeschränkt ist – erfordert genaue Kenntnisse der Sicherheitsrichtlinien Ihrer Organisation. Sie sollten diese Richtlinien berücksichtigen, wenn Sie die Optionen für den Zugriff auf CAs in einer eingeschränkten Umgebung in Betracht ziehen.

Zscaler-Interception verstehen

Zscaler führt SSL/TLS-Interception für HTTPS-Traffic durch, um Traffic zu inspizieren und zu sichern. Dies bedeutet normalerweise:

• Zscaler präsentiert Clients sein eigenes Root-Zertifikat anstelle des Zertifikats der ursprünglichen Website.
• Die Organisation muss Zscaler's Root-Zertifikat im vertrauenswürdigen Zertifikatspeicher aller Geräte installieren, die auf HTTPS-Ressourcen zugreifen.

Optionen für den Zugriff auf externe CAs in einer eingeschränkten Umgebung

Zscaler's Root-Zertifikat installieren

1. Besorgen Sie sich das Zscaler Root-Zertifikat von Ihrer IT-Abteilung oder dem Zscaler Admin Portal.

2. Installieren Sie es im OS/Browser oder Endpoint Trust Store:

   • Windows: Verwenden Sie certmgr.msc.
   • Linux: Fügen Sie es zu /usr/local/share/ca-certificates/ hinzu und führen Sie update-ca-certificates aus.
   • macOS: Verwenden Sie Keychain Access.

Ein Proxy-fähiges Tool verwenden

Wenn Sie Zertifikate abrufen oder mit einem CA-Server kommunizieren müssen, verwenden Sie Tools, die HTTP-Proxys unterstützen (z. B. curl, wget, openssl) und konfigurieren Sie diese so, dass sie über Zscaler geleitet werden. Beispiel mit curl:

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

Für OpenSSL sollten Sie erwägen, den Proxy auf Systemebene zu konfigurieren oder einen Tunnel durch ein Tool wie cntlm zu verwenden.

Eine Richtlinienausnahme anfordern (falls erforderlich)

Wenn der Zugriff auf eine bestimmte CA oder einen bestimmten Endpunkt blockiert ist, können Sie eine Ausnahme anfordern:

• Reichen Sie eine Anfrage bei Ihrem Netzwerksicherheitsteam oder Zscaler-Administrator ein, um eine temporäre oder permanente Ausnahme zu erhalten.
• Geben Sie den Hostnamen, den Zweck und den Port an (normalerweise 443).

Zugriff über PAC-Datei-Regeln

Wenn Ihre Umgebung eine Proxy Auto-Config (PAC)-Datei verwendet, können Ihre Anfragen je nach Domäne unterschiedlich weitergeleitet werden:

• Überprüfen Sie PAC-Datei-Regeln (z. B. http://proxy.company.com/proxy.pac), um zu sehen, ob der CA-Endpunkt explizit blockiert oder falsch weitergeleitet wird.
• Arbeiten Sie mit der IT zusammen, um die PAC-Datei bei Bedarf zu ändern.

Eine interne CA oder einen Mirror verwenden

Einige Organisationen spiegeln externe CA-Repositories intern. Überprüfen Sie, ob Ihre Organisation Root-/Zwischenzertifikate im Intranet spiegelt. Beispielsweise könnten interne NGINX- oder Apache-Hosts Root-Zertifikate über HTTP bereitstellen.

Tipps zur Fehlerbehebung

• Verwenden Sie Tools wie openssl s_client -connect ca.example.com:443, um Konnektivität und Zertifikatspräsentation zu überprüfen.
• Überprüfen Sie Browser- oder Systemprotokolle auf SSL-Fehler.
• Verwenden Sie Paketerfassung (Wireshark oder tcpdump), um zu bestätigen, ob Traffic den CA-Server erreicht oder auf dem Weg blockiert wird.
• Zscaler oder SSL-abfangende Firewall blockiert API-Zugriff.