Помилки сертифікатів під час використання проксі
Перш ніж змінювати налаштування сертифікатів, з’ясуйте, де не пройшла перевірка: у TLS-з’єднанні із самим проксі чи з цільовим сайтом.
Перш ніж змінювати набір CA, з’ясуйте, яке TLS-рукостискання не вдалося. Сертифікат проксі та сертифікат сайту можуть перевірятися в різних з’єднаннях.
| Проксі й призначення | Перевірки TLS |
|---|---|
| HTTP-проксі для HTTPS-сайту | Після CONNECT перевірте сертифікат призначення через тунель. |
| HTTPS-проксі для HTTPS-сайту | Спочатку перевірте TLS до проксі; після відкриття тунелю — окрему TLS-сесію до призначення. |
За докладним трасуванням визначте запитане ім’я хоста та останнє завершене рукостискання. Помилка сертифіката HTTPS-проксі може виникнути ще до звернення до сайту. Перевірте очікуване ім’я цього з’єднання, строк дії сертифіката, місцевий годинник, очікуваний ланцюжок і затверджене сховище довіри. Врахуйте навмисно налаштоване перехоплення TLS або доданий кореневий сертифікат.
curl надає окремі параметри CA для двох з’єднань:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert задає довіру для проксі; --cacert — для призначення. Замініть адресу й файли з прикладу значеннями з обраної схеми довіри. Власні набори не потрібні, якщо системної довіри вже досить.
Заміна імені хоста довільною IP-адресою змінює зіставлення сертифіката. Пропуск перевірки може приховати збій без підтвердження ідентичності іншої сторони. Для незнайомого проксі прохання встановити його кореневий CA — недостатня підстава довіряти йому.
Відмова в з’єднанні з портом чи відхилений CONNECT належать до попереднього етапу; зміна сертифікатів їх не виправить. І навпаки: після перевірки TLS призначення HTTP-помилка сайту стосується отриманої відповіді, а не чергового налаштування CA.