Vem skickar klientcertifikatet genom en proxy?
Håll destinationens mTLS-uppgifter åtskilda från proxyns uppgifter och från de certifikat som Apache använder när det skapar sin egen uppströms TLS-session.
Vid vanlig HTTPS genom CONNECT skickar programmet webbplatsens klientcertifikat under sin egen TLS-handskakning med destinationen. Proxyn vidarebefordrar bara byte; den blir inte automatiskt webbplatsens TLS-klient.
| Uppgift | Ägare/anslutning |
|---|---|
| Proxy-användarnamn/lösenord | Klientens åtkomst till proxyn. |
| Webbplatsens klientcertifikat och privata nyckel | Programmets TLS-session med destinationen. |
| Proxyserverns uppströms klientcertifikat | En TLS-session som proxyn själv initierar. |
Dessa roller kan samexistera. Det krävs inte att webbplatsens privata nyckel laddas upp till en enkel tunnelproxy för att mTLS mot destinationen ska fungera. Efter CONNECT-överlämningen använder du programmets vanliga konfiguration för klientcertifikat mot destinationen och fortsätter verifiera webbplatsens servercertifikat.
Apaches SSLProxyMachineCertificateFile tillhandahåller uppgifter när Apache skapar sin egen uppströms TLS-session. Råd om den filen bevisar inte att varje klient som använder en ogenomskinlig vidarebefordringstunnel måste konfigurera den.
TLS-avlyssning avslutar en session hos en mellanhand och ändrar detta ägande. Fastställ om den nödvändiga klientidentiteten kan passera genom det arrangemanget, i stället för att anta att kopiering av ett certifikat bevarar autentisering från ände till ände.
Vid fel, notera om begäran stoppade vid proxyinloggningen, vid destinationens TLS eller vid den senare programutväxlingen. Placera uppgiften på den anslutning som faktiskt begär den.