Sino ang Nagpapadala ng Sertipiko ng Kliyente sa Pamamagitan ng Proxy?
Panatilihing hiwalay ang mTLS na kredensyal ng destinasyon mula sa kredensyal ng proxy at sa mga sertipiko na ginagamit ng Apache kapag gumagawa ito ng sarili nitong upstream TLS session.
Sa karaniwang HTTPS sa pamamagitan ng CONNECT, ipinapadala ng aplikasyon ang sertipiko ng kliyente ng website sa sarili nitong TLS handshake sa destinasyon. Nagpapasa lang ng byte ang proxy; hindi ito awtomatikong nagiging TLS client ng website.
| Kredensyal | May-ari/koneksyon |
|---|---|
| Username/password ng proxy | Pag-access ng kliyente sa proxy. |
| Sertipiko ng kliyente at pribadong susi ng website | TLS session ng aplikasyon sa destinasyon. |
| Upstream na sertipiko ng kliyente ng proxy server | TLS session na mismo ang proxy ang nag-uumpisa. |
Maaaring magkasabay ang mga papel na ito. Hindi kailangang i-upload ang pribadong susi ng website sa simpleng tunneling proxy para gumana ang mTLS sa destinasyon. Pagkatapos ng pagpasa ng CONNECT, gamitin ang karaniwang configuration ng sertipiko ng kliyente sa destinasyon sa aplikasyon at magpatuloy sa pag-verify ng sertipiko ng server ng website.
Ang SSLProxyMachineCertificateFile ng Apache ay nagbibigay ng kredensyal kapag gumagawa ang Apache ng sarili nitong upstream TLS session. Ang payo tungkol sa file na iyon ay hindi nagpapatunay na bawat kliyenteng gumagamit ng opaque na forward tunnel ay dapat itong i-configure.
Ang TLS interception ay nagtatapos ng session sa isang tagapamagitan at binabago ang pagmamay-ari na ito. Alamin kung ang kinakailangang pagkakakilanlan ng kliyente ay makakadaan sa ganitong kaayusan sa halip na ipagpalagay na pinapanatili ng pagkopya ng sertipiko ang end-to-end na pagpapatotoo.
Kapag nabigo, itala kung huminto ang kahilingan sa pag-login sa proxy, sa TLS ng destinasyon o sa susunod na palitan ng aplikasyon. Ilagay ang kredensyal sa koneksyon na talagang humihiling nito.