Грешки в сертификатите при използване на прокси
Преди да променяте сертификатите, установете дали проверката е неуспешна при 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 настройка.