Ko šalje klijentski certifikat kroz proxy?
Držite mTLS akreditive odredišta odvojeno od proxy akreditiva i od certifikata koje Apache koristi kada stvara sopstvenu izlaznu TLS sesiju.
Kod običnog HTTPS-a kroz CONNECT aplikacija šalje klijentski certifikat sajta tokom sopstvenog TLS rukovanja sa odredištem. Proxy samo prenosi bajtove; ne postaje automatski TLS klijent sajta.
| Akreditiv | Vlasnik/veza |
|---|---|
| Korisničko ime/lozinka proxyja | Pristup klijenta proxyju. |
| Klijentski certifikat sajta i privatni ključ | TLS sesija aplikacije sa odredištem. |
| Izlazni klijentski certifikat proxy servera | TLS sesija koju sam proxy pokreće. |
Te uloge mogu postojati zajedno. Prenos privatnog ključa sajta na obični tunelski proxy nije potreban da bi mTLS prema odredištu radio. Nakon predaje CONNECT koristite uobičajenu konfiguraciju klijentskog certifikata odredišta u aplikaciji i nastavite da proveravate certifikat servera sajta.
SSLProxyMachineCertificateFile u Apacheju daje akreditive kada Apache stvara sopstvenu izlaznu TLS sesiju. Savet o toj datoteci ne dokazuje da svaki klijent koji koristi neprozirni prosleđujući tunel mora da je konfiguriše.
Presretanje TLS-a prekida sesiju kod posrednika i menja ovo vlasništvo. Utvrdite da li traženi identitet klijenta može da prođe kroz takav raspored, umesto da pretpostavite da kopiranje certifikata čuva proveru identiteta od kraja do kraja.
Kod kvara zabeležite da li se zahtev zaustavio na prijavi na proxy, na TLS-u odredišta ili na kasnijoj razmeni aplikacije. Stavite akreditiv na vezu koja ga zaista traži.