Наборы CA Cargo для проксі і сервера пакетаў
Ужывайце cainfo і proxy-cainfo Cargo да патрэбнага TLS-злучэння, не лічачы ўсе памылкі сертыфікатаў проксі адной праблемай даверу.
Для HTTPS-проксі і HTTPS-крыніцы пакетаў Cargo можа правяраць два TLS-злучэнні рознымі наборамі CA:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"Замяніце канцавы пункт і шляхі ўхваленымі значэннямі. Гэты проксі наўмысна мае TLS-слухач; звычайны HTTP-проксі не становіцца HTTPS праз тое, што крыніца пакетаў выкарыстоўвае HTTPS.
| Этап збою | Налада даверу для праверкі |
|---|---|
| TLS проксі да стварэння тунэля да прызначэння | http.proxy-cainfo; калі не зададзена асобна, выкарыстоўваецца http.cainfo. |
| Сертыфікат прызначэння пасля стварэння тунэля | http.cainfo для шляху даверу да прызначэння. |
Адпаведныя зменныя — CARGO_HTTP_PROXY_CAINFO і CARGO_HTTP_CAINFO. Выкарыстоўвайце належны ўхвалены цэнтр сертыфікацыі; капіяванне выпадковага сертыфіката ў абодва файлы не вызначыць, якое злучэнне памылковае.
Незашыфраваны HTTP-проксі, што перадае CONNECT, не мае TLS-сертыфіката слухача проксі для праверкі. Памылку прызначэння ў такім выпадку не выправіць выдуманым файлам CA проксі. Таксама праверце наяўнасць наладжанага шляху ў сапраўдным кантэйнеры або заданні CI і ўлічвайце паводзіны аперацыйнай сістэмы і TLS-бэкенда пры параўнанні асяроддзяў.
Пакідайце праверку ўключанай. Яна правярае ідэнтычнасць, каб адрозніць патрэбны сэрвіс ад перадачы, якая проста працягваецца.