’n HTTPS-proxy moet ook sy sertifikaatketting stuur

As kliënte die HTTPS-proxy verwerp voordat hulle ’n webwerf bereik, ondersoek die ketting wat die proxy-luisteraar stuur. ’n Geldige bladsertifikaat alleen voorsien dalk nie die intermediêre sertifikate wat die kliënt nodig het nie.

1. Identifiseer die gemete eindpunt. Lees die gasheernaam in die gekonfigureerde proxy-URL en die fout vir daardie verbinding. Die luisteraarsertifikaat moet daardie naam dek. ’n Webwerfsertifikaat of ’n sertifikaat vir ’n ander IP-alias kan dit nie vervang nie.
2. Kontroleer die luisteraar se kettingkonfigurasie. Squid se ondersteunde OpenSSL-konfigurasie kan intermediêre sertifikate in die sertifikaatlêer insluit. Bevestig die reëling in die luisteraarverwysing vir die geïnstalleerde Squid-weergawe en TLS-agterkant; pakketgedrag is nie eenvormig nie. Die Squid 6.13 TLS-luisteraar-voorbeeld hou luisteraarvertroue apart van die bestemming se TLS.
3. Kontroleer kliëntvertroue afsonderlik. Om intermediêre sertifikate te stuur help om die ketting te bou, maar die kliënt het steeds die beoogde wortelvertrouensanker nodig. Om die hele bedienerketting blindelings in ’n wortelstoor te importeer is ’n ander verandering as om reg te maak wat die bediener stuur.

Hou verifikasie aan. Dit identifiseer die HTTPS-proxy wat die kliënt bedoel het om te gebruik. Nadat daardie verbinding verifieer, hoort ’n latere webwerfsertifikaatfout by die bestemming se TLS-sessie deur die proxy, met sy eie gasheernaam- en vertroue-ondersoek.