Hvem sender klientcertifikatet gjennom en proxy?
Hold destinasjonens mTLS-legitimasjon atskilt fra proxyens legitimasjon og fra sertifikatene Apache bruker når det oppretter sin egen oppstrøms TLS-økt.
Ved vanlig HTTPS gjennom CONNECT sender applikasjonen nettstedets klientcertifikat under sin egen TLS-håndtrykk med destinasjonen. Proxyen videresender bare byte; den blir ikke automatisk nettstedets TLS-klient.
| Legitimasjon | Eier/tilkobling |
|---|---|
| Proxy-brukernavn/passord | Klientens tilgang til proxyen. |
| Nettstedets klientcertifikat og private nøkkel | Applikasjonens TLS-økt med destinasjonen. |
| Proxyserverens oppstrøms klientcertifikat | En TLS-økt som proxyen selv starter. |
Disse rollene kan eksistere side om side. Det er ikke nødvendig å laste opp nettstedets private nøkkel til en enkel tunnelproxy for at mTLS mot destinasjonen skal virke. Etter CONNECT-overleveringen bruker du applikasjonens vanlige oppsett for klientcertifikat mot destinasjonen og fortsetter å verifisere nettstedets servercertifikat.
Apaches SSLProxyMachineCertificateFile leverer legitimasjon når Apache oppretter sin egen oppstrøms TLS-økt. Råd om den filen beviser ikke at enhver klient som bruker en ugjennomsiktig videresendingstunnel, må konfigurere den.
TLS-avlytting avslutter en økt hos en mellommann og endrer dette eierskapet. Fastslå om den påkrevde klientidentiteten kan passere gjennom den ordningen, i stedet for å anta at kopiering av et sertifikat bevarer autentisering ende-til-ende.
Ved feil, noter om forespørselen stoppet ved proxy-innlogging, ved destinasjonens TLS eller ved den senere applikasjonsutvekslingen. Sett legitimasjonen på tilkoblingen som faktisk ber om den.