HTTPS прокси мора да ја испрати и својата синџир од сертификати
Дијагностицирајте ги сертификатите што недостасуваат на TLS слушателот од клиентот до Squid одделно од сертификатот на целната веб-страница.
Ако клиентите го одбијат HTTPS проксито пред да стигнат до веб-страница, проверете го синџирот што го испраќа слушателот на проксито. Само важечки завршен сертификат можеби не ги обезбедува сертификатите што му се потребни на клиентот.
- Идентификувајте ја проверената крајна точка. Прочитајте го името на домаќинот во конфигурираната URL на проксито и грешката за таа врска. Сертификатот на слушателот мора да го покрива тоа име. Сертификат на веб-страница или сертификат за друг IP псевдоним не може да го замени.
- Проверете ја конфигурацијата на синџирот на слушателот. Поддржаната OpenSSL конфигурација на Squid може да вклучи сертификати во датотеката со сертификати. Потврдете го распоредот во референцата на слушателот за инсталираната верзија на Squid и TLS backend; однесувањето на пакетите не е еднообразно. Примерот на TLS слушател во Squid 6.13 го држи довербата на слушателот одделно од TLS на целта.
- Проверете ја довербата на клиентот одделно. Испраќањето сертификати помага да се изгради синџирот, но на клиентот сè уште му треба предвиденото коренско сидро на доверба. Увезувањето на целиот серверски синџир во коренско складиште без разлика е друга промена од исправањето на она што го испраќа серверот.
Оставете ја проверката вклучена. Таа го идентификува HTTPS проксито што клиентот имал намера да го користи. Откако таа врска ќе се потврди, подоцнежната грешка на сертификатот на веб-страницата и припаѓа на TLS сесијата на целта преку проксито, со сопствена истрага за името на домаќинот и довербата.