HTTPS-прокси тоже должен отправлять свою цепочку сертификатов

Если клиенты отклоняют HTTPS-прокси ещё до обращения к сайту, проверьте цепочку, которую отправляет слушатель прокси. Один действительный конечный сертификат может не давать промежуточных сертификатов, нужных клиенту.

1. Определите проверяемую конечную точку. Прочитайте имя хоста в настроенном URL прокси и ошибку для этого соединения. Сертификат слушателя должен покрывать это имя. Сертификат сайта или сертификат для другого псевдонима IP не может его заменить.
2. Проверьте конфигурацию цепочки слушателя. Поддерживаемая Squid конфигурация OpenSSL может включать промежуточные сертификаты в файл сертификата. Подтвердите порядок в справочнике слушателя для установленной версии Squid и TLS backend; поведение пакетов неодинаково. Пример TLS-слушателя в Squid 6.13 держит доверие слушателя отдельно от TLS назначения.
3. Проверьте доверие клиента отдельно. Отправка промежуточных сертификатов помогает построить цепочку, но клиенту всё ещё нужен предусмотренный корневой якорь доверия. Импорт всей серверной цепочки в корневое хранилище без разбора — это другое изменение, чем исправление того, что отправляет сервер.

Оставьте проверку включённой. Она определяет HTTPS-прокси, который клиент собирался использовать. После проверки этого соединения более поздняя ошибка сертификата сайта относится к TLS-сессии назначения через прокси, с собственным исследованием имени хоста и доверия.