Какая сторона инспектирующего прокси отклонила сертификат?

Клиент доверяет одобренному инспектирующему прокси. Запрос всё равно завершается ошибкой сертификата. Оба факта могут быть верны: у этого прокси есть ещё одно TLS-соединение для проверки.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

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

Прочитайте ошибку проверяющего

Определите, какой процесс сообщил о неудачной цепочке или имени узла. Страница ошибки, созданная прокси, может успешно дойти до клиента по действительному соединению. Очередная замена CA-файла клиента не обновляет конфигурацию доверия прокси к вышестоящей стороне.

Например, Mitmproxy документирует отдельные параметры доверия к вышестоящей стороне, включая ssl_verify_upstream_trusted_ca. Компетентный администратор может настроить одобренное доверие для вышестоящей службы, сохранив проверку. Другому прокси-продукту нужен свой соответствующий интерфейс.

Проверьте также фактическое имя назначения и цепочку. Частная служба без промежуточного сертификата, просроченный сертификат и неизвестный частный издатель требуют разных исправлений. Преднамеренное исключение для одной частной службы не должно молча превращаться в глобальное принятие любого сертификата.

Обычный туннель CONNECT устроен иначе

Непрозрачный туннель пересылки не разделяет TLS назначения таким образом. Приложение обычно само согласует и проверяет этот сквозной сеанс TLS. Сначала установите, действительно ли перехват входит в маршрут, вместо того чтобы применять настройки инспектирующего прокси к любому посреднику.

Записывайте два результата проверки отдельно. «Сертификату прокси можно доверять» отвечает на вопрос со стороны клиента; это не удостоверяет, что прокси видел при соединении вверх.