Яка сторона інспекційного проксі відхилила сертифікат?

Клієнт довіряє схваленому інспекційному проксі. Запит усе одно завершується помилкою сертифіката. Обидва факти можуть бути правдивими: у цього проксі є ще одне з'єднання TLS для перевірки.

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

У схемі перехоплення посередник завершує TLS клієнта й створює власне з'єднання далі. Клієнт може прийняти сертифікат, пред'явлений з його боку, тоді як проксі відхиляє сертифікат, отриманий від веб-сайту.

Прочитайте помилку перевіряльника

Визначте, який процес повідомив про невдалий ланцюжок або ім'я вузла. Сторінка помилки, створена проксі, може успішно дійти до клієнта через дійсне з'єднання. Чергова зміна CA-файлу клієнта не оновлює конфігурацію довіри проксі до вищої сторони.

Наприклад, Mitmproxy документує окремі параметри довіри до вищої сторони, зокрема ssl_verify_upstream_trusted_ca. Відповідний адміністратор може налаштувати схвалену довіру для служби вгорі за потоком, зберігаючи перевірку. Іншому проксі-продукту потрібен свій відповідний інтерфейс.

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

Звичайний тунель CONNECT інший

Непрозорий тунель пересилання не розділяє TLS призначення таким чином. Застосунок зазвичай сам узгоджує й перевіряє цей сеанс TLS від краю до краю. Спершу встановіть, чи перехоплення справді є частиною маршруту, замість застосовувати налаштування інспекційного проксі до будь-якого посередника.

Записуйте два результати перевірки окремо. «Сертифікату проксі можна довіряти» відповідає на питання з боку клієнта; це не засвідчує, що проксі бачив, з'єднуючись угору.