Ein HTTPS-Proxy muss auch seine Zertifikatskette senden

Wenn Clients den HTTPS-Proxy ablehnen, bevor sie eine Website erreichen, prüfen Sie die Kette, die der Proxy-Listener sendet. Ein gültiges Endzertifikat allein liefert möglicherweise nicht die Zwischenzertifikate, die der Client benötigt.

1. Bestimmen Sie den geprüften Endpunkt. Lesen Sie den Hostnamen in der konfigurierten Proxy-URL und den Fehler für diese Verbindung. Das Listener-Zertifikat muss diesen Namen abdecken. Ein Website-Zertifikat oder ein Zertifikat für einen anderen IP-Alias kann es nicht ersetzen.
2. Prüfen Sie die Kettenkonfiguration des Listeners. Die von Squid unterstützte OpenSSL-Konfiguration kann Zwischenzertifikate in die Zertifikatsdatei aufnehmen. Bestätigen Sie die Anordnung in der Listener-Referenz für die installierte Squid-Version und das TLS-Backend; das Verhalten der Pakete ist nicht einheitlich. Das TLS-Listener-Beispiel von Squid 6.13 hält das Vertrauen des Listeners getrennt vom TLS des Ziels.
3. Prüfen Sie das Client-Vertrauen separat. Das Senden von Zwischenzertifikaten hilft beim Aufbau der Kette, aber der Client benötigt weiterhin den vorgesehenen Root-Vertrauensanker. Die gesamte Serverkette unterschiedslos in einen Root-Speicher zu importieren, ist eine andere Änderung als die Korrektur dessen, was der Server sendet.

Lassen Sie die Verifikation aktiviert. Sie identifiziert den HTTPS-Proxy, den der Client verwenden wollte. Nachdem diese Verbindung verifiziert ist, gehört ein späterer Website-Zertifikatsfehler zu der TLS-Sitzung des Ziels durch den Proxy, mit eigener Hostnamen- und Vertrauensuntersuchung.