Перевірте сертифікат вебсайту через HTTP-проксі за допомогою OpenSSL
Використовуйте OpenSSL s_client через HTTP CONNECT-проксі та узгодьте назву призначення, SNI і перевірку сертифіката.
Використовуйте встановлений OpenSSL s_client із підтримкою -proxy. Для авторизованої кінцевої точки HTTP CONNECT:
openssl s_client -proxy proxy.example:3128 -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsЗамініть адресу проксі та послідовно використовуйте потрібне ім’я призначення. Для перевірки публічного призначення через проксі, який можна вибрати, виберіть HTTP-кандидата зі списку HTTP-проксі. -connect вибирає ціль, -servername надсилає SNI для її віртуального TLS-хоста, а -verify_hostname перевіряє ідентичність. Самого SNI недостатньо для перевірки імені хоста. Під час адаптації параметрів перевірте посібник встановленого випуску.
-showcerts показує те, що надіслав сервер, але не оголошує ланцюжок довіреним. -verify_return_error завершує handshake через помилки перевірки; інакше діагностичний клієнт може продовжити після помилок. Для приватної служби використовуйте схвалений матеріал CA, а не довіряйте випадково завантаженому сертифікату.
| Результат | Етап |
|---|---|
| 407 | Автентифікація проксі до TLS призначення. |
| Відхилене призначення CONNECT | Політика призначення проксі. |
| Сертифікат отримано, перевірку виконано | TLS-обмін призначення через прийнятий тунель. |
В OpenSSL 3.x з HTTP-проксі та Basic-автентифікацією використовуйте параметри проксі-облікового запису s_client, зберігаючи перевірку призначення.
Кінцева точка лише SOCKS не надає інтерфейсу HTTP-проксі, який використовує ця команда. За дозволеного перехоплення TLS показаний сертифікат може видати цей посередник. Порівняйте його видавця та передбачену схему довіри, перш ніж приписувати різницю несправному вебсайту.