Een HTTPS-proxy moet ook zijn certificaatketen sturen

Als clients de HTTPS-proxy weigeren voordat ze een website bereiken, inspecteer dan de keten die de proxylistener stuurt. Een geldig bladcertificaat alleen levert mogelijk niet de tussenliggende certificaten die de client nodig heeft.

1. Identificeer het gecontroleerde eindpunt. Lees de hostnaam in de geconfigureerde proxy-URL en de fout voor die verbinding. Het listenercertificaat moet die naam dekken. Een websitecertificaat of certificaat voor een andere IP-alias kan het niet vervangen.
2. Controleer de ketenconfiguratie van de listener. De door Squid ondersteunde OpenSSL-configuratie kan tussenliggende certificaten in het certificaatbestand opnemen. Bevestig de opbouw in de listenerreferentie voor de geïnstalleerde Squid-versie en TLS-backend; het gedrag van pakketten is niet uniform. Het TLS-listenervoorbeeld van Squid 6.13 houdt het vertrouwen van de listener gescheiden van de TLS van de bestemming.
3. Controleer het clientvertrouwen apart. Het sturen van tussenliggende certificaten helpt de keten op te bouwen, maar de client heeft nog steeds het bedoelde wortelvertrouwensanker nodig. De volledige serverketen klakkeloos in een root-store importeren is een andere wijziging dan corrigeren wat de server stuurt.

Laat verificatie aan staan. Het identificeert de HTTPS-proxy die de client wilde gebruiken. Nadat die verbinding is geverifieerd, hoort een latere websitecertificaatfout bij de TLS-sessie van de bestemming via de proxy, met een eigen hostnaam- en vertrouwensonderzoek.