Nork bidaltzen du bezeroaren ziurtagiria proxy baten bidez?
Mantendu helmugako mTLS kredentzialak proxyaren kredentzialetatik eta Apache-k bere goiko TLS saioa sortzean erabiltzen dituen ziurtagirietatik bereizita.
Ohiko CONNECT bidezko HTTPS erabileran, aplikazioak webguneko bezeroaren ziurtagiria bidaltzen du helmugarekiko bere TLS esku-ematean. Proxyak byteak bideratzen ditu soilik; ez da automatikoki bihurtzen webgunearen TLS bezero.
| Kredentziala | Jabea/konexioa |
|---|---|
| Proxyaren erabiltzaile-izena/pasahitza | Bezeroaren sarbidea proxyra. |
| Webgunearen bezero-ziurtagiria eta gako pribatua | Aplikazioaren TLS saioa helmugarekin. |
| Proxy zerbitzariaren goiko bezero-ziurtagiria | Proxyak berak hasten duen TLS saioa. |
Rol horiek elkarrekin egon daitezke. Ez da beharrezkoa webgunearen gako pribatua tunel-proxy soil batera igotzea helmugako mTLS funtziona dezan. CONNECT transferentziaren ondoren, erabili aplikazioaren helmugako bezero-ziurtagiriaren ohiko konfigurazioa eta jarraitu webgunearen zerbitzari-ziurtagiria egiaztatzen.
Apache-ren SSLProxyMachineCertificateFile-k kredentzialak ematen ditu Apachek bere goiko TLS saioa sortzen duenean. Fitxategi horri buruzko aholkuak ez du frogatzen tunel garden opakua erabiltzen duen bezero orok hura konfiguratu behar duenik.
TLS atzemateak saioa bitartekari batean amaitzen du eta jabetza hori aldatzen du. Egiaztatu beharrezko bezero-identitatea antolamendu horretatik pasa daitekeen, ziurtagiri bat kopiatzeak muturretik muturrera autentifikazioa gordetzen duela suposatu ordez.
Hutsegitean, idatzi eskaera proxyaren saio-hasieran, helmugako TLSn edo aplikazioaren ondorengo trukean gelditu zen. Jarri kredentziala benetan eskatzen duen konexioan.