Wie stuurt het cliëntcertificaat via een proxy?
Houd mTLS-gegevens van de bestemming gescheiden van proxygegevens en van certificaten die Apache gebruikt voor zijn eigen upstream-TLS-sessie.
Bij gewone HTTPS via CONNECT stuurt de toepassing het cliëntcertificaat van de website tijdens haar eigen TLS-handshake met de bestemming. De proxy geeft bytes door; hij wordt niet automatisch de TLS-client van de website.
| Credential | Eigenaar/verbinding |
|---|---|
| Proxygebruikersnaam/wachtwoord | Toegang van de client tot de proxy. |
| Cliëntcertificaat en privésleutel van de website | TLS-sessie van de toepassing met de bestemming. |
| Upstream-cliëntcertificaat van de proxyserver | TLS-sessie die de proxy zelf start. |
Deze rollen kunnen naast elkaar bestaan. Je hoeft de privésleutel van de website niet naar een gewone tunnelproxy te uploaden om mTLS met de bestemming te laten werken. Gebruik na de CONNECT-overdracht de normale configuratie voor het bestemmingscertificaat in de toepassing en blijf het servercertificaat van de website controleren.
SSLProxyMachineCertificateFile levert gegevens wanneer Apache zijn eigen upstream-TLS-sessie maakt. Advies over dat bestand bewijst niet dat elke client met een ondoorzichtige forwardtunnel het moet configureren.
TLS-interceptie beëindigt een sessie bij een tussenpersoon en verandert dit eigenaarschap. Stel vast of de vereiste clientidentiteit door die opzet kan gaan in plaats van aan te nemen dat het kopiëren van een certificaat end-to-end-authenticatie behoudt.
Leg bij een fout vast of het verzoek stopte bij proxy-login, TLS van de bestemming of de latere uitwisseling met de toepassing. Plaats de credential op de verbinding die er werkelijk om vraagt.