HTTPS прокси мора да пошаље и свој ланац сертификата

Дијагностикујте недостајуће посредничке сертификате на TLS слушаоцу од клијента до Squid-а одвојено од сертификата циљне веб-странице.

Ако клијенти одбију HTTPS прокси пре него што стигну до веб-странице, прегледајте ланац који шаље слушалац проксија. Само важећи завршни сертификат можда не пружа посредничке сертификате који су клијенту потребни.

  1. Идентификујте крајњу тачку која се проверава. Прочитајте назив хоста у конфигурисаном URL-у проксија и грешку за ту везу. Сертификат слушаоца мора да покрива тај назив. Сертификат веб-странице или сертификат за други IP алијас не може га заменити.
  2. Проверите конфигурацију ланца слушаоца. Подржана OpenSSL конфигурација Squid-а може да укључи посредничке сертификате у датотеку сертификата. Потврдите распоред у референци слушаоца за инсталирану верзију Squid-а и TLS backend; понашање пакета није уједначено. Пример TLS слушаоца у Squid-у 6.13 држи поверење слушаоца одвојено од TLS-а одредишта.
  3. Проверите поверење клијента одвојено. Слање посредничких сертификата помаже изградњи ланца, али клијенту и даље треба предвиђено коренско сидро поверења. Увоз целог серверског ланца у коренско складиште без разлике је друга измена од исправљања онога што сервер шаље.

Оставите проверу укљученом. Она идентификује HTTPS прокси који је клијент намеравао да користи. Након што се та веза потврди, каснија грешка сертификата веб-странице припада TLS сесији одредишта кроз прокси, са сопственом истрагом назива хоста и поверења.

Повезани чланци