En HTTPS-proxy skal også sende sin certifikatkæde

Hvis klienter afviser HTTPS-proxyen, før de når et websted, skal du undersøge den kæde, som proxylytteren sender. Et gyldigt bladcertifikat alene giver måske ikke de mellemliggende certifikater, som klienten har brug for.

1. Identificér det kontrollerede endepunkt. Læs værtsnavnet i den konfigurerede proxy-URL og fejlen for den forbindelse. Lytterens certifikat skal dække det navn. Et webstedscertifikat eller certifikat for et andet IP-alias kan ikke erstatte det.
2. Kontrollér lytterens kædekonfiguration. Squids understøttede OpenSSL-konfiguration kan medtage mellemliggende certifikater i certifikatfilen. Bekræft arrangementet i lytterreferencen for den installerede Squid-version og TLS-backend; pakkeadfærd er ikke ensartet. TLS-lyttereksemplet i Squid 6.13 holder lyttertillid adskilt fra destinationens TLS.
3. Kontrollér klientens tillid særskilt. At sende mellemliggende certifikater hjælper med at opbygge kæden, men klienten har stadig brug for det tilsigtede rodtillidsanker. At importere hele serverkæden til et rodlager uden skelnen er en anden ændring end at rette det, serveren sender.

Lad verifikationen være slået til. Den identificerer den HTTPS-proxy, som klienten havde til hensigt at bruge. Når den forbindelse er verificeret, hører en senere webstedscertifikatfejl til destinationens TLS-session gennem proxyen, med sin egen værtsnavns- og tillidsundersøgelse.