OpenSSL s_client: помилка 403 від проксі виникає до TLS призначення
Розглядайте 403 на CONNECT через проксі OpenSSL як збій на етапі тунелю і не діагностуйте сертифікат призначення за рукостисканням, яке так і не почалося.
Якщо openssl s_client отримує HTTP 403 у відповідь на свій запит CONNECT через проксі, починайте саме з цієї відмови. Запитаний тунель не встановлено.
З параметром -proxy s_client спершу просить HTTP-проксі підключитися до призначення, вказаного в -connect. Лише успішна відповідь CONNECT перетворює цей обмін на тунель для TLS-рукостискання з призначенням.
Цей порядок пояснює інакше заплутаний вивід: помилка проксі, за якою йдуть заголовки, пов'язані з TLS, відсутність сертифіката партнера або зовні заспокійливий рядок перевірки. Ці поля не доводять, що сертифікат призначення було отримано й перевірено. Операція зупинилася на ранішому етапі.
Запишіть відповідь проксі, а також запитані хост і порт призначення. Відповідь 403 скеровує увагу до рішення проксі про доступ; відповідь 407 вимагає автентифікації на проксі. Ні те, ні інше не виправляється вимкненням перевірки сертифіката призначення.
Коли обмін дозволено дослідити, вивід -debug у s_client може допомогти виявити відмову. Тримайте будь-які облікові дані проксі поза спільними трасуваннями. Успішному тунелю згодом усе одно знадобиться власна оцінка TLS і сертифікатів, але ланцюга сертифікатів цілі для діагностики немає, доки цього етапу справді не досягнуто.