Ein Zertifikatsfehler nach der Proxy-Konfiguration kann auf zwei voellig verschiedene Dinge hindeuten: entweder auf eine zwischengeschaltete Pruefebene oder auf eine einfache Konfigurationsluecke. Beides zu unterscheiden ist fuer Ihre Sicherheit entscheidend.
Was sollte im Normalfall passieren?
In einem korrekt konfigurierten CONNECT-Tunnel ruehrt der Proxy das Zertifikat ueberhaupt nicht an. Der TLS-Handshake findet direkt zwischen Client und Zielserver statt; der Proxy transportiert lediglich verschluesselte Bytes. Das Zertifikat ist somit das echte Zertifikat der Zielseite.
In diesem Ablauf ist kein Zertifikatsfehler zu erwarten. Tritt einer auf, wurde entweder dazwischengeschaltet oder der Zertifikatsspeicher des Clients ist unvollstaendig.
Fehlerursachen
Die zweite Zeile ist ein Warnsignal: Befindet sich ein selbstsigniertes Zertifikat in der Kette, wird Ihr Traffic moeglicherweise mitgelesen.
Wie erkennt man SSL Inspection?
Weichen die issuer -Werte in beiden Ausgaben voneinander ab, fuehrt der Proxy eine TLS-Interception durch und kann Ihren Traffic mitlesen.
Einen Zertifikatsfehler mit -k oder verify=False stummzuschalten loest das Problem nicht — es macht es lediglich unsichtbar. Das bedeutet, jedem Zwischengeschalteten das Mitlesen Ihres Traffics zu erlauben. Verwenden Sie das niemals in der Produktion.
Die richtigen Loesungen
Aktualisieren Sie den Stammzertifikatsspeicher
Das ist die haeufigste Ursache. Unter Linux update-ca-certificates, in Python über einen mit certifi Aktualisieren Sie das Paket.
Unternehmens-Stammzertifikat geprueft hinzufuegen
Wenn Sie sich in einem Unternehmensnetzwerk befinden und die Richtlinie dies vorsieht, fuegen Sie das von der IT-Abteilung erhaltene Stammzertifikat dem Vertrauensspeicher Ihres Clients hinzu. Fuegen Sie niemals ein aus dem Internet heruntergeladenes Zertifikat hinzu.
Pruefen Sie die Systemzeit
Eine falsche Systemzeit laesst gueltige Zertifikate als "abgelaufen" erscheinen. Das kommt bei virtuellen Maschinen haeufig vor.
Nutzen Sie einen Kanal ohne TLS-Interception
Anwendungen mit Certificate Pinning akzeptieren keine Zwischenschaltung. In diesem Fall sind mobile Daten oder eine direkte Verbindung erforderlich.
Anwendungsspezifische Zertifikatsspeicher
Nicht jede Anwendung nutzt den Vertrauensspeicher des Systems. Das erklaert die Situation "im Browser funktioniert es, in meinem Skript nicht":
| Umgebung | Zertifikatsspeicher | Methode zum Hinzufuegen |
|---|---|---|
| Linux-Systemwerkzeuge | /etc/ssl/certs | update-ca-certificates |
| Python (requests) | certifi-Paket | REQUESTS_CA_BUNDLE -Variable |
| Node.js | Integrierter Speicher | NODE_EXTRA_CA_CERTS -Variable |
| Java | cacerts keystore | keytool -import |
| Firefox | Eigener Speicher | Einstellungen → Zertifikate |
| Chrome | Systemspeicher | Betriebssystemeinstellung |
Ein systemweit hinzugefuegtes Zertifikat gilt fuer saemtliche Anwendungen als vertrauenswuerdig. Tun Sie das nur bei Zertifikaten, deren Herkunft Sie sicher kennen.
Certificate Pinning
Manche mobilen Anwendungen und Banking-Clients verankern das Serverzertifikat innerhalb der Anwendung. Sehen sie ein zwischengeschaltetes Zertifikat, weisen sie die Verbindung zurueck — kein hinzugefuegtes Stammzertifikat aendert dieses Verhalten.
Das ist der Grund fuer die Beschwerde "im Unternehmens-WLAN startet die App nicht, ueber mobile Daten schon". Die einzige Loesung ist, fuer diese Anwendung einen Kanal ohne TLS-Interception zu nutzen.
Zusammenfassung
In einem intakten CONNECT-Tunnel ruehrt der Proxy das Zertifikat nicht an; sehen Sie einen Fehler, ist entweder der Stammspeicher Ihres Clients unvollstaendig oder eine zwischengeschaltete Pruefebene vorhanden. Um beide Faelle zu unterscheiden, vergleichen Sie den Wert in der Zertifikatskette issuer mit dem einer direkten Verbindung. Die Pruefung zu deaktivieren ist keine Loesung, sondern macht das Risiko lediglich unsichtbar. Um zu sehen, was Ihre Verbindung tatsaechlich preisgibt, koennen Sie Anonymitätstest unser Werkzeug nutzen.