HTTPS-проксі також має надсилати свій ланцюжок сертифікатів

Діагностуйте відсутні проміжні сертифікати на TLS-слухачі від клієнта до Squid окремо від сертифіката цільового сайту.

Якщо клієнти відхиляють HTTPS-проксі ще до звернення до сайту, перевірте ланцюжок, який надсилає слухач проксі. Один чинний кінцевий сертифікат може не давати проміжних сертифікатів, потрібних клієнту.

  1. Визначте перевірювану кінцеву точку. Прочитайте ім'я хоста в налаштованому URL проксі та помилку для цього з'єднання. Сертифікат слухача має покривати це ім'я. Сертифікат сайту або сертифікат для іншого псевдоніма IP не може його замінити.
  2. Перевірте конфігурацію ланцюжка слухача. Підтримувана Squid конфігурація OpenSSL може включати проміжні сертифікати у файл сертифіката. Підтвердьте порядок у довідці слухача для встановленої версії Squid і TLS backend; поведінка пакунків неоднакова. Приклад TLS-слухача в Squid 6.13 тримає довіру слухача окремо від TLS призначення.
  3. Перевірте довіру клієнта окремо. Надсилання проміжних сертифікатів допомагає побудувати ланцюжок, але клієнту все ще потрібен передбачений кореневий якір довіри. Імпорт усього серверного ланцюжка в кореневе сховище без розбору — це інша зміна, ніж виправлення того, що надсилає сервер.

Залиште перевірку ввімкненою. Вона визначає HTTPS-проксі, який клієнт мав намір використовувати. Після перевірки цього з'єднання пізніша помилка сертифіката сайту належить TLS-сесії призначення через проксі, з власним дослідженням імені хоста й довіри.

Схожі статті