Kann eine Server-Zertifikatskette den Vertrauensspeicher des Clients außer Kraft setzen?

Ein Browser zeigt eine Zertifikatswarnung für eine Website an, deren Kette vollständig ist, und der erste Impuls ist, den Server zu reparieren. Meist präsentiert der Server genau das, was er soll. Der Client entscheidet, welche Anker er akzeptiert, und keine Anordnung von Zwischenzertifikaten kann diese Entscheidung vom anderen Ende der Verbindung aus ändern. Diese Grenze erklärt den größten Teil dessen, was wie ein Zertifikatsproblem aussieht.

Die Validierung läuft beim Client, mit den Ankern des Clients

Die Pfadvalidierung nimmt die vorgelegten Zertifikate und baut eine Kette zu einem Vertrauensanker auf, den das prüfende System bereits besitzt. RFC 5280 beschreibt dieses Modell und legt die Ankerauswahl in die lokale Implementierung statt zum Server. Eine Anwendung kann darüber ihre eigene Richtlinie legen: einen festgelegten Schlüssel, einen Unternehmens-Vertrauensspeicher, oder eine strengere Identitätsprüfung. Die Zertifikatsliste, die ein Server sendet, ist ein Beleg, der diesem Prozess angeboten wird, niemals eine Anweisung an ihn.

Eine vollständige Kette beweist also, dass der Server die Teile hat. Sie beweist nicht, dass der Client sie akzeptieren wird.

Um zu sehen, was der Server tatsächlich sendet, führen Sie openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts aus und zählen Sie die Zertifikate in der Ausgabe. Eine unvollständige Kette dort ist eine Korrektur auf Serverseite. Eine vollständige Kette verlagert die Frage zum Client und seinen Ankern, wo der Server keine Stimme hat.

Was die TLS-Inspektion tatsächlich ändert

Ein Inspektionsgerät beendet die TLS-Sitzung auf der Clientseite und öffnet eine separate Sitzung zum echten Dienst. Der Client validiert dann das Zertifikat des Geräts, das zu einem Anker führen muss, dem der Client vertraut. Deshalb erhalten verwaltete Geräte die Inspektionswurzel über die Geräteverwaltung, und deshalb zeigt ein persönliches Gerät ohne sie eine Warnung.

Die Anordnung ist beabsichtigt und lokal. Nichts in der Kette des ursprünglichen Servers kann einen nicht verwalteten Browser zwingen, die Ersatzidentität zu akzeptieren, und nichts darin hindert ein verwaltetes Gerät daran.

VPN-Terminierung ist keine HTTPS-Entschlüsselung

Eine VPN-Schicht transportiert Pakete zwischen einem Client und einem Gateway. Sie zu entfernen oder ihre Konfiguration zu lesen legt keine HTTPS-Nutzlast darin offen.

Die TLS-Sitzung läuft weiterhin zwischen Browser und Webserver, mit denselben Validierungsregeln, es sei denn, etwas beendet sie ausdrücklich. Die Verwechslung der beiden Schichten erzeugt eine Anfrage an den VPN-Administrator, das Zertifikat bereitzustellen, obwohl das betreffende Zertifikat zu einem Inspektionsproxy oder zur Website selbst gehört. Fragen Sie, welche Komponente das Zertifikat präsentiert, bevor Sie einen Vertrauensspeicher ändern.

Setzen Sie Erwartungen in der Komponente, die Sie kontrollieren

Wenn Sie die Anwendung und ihren Client betreiben, definieren Sie die erwartete Dienstidentität, die akzeptierten Aussteller und jede Anforderung an Pinning oder Client-Authentifizierung gemeinsam. Planen Sie Erneuerung und Wiederherstellung so, dass ein legitimer Zertifikatswechsel kein Ausfall wird. Wenn Sie nur den öffentlichen Server betreiben, dokumentieren Sie, welche Authentifizierung Sie verlangen und welche Clientumgebungen Sie unterstützen. Das Senden einer bevorzugten Kette bescheinigt keinem fremden Gerät etwas.

Bei verwalteten Geräten lösen Sie Inkompatibilitäten über die Anwendungs- und Netzwerkverantwortlichen. Das Deaktivieren der Prüfung, das Hinzufügen einer unerklärten Wurzel oder der Versuch, eine Inspektionsrichtlinie zu überdauern, stellt die beabsichtigte Peer-Beziehung nicht her.

Testen Sie das Ergebnis in einem sauberen Clientprofil, nicht auf dem Rechner, auf dem bereits eine Ausnahme hinzugefügt wurde. Das ist die einzige Prüfung, die zeigt, was ein neues Gerät erleben wird.