Hvem er det som sender klientcertifikatet gjennom en proxy?
Hold mTLS-legitimasjonen til destinasjonen atskilt fra proxyens legitimasjon og fra sertifikatene som Apache bruker når det oppretter sin egen oppstrøms TLS-økt.
Ved vanlig HTTPS gjennom CONNECT sender applikasjonen nettstedets klientcertifikat i sitt eget TLS-håndtrykk mot destinasjonen. Proxyen formidler 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 mot destinasjonen. |
| Proxyserverens oppstrøms klientcertifikat | En TLS-økt som proxyen selv starter. |
Disse rollene kan eksistere samtidig. Du trenger ikke laste opp nettstedets private nøkkel til en enkel tunnelproxy for at mTLS mot destinasjonen skal fungere. Etter CONNECT-overleveringen bruker du applikasjonens vanlige konfigurasjon for klientcertifikat mot destinasjonen og fortsetter å verifisere nettstedets servercertifikat.
Apache sin SSLProxyMachineCertificateFile skaffer legitimasjon når Apache oppretter sin egen oppstrøms TLS-økt. Råd om denne 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 nødvendige klientidentiteten kan passere gjennom denne 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. Plasser legitimasjonen på tilkoblingen som faktisk ber om den.