Mga CA Bundle ng Cargo para sa Proxy at Package Server
Ilapat ang cainfo at proxy-cainfo ng Cargo sa tamang TLS connection sa halip na ituring ang lahat ng proxy certificate failure na iisang problema sa tiwala.
Para sa HTTPS proxy at HTTPS package source, kayang beripikahin ng Cargo ang dalawang TLS connection gamit ang magkaibang CA bundle:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"Palitan ang endpoint at mga path ng mga aprubadong halaga. Sadyang may TLS listener ang proxy na ito; ang karaniwang HTTP proxy ay hindi nagiging HTTPS dahil gumagamit ng HTTPS ang package source.
| Yugto ng pagkabigo | Trust setting na susuriin |
|---|---|
| TLS ng proxy, bago magkaroon ng tunnel sa destinasyon | http.proxy-cainfo, na gumagamit ng http.cainfo kapag hindi hiwalay na itinakda. |
| Certificate ng destinasyon matapos mabuo ang tunnel | http.cainfo para sa trust path ng destinasyon. |
Ang katumbas na mga variable ay CARGO_HTTP_PROXY_CAINFO at CARGO_HTTP_CAINFO. Gamitin ang angkop at aprubadong certificate authority; hindi matutukoy kung aling koneksyon ang mali sa pagkopya ng basta certificate sa parehong file.
Walang TLS certificate ng proxy listener na ibeberipika ang hindi naka-encrypt na HTTP proxy na nagdadala ng CONNECT. Hindi maaayos ang error ng destinasyon sa ganitong kaso sa pag-imbento ng proxy CA file. Tingnan din kung umiiral ang naka-configure na path sa aktuwal na container o CI job, at isaalang-alang ang asal ng operating system at TLS backend kapag naghahambing ng mga environment.
Panatilihing naka-enable ang beripikasyon. Ibinibigay nito ang identity check na kailangan upang maiba ang nilalayong serbisyo sa transfer na basta nagpapatuloy lamang.