Wer sendet das Clientzertifikat über einen Proxy?
Trennen Sie mTLS-Zugangsdaten der Zielwebsite von Proxy-Zugangsdaten und den Zertifikaten, die Apache für eigene Upstream-TLS-Sitzungen verwendet.
Bei gewöhnlichem HTTPS über CONNECT sendet die Anwendung das Clientzertifikat der Website während ihres eigenen TLS-Handshakes zum Ziel. Der Proxy leitet Bytes weiter und wird nicht automatisch zum TLS-Client der Website.
| Anmeldedaten | Besitzer/Verbindung |
|---|---|
| Proxy-Benutzername/-passwort | Zugriff des Clients auf den Proxy. |
| Clientzertifikat und privater Schlüssel der Website | TLS-Sitzung der Anwendung mit dem Ziel. |
| Clientzertifikat des Proxyservers für Upstream | Eine TLS-Sitzung, die der Proxy selbst startet. |
Diese Rollen können zusammen bestehen. Der private Schlüssel der Website muss nicht auf einen einfachen Tunnelproxy geladen werden, damit Ziel-mTLS funktioniert. Nach dem CONNECT-Übergang verwenden Sie die normale Clientzertifikat-Konfiguration der Anwendung für das Ziel und prüfen weiterhin das Serverzertifikat der Website.
SSLProxyMachineCertificateFile liefert Zugangsdaten, wenn Apache seine eigene Upstream-TLS-Sitzung erstellt. Hinweise zu dieser Datei bedeuten nicht, dass jeder Client eines undurchsichtigen Forward-Tunnels sie konfigurieren muss.
TLS-Interception beendet eine Sitzung an einem Vermittler und verändert diese Zuordnung. Stellen Sie fest, ob die benötigte Clientidentität diese Anordnung passieren kann, statt anzunehmen, dass Kopieren eines Zertifikats Ende-zu-Ende-Authentifizierung bewahrt.
Bei einem Fehler notieren Sie, ob die Anfrage beim Proxy-Login, bei Ziel-TLS oder beim späteren Anwendungsaustausch stoppte. Hinterlegen Sie die Zugangsdaten auf der Verbindung, die sie tatsächlich anfordert.