TLS-Fehler nur im Firmen-VPN: den richtigen Zertifikatsspeicher reparieren
Gleiches Werkzeug, gleicher Laptop, nur das VPN bricht TLS. Lesen Sie die Meldung, finden Sie das CA-Bundle, das die Binärdatei liest, und fügen Sie eine Wurzel hinzu, statt Prüfungen abzuschalten.
Der Go-Build, die Composer-Installation und der Python-Client funktionieren zu Hause und scheitern alle im Firmen-VPN. Dieses Muster sagt etwas über den Pfad aus, nicht über die Anwendung. Etwas auf dem Tunnel hat die Zertifikatskette verändert, die Ihr Prozess sieht, oder hat den Handshake zurückgesetzt, bevor überhaupt eine Kette ankam. Die beiden Fehler sehen im Terminal ähnlich aus und verlangen völlig unterschiedliche Reaktionen.
Drei Meldungen, drei Mechanismen
Der Fehler x509 certificate signed by unknown authority bedeutet, dass eine Kette aufgebaut wurde und ihre Wurzel in dem Zertifikatsspeicher fehlt, den dieser Prozess nutzt. Der Fehler self-signed certificate in certificate chain bedeutet meist, dass ein Inspektionsproxy mit seinem eigenen Zertifikat geantwortet hat, und das ist eine Kette, die Ihre Laufzeitumgebung nicht kennt. Ein SSL EOF während des Handshakes bedeutet, dass die Verbindung geschlossen wurde, bevor ein brauchbares Zertifikat gesendet wurde, und das ist eine Middlebox, die ClientHello ablehnt, überhaupt kein Vertrauensproblem.
Ein Flag für unsichere Verbindungen lässt alle drei Meldungen verschwinden, während die Abfangstelle bleibt, und es entfernt die Prüfung, die einen echten Angreifer erkennen würde.
Finden Sie das Bundle, das der Prozess tatsächlich liest
Die im Windows-Speicher installierte Firmenwurzel repariert Browser und .NET-Anwendungen, die den Systemspeicher konsultieren. Für einen Build in einem Container, der sein eigenes CA-Bundle mitbringt, bewirkt sie nichts, und ebenso wenig für einen Python-Prozess mit certifi oder einen Node-Prozess mit seiner mitgelieferten Liste. Go liest den Systempool der Umgebung, in der die Binärdatei läuft, also den Container und nicht den Laptop. Eine Maschine erzeugt daher gleichzeitig einen funktionierenden Browser und ein scheiterndes Build-Werkzeug.
Fragen Sie das Werkzeug, statt zu vermuten. python3 -c "import ssl; print(ssl.get_default_verify_paths())" gibt die Dateien aus, die Python konsultieren wird, und node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" zeigt, ob bereits eine Überschreibung gesetzt ist. Führen Sie für einen Container dieselbe Prüfung im Image aus, denn das ist die Umgebung, die der Build tatsächlich nutzt.
Installieren Sie eine Wurzel dort, wo der Build läuft
Holen Sie sich die Inspektionswurzel von der IT als PEM-Datei und prüfen Sie ihren Fingerabdruck über einen separaten Kanal, bevor Sie ihr vertrauen. Auf Debian-basierten Images kopieren Sie sie nach /usr/local/share/ca-certificates/ und führen update-ca-certificates aus; Images aus der RHEL-Familie nutzen update-ca-trust, nachdem die Datei in /etc/pki/ca-trust/source/anchors/ abgelegt wurde. Fügen Sie in einem Container-Build diese Schritte vor dem scheiternden Befehl ein, damit der Layer über der Installation der Abhängigkeiten zwischengespeichert wird.
Binden Sie für einen lokalen Devcontainer die PEM-Datei ein und führen Sie denselben Aktualisierungsbefehl beim Start aus, statt ihn in ein persönliches Image einzubacken, das niemand sonst reproduzieren kann. Werkzeuge mit eigenem Bundle brauchen ihre eigene dokumentierte Überschreibung: pip hat eine Zertifikatseinstellung, npm hat eine cafile-Einstellung, und die meisten anderen akzeptieren die Standardumgebungsvariablen.
Das ist nicht dasselbe wie jedes Zertifikat zu akzeptieren. Sie fügen eine bestimmte Wurzel, die Sie von der Stelle erhalten haben, die die Inspektion durchführt, einer Umgebung hinzu, und die Prüfung bleibt für jede andere Kette aktiv. Halten Sie fest, welche Datei hinzugefügt wurde und wann sie abläuft, denn eine Inspektionswurzel wird wie jede andere CA erneuert.
Wenn der Handshake vor einem Zertifikat stirbt
Wenn nichts vorgelegt wird, hilft keine Änderung am Zertifikatsspeicher. Vergleichen Sie dieselbe Anfrage mit aktivem und inaktivem Tunnel und prüfen Sie die Kette dann direkt mit openssl s_client -connect host:443 -servername host -showcerts. Eine Verbindung, die außerhalb des VPN zustande kommt und darin zurückgesetzt wird, ist eine politische Entscheidung der Middlebox, und das Mittel ist eine Ausnahme für diesen Host und kein weiteres Zertifikat. Bitten Sie darum, die Paketregistrierung oder den API-Endpunkt unverändert durchzulassen.
Den Tunnel aufzuteilen, damit das Werkzeug das VPN umgeht, vermeidet die Inspektion für diesen Verkehr, was Richtlinien verletzen kann und das Werkzeug nicht vertrauenswürdig macht.
Halten Sie das Ergebnis pro Werkzeug fest
Eine kurze Notiz mit der Binärdatei, der Vertrauensdatei, die sie liest, der beteiligten Umgebungsvariable und der genehmigten Ausnahme erspart der nächsten Person die ganze Diagnose. Führen Sie die Notiz pro Werkzeug statt pro Laptop, denn der Laptop ist selten das, was sich geändert hat.
Und halten Sie zwei Sätze im Ticket getrennt: Wir haben eine bestimmte Firmenwurzel installiert, und wir haben die Prüfung abgeschaltet. Nur eines davon ist eine Supportmaßnahme.