Памылкі сертыфікатаў пры выкарыстанні проксі
Перш чым мяняць налады сертыфікатаў, высветліце, дзе не прайшла праверка: у 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.