Serwer proxy HTTPS musi też wysyłać swój łańcuch certyfikatów

Jeśli klienci odrzucają proxy HTTPS przed dotarciem do witryny, sprawdź łańcuch wysyłany przez nasłuch proxy. Sam prawidłowy certyfikat końcowy może nie dostarczać certyfikatów pośrednich, których potrzebuje klient.

1. Zidentyfikuj sprawdzany punkt końcowy. Odczytaj nazwę hosta ze skonfigurowanego adresu URL proxy oraz błąd tego połączenia. Certyfikat nasłuchu musi obejmować tę nazwę. Certyfikat witryny ani certyfikat dla innego aliasu IP nie może go zastąpić.
2. Sprawdź konfigurację łańcucha nasłuchu. Obsługiwana przez Squida konfiguracja OpenSSL może zawierać certyfikaty pośrednie w pliku certyfikatu. Potwierdź układ w dokumentacji nasłuchu dla zainstalowanej wersji Squida i backendu TLS; zachowanie pakietów nie jest jednolite. Przykład nasłuchu TLS w Squidzie 6.13 utrzymuje zaufanie nasłuchu oddzielnie od TLS celu.
3. Sprawdź osobno zaufanie klienta. Wysyłanie certyfikatów pośrednich pomaga zbudować łańcuch, ale klient nadal potrzebuje zamierzonego zakotwiczenia zaufania głównego. Importowanie całego łańcucha serwera do magazynu głównego bez rozróżnienia to inna zmiana niż poprawienie tego, co wysyła serwer.

Pozostaw weryfikację włączoną. Identyfikuje ona proxy HTTPS, którego klient zamierzał użyć. Po zweryfikowaniu tego połączenia późniejszy błąd certyfikatu witryny należy do sesji TLS celu przez proxy, z własnym dochodzeniem dotyczącym nazwy hosta i zaufania.