Ошибки сертификатов при использовании прокси
Прежде чем менять настройки сертификатов, выясните, где не прошла проверка: в 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.