Slackware hinter Zscaler: Wenn die Corporate Root CA fehlt
16.08.2026 6 Min. Lesezeit
Slackware in einer Unternehmensumgebung zu betreiben, ist grundsätzlich kein Problem. Etwas interessanter wird es allerdings, wenn der gesamte Netzwerkverkehr über Zscaler läuft.
Spätestens beim ersten Zugriff auf eine HTTPS-Ressource kann Slackware dann feststellen, dass mit der Zertifikatskette etwas nicht stimmt.
Der Grund ist relativ einfach: Die Unternehmensumgebung vertraut einer Root Certificate Authority (CA), die von Zscaler verwendet wird. Windows kennt dieses Zertifikat bereits, Slackware dagegen nicht.
Das Ergebnis sind Zertifikatsfehler bei HTTPS-Verbindungen.
In meinem Fall betraf das eine Slackware-Installation unter WSL. Das grundsätzliche Vorgehen lässt sich aber genauso auf eine native Slackware-Installation übertragen.
Das Problem: Zwei unterschiedliche Vertrauensspeicher
Zscaler kann den HTTPS-Verkehr einer Unternehmensumgebung überprüfen. Vereinfacht gesagt wird dabei die TLS-Verbindung aufgebrochen und für das Zielsystem ein neues Zertifikat ausgestellt.
Damit dieses Zertifikat als vertrauenswürdig akzeptiert wird, muss das System die entsprechende Zscaler-Root-CA kennen.
Auf einem durch das Unternehmen verwalteten Windows-System ist das normalerweise bereits der Fall. Die entsprechende CA befindet sich im Windows-Zertifikatsspeicher.
Eine Linux-Installation bringt dagegen ihren eigenen CA-Speicher mit. Slackware übernimmt die Zertifikate aus dem Windows-Zertifikatsspeicher nicht automatisch.
Das ist auch bei WSL wichtig: Obwohl Slackware innerhalb von Windows läuft, ist die Linux-Umgebung hinsichtlich ihrer Zertifikatsverwaltung nicht einfach ein weiterer Benutzer des Windows-Trust-Stores.
Damit entstehen zwei Welten:
- Windows vertraut der Zscaler Root CA.
- Slackware kennt diese CA zunächst nicht.
- HTTPS-Verbindungen aus Slackware können deshalb an der Zertifikatsprüfung scheitern.
Die Zscaler Root CA unter Windows finden
Der erste Schritt besteht darin, herauszufinden, welches Root-Zertifikat in der Unternehmensumgebung verwendet wird.
Unter Windows lässt sich der Zertifikatsspeicher beispielsweise über certmgr.msc öffnen.
Dort findet sich das Zertifikat unter:
Certificates – Current User → Trusted Root Certification Authorities → Certificates
In meiner Umgebung ist dort unter anderem die Zscaler Root CA zu finden.
Dabei sollte man genau darauf achten, das von der eigenen Unternehmensumgebung bereitgestellte Zertifikat zu verwenden. Die Bezeichnung kann je nach Zscaler-Konfiguration und Unternehmenssetup anders aussehen.
Die Root CA exportieren
Das Zertifikat muss anschließend aus Windows exportiert werden.
Nach einem Rechtsklick auf das entsprechende Zertifikat startet der Certificate Export Wizard.
Für die weitere Verwendung unter Linux bietet sich das X.509-Format an. In meinem Fall habe ich beim Export die Option
Base-64 encoded X.509 (.CER)
verwendet.
Damit erhält man eine Datei, die sich problemlos in die Linux-Umgebung übertragen und dort als CA-Zertifikat installieren lässt.
Wichtig ist an dieser Stelle: Es geht ausschließlich um das öffentliche Root-CA-Zertifikat. Ein privater Schlüssel wird nicht benötigt und sollte auch nicht exportiert werden.
Das Zertifikat nach Slackware übertragen
Bei einer Slackware-Installation unter WSL kann die exportierte Datei anschließend in die Linux-Umgebung kopiert werden.
Beispielsweise kann die Datei zunächst im Windows-Dateisystem abgelegt und anschließend über den gemounteten Windows-Dateibaum in das Slackware-Dateisystem kopiert werden.
Nachdem sich das Zertifikat innerhalb der Slackware-Umgebung befindet, muss es in den lokalen CA-Trust-Store aufgenommen werden.
Die Zscaler Root CA unter Slackware 15 installieren
Bei einem aktuellen Slackware 15 lässt sich das exportierte Zertifikat auf einfache Weise in den CA-Trust-Store integrieren.
Zunächst sollte die exportierte .CER-Datei nach Möglichkeit in eine .crt-Datei umbenannt und nach /usr/local/share/ca-certificates/ kopiert werden:
# cp ZscalerRootCA.cer /usr/local/share/ca-certificates/ZscalerRootCA.crt
Anschließend wird als root der CA-Zertifikatsspeicher aktualisiert:
# update-ca-certificates
Das Skript berücksichtigt dabei die Zertifikate aus /usr/local/share/ca-certificates/ und aktualisiert den System-Trust-Store.
Danach sollte Slackware der von Zscaler verwendeten Root CA vertrauen. Ob die Zertifikatsprüfung anschließend funktioniert, lässt sich beispielsweise mit curl testen:
$ curl https://bitunfall.de
Wenn zuvor ein Fehler wie SSL certificate problem oder unable to get local issuer certificate aufgetreten ist, sollte dieser nach der erfolgreichen Installation der Root CA nicht mehr erscheinen.
Damit ist die Konfiguration auch für eine Slackware-Installation unter WSL sauber gelöst: Das Zertifikat liegt nicht nur im Dateisystem, sondern wurde in den von den Linux-Anwendungen verwendeten Trust-Store aufgenommen.
Warum das wichtig ist
Das Kopieren der .CER-Datei alleine reicht also nicht unbedingt aus.
Ein Programm wie curl prüft bei einer HTTPS-Verbindung, ob die vom Server präsentierte Zertifikatskette bis zu einer vertrauenswürdigen Root CA zurückgeführt werden kann.
Ohne die Zscaler Root CA sieht Slackware beispielsweise vereinfacht betrachtet eine Zertifikatskette wie:
Zielserver
↓
Zscaler ausgestelltes Zertifikat
↓
Zscaler Root CA
↓
❌ Root CA nicht vertrauenswürdig
Nach der Installation der Unternehmens-CA sieht die Vertrauenskette dagegen so aus:
Zielserver
↓
Zscaler ausgestelltes Zertifikat
↓
Zscaler Root CA
↓
✓ Root CA vertrauenswürdig
Damit können HTTPS-Verbindungen aus der Slackware-Umgebung wieder erfolgreich validiert werden.
WSL macht hier keinen Unterschied
Gerade bei WSL kann die Situation zunächst verwirrend sein.
Schließlich läuft Slackware innerhalb von Windows und Windows kennt die Zscaler-CA bereits. Trotzdem bedeutet das nicht, dass Linux-Anwendungen automatisch auf den Windows-Zertifikatsspeicher zugreifen.
Slackware bringt seine eigene Linux-Umgebung mit - einschließlich eigener CA-Zertifikate.
Das erklärt auch, warum eine HTTPS-Verbindung im Windows-Browser problemlos funktionieren kann, während beispielsweise ein curl innerhalb von Slackware einen Zertifikatsfehler meldet.
Native Slackware-Installation
Bei einer nativen Slackware-Installation ist das Prinzip dasselbe.
Der Unterschied besteht lediglich darin, dass es keinen Windows-Host gibt, aus dessen Zertifikatsspeicher man die CA exportieren kann. Das Zertifikat muss in diesem Fall auf einem anderen Weg aus der Unternehmensumgebung bereitgestellt werden.
Auch hier gilt:
Die Unternehmens-Root-CA muss Bestandteil des von Slackware verwendeten Trust-Stores sein.
Ist das erledigt, können die üblichen Linux-Werkzeuge die von Zscaler ausgestellten Zertifikate entsprechend validieren.
Ein wichtiger Sicherheitshinweis
Bei diesem Vorgehen sollte man nicht einfach irgendein Zertifikat installieren, nur weil dadurch der Zertifikatsfehler verschwindet.
Die Root CA ist ein zentraler Bestandteil der Vertrauenskette. Wer eine CA als vertrauenswürdig installiert, gibt dem System damit grundsätzlich die Möglichkeit, Zertifikate zu akzeptieren, die von dieser CA signiert wurden.
Deshalb sollte ausschließlich die offiziell von der eigenen Unternehmensumgebung bereitgestellte Zscaler Root CA verwendet werden.
Auch sollte man keinesfalls versuchen, einen privaten Schlüssel aus Windows zu exportieren. Für diesen Anwendungsfall wird nur das öffentliche CA-Zertifikat benötigt.
Fazit
Das Problem ist letztlich kein spezielles Slackware- oder WSL-Problem.
Es entsteht dadurch, dass eine Unternehmensumgebung ihre eigene Zertifizierungsstelle verwendet, während Slackware diesen Trust Anchor zunächst nicht kennt.
Windows ist bereits entsprechend konfiguriert, Slackware benötigt dagegen eine eigene Konfiguration.
Der Lösungsweg ist deshalb überschaubar:
- Die von der Unternehmensumgebung verwendete Zscaler Root CA in Windows finden.
- Das öffentliche Zertifikat als Base-64-X.509-Datei exportieren.
- Das Zertifikat nach Slackware übertragen.
- Es in den von Slackware verwendeten CA-Trust-Store integrieren.
- Anschließend die HTTPS-Verbindung erneut testen.
Damit lässt sich Slackware auch in einer Umgebung betreiben, in der der Netzwerkverkehr durch Zscaler TLS-inspected wird.
Und genau hier zeigt sich einmal mehr eine Besonderheit von WSL: Windows und Linux teilen sich zwar denselben Rechner, aber nicht automatisch alle Vertrauens- und Konfigurationsmechanismen.