Коя страна на инспекционния прокси отхвърли сертификата?

Клиентът се доверява на одобреното инспекционно прокси. Заявката все още се проваля заради грешка със сертификата. И двата факта могат да са верни: това прокси има още една TLS връзка за проверка.

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

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

Прочетете грешката на проверяващия

Определете кой процес е съобщил за неуспешната верига или име на хост. Генерирана от проксито страница за грешка може успешно да достигне до клиента по валидна връзка. Поредната промяна на CA файла на клиента не обновява конфигурацията за доверие на проксито нагоре по веригата.

Например Mitmproxy документира отделни опции за доверие нагоре по веригата, включително ssl_verify_upstream_trusted_ca. Съответният администратор може да настрои одобрено доверие за услугата нагоре, като същевременно запази проверката. Друг прокси продукт се нуждае от съответния си интерфейс.

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

Обикновеният CONNECT тунел е различен

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

Записвайте двата резултата от проверката поотделно. „Сертификатът на проксито е надежден“ отговаря на въпроса от страна на клиента; той не удостоверява какво е видяло проксито, когато се е свързало нагоре.