Kailangan din ng HTTPS proxy na ipadala ang chain ng certificate nito

Suriin ang mga nawawalang intermediate na certificate sa TLS listener mula sa client patungong Squid nang hiwalay sa certificate ng destinasyong website.

Kung tinatanggihan ng mga client ang HTTPS proxy bago makarating sa isang website, siyasatin ang chain na ipinapadala ng listener ng proxy. Maaaring hindi magbigay ng mga intermediate na certificate na kailangan ng client ang isang valid na leaf certificate lamang.

  1. Tukuyin ang endpoint na sinusuri. Basahin ang hostname sa naka-configure na URL ng proxy at ang error para sa koneksyong iyon. Dapat saklawin ng certificate ng listener ang pangalang iyon. Hindi ito mapapalitan ng certificate ng isang website o certificate para sa ibang IP alias.
  2. Suriin ang configuration ng chain ng listener. Maaaring isama ng sinusuportahang OpenSSL configuration ng Squid ang mga intermediate sa file ng certificate. Kumpirmahin ang ayos sa reference ng listener para sa naka-install na bersyon ng Squid at TLS backend; hindi pare-pareho ang pag-uugali ng mga package. Ang halimbawa ng TLS listener ng Squid 6.13 ay naghihiwalay ng tiwala ng listener sa TLS ng destinasyon.
  3. Suriin nang hiwalay ang tiwala ng client. Nakakatulong ang pagpapadala ng mga intermediate sa pagbuo ng chain, ngunit kailangan pa rin ng client ang inilaan na root trust anchor. Ang pag-import ng buong server chain sa root store nang walang pagtatangi ay ibang pagbabago kaysa sa pagwawasto ng ipinapadala ng server.

Iwanang naka-on ang verification. Tinutukoy nito ang HTTPS proxy na balak gamitin ng client. Kapag na-verify ang koneksyong iyon, ang susunod na error sa certificate ng website ay pag-aari ng TLS session ng destinasyon sa pamamagitan ng proxy, na may sariling pagsisiyasat sa hostname at tiwala.

Kaugnay na mga artikulo