HTTPS-праксі таксама павінен адпраўляць ланцужок сертыфікатаў
Дыягнастуйце адсутныя прамежкавыя сертыфікаты на TLS-слухачы ад кліента да Squid асобна ад сертыфіката сайта прызначэння.
Калі кліенты адхіляюць HTTPS-праксі да таго, як дасягнуць сайта, праверце ланцужок, які адпраўляе слухач праксі. Адзін сапраўдны канцавы сертыфікат можа не даць прамежкавых сертыфікатаў, патрэбных кліенту.
- Вызначце кропку, якая правяраецца. Прачытайце імя хоста ў наладжаным URL праксі і памылку для гэтага злучэння. Сертыфікат слухача павінен пакрываць гэтае імя. Сертыфікат сайта або сертыфікат для іншага псеўданіма IP не можа яго замяніць.
- Праверце налады ланцужка слухача. Падтрымліваная Squid канфігурацыя OpenSSL можа ўключаць прамежкавыя сертыфікаты ў файл сертыфіката. Пацвердзіце парадак у даведцы слухача для ўсталяванай версіі Squid і TLS-бэкэнда; паводзіны пакетаў не аднолькавыя. Прыклад TLS-слухача Squid 6.13 трымае давер слухача асобна ад TLS прызначэння.
- Праверце давер кліента асобна. Адпраўка прамежкавых сертыфікатаў дапамагае пабудаваць ланцужок, але кліенту ўсё яшчэ патрэбны каранёвы якар даверу. Імпарт усяго сервернага ланцужка ў сховішча каранёў без разбору — гэта іншае змяненне, чым выпраўленне таго, што адпраўляе сервер.
Пакіньце праверку ўключанай. Яна вызначае HTTPS-праксі, які кліент меў намер выкарыстоўваць. Пасля праверкі гэтага злучэння пазнейшая памылка сертыфіката сайта адносіцца да сесіі TLS прызначэння праз праксі, з уласным імем хоста і даследаваннем даверу.