Un proxy HTTPS trebuie să trimită și lanțul său de certificate

Dacă clienții resping proxy-ul HTTPS înainte de a ajunge la un site, inspectați lanțul trimis de listenerul proxy-ului. Un singur certificat frunză valid poate să nu furnizeze certificatele intermediare de care are nevoie clientul.

1. Identificați punctul final verificat. Citiți numele de gazdă din URL-ul proxy configurat și eroarea pentru acea conexiune. Certificatul listenerului trebuie să acopere acel nume. Un certificat de site sau un certificat pentru alt alias IP nu îl poate înlocui.
2. Verificați configurația lanțului listenerului. Configurația OpenSSL acceptată de Squid poate include certificate intermediare în fișierul de certificate. Confirmați aranjamentul în referința listenerului pentru versiunea Squid instalată și backendul TLS; comportamentul pachetelor nu este uniform. Exemplul de listener TLS din Squid 6.13 menține încrederea listenerului separată de TLS-ul destinației.
3. Verificați separat încrederea clientului. Trimiterea certificatelor intermediare ajută la construirea lanțului, dar clientul are în continuare nevoie de ancora de încredere rădăcină prevăzută. Importarea întregului lanț al serverului într-un depozit rădăcină fără discernământ este o modificare diferită de corectarea a ceea ce trimite serverul.

Lăsați verificarea activată. Aceasta identifică proxy-ul HTTPS pe care clientul intenționa să îl folosească. După ce acea conexiune este verificată, o eroare ulterioară de certificat al site-ului aparține sesiunii TLS a destinației prin proxy, cu propria investigație privind numele de gazdă și încrederea.