Cargo se CA-bundels vir die proksie en pakketbediener
Pas Cargo se cainfo en proxy-cainfo op die regte TLS-verbinding toe, eerder as om elke proksiesertifikaatfout as een vertrouensprobleem te behandel.
Vir 'n HTTPS-proksie en HTTPS-pakketbron kan Cargo twee TLS-verbindings met verskillende CA-bundels verifieer:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"Vervang die eindpunt en paaie met jou goedgekeurde waardes. Hierdie proksie het doelbewus 'n TLS-luisteraar; 'n gewone HTTP-proksie word nie HTTPS omdat die pakketbron HTTPS gebruik nie.
| Foutstadium | Vertrouensinstelling om na te gaan |
|---|---|
| Proksie-TLS, voordat 'n bestemmingstonnel bestaan | http.proxy-cainfo, wat op http.cainfo terugval as dit nie afsonderlik ingestel is nie. |
| Bestemmingsertifikaat ná tonnelvestiging | http.cainfo vir die bestemming se vertrouenspad. |
Die ooreenstemmende veranderlikes is CARGO_HTTP_PROXY_CAINFO en CARGO_HTTP_CAINFO. Gebruik die toepaslike goedgekeurde sertifikaatowerheid; om 'n willekeurige sertifikaat na albei lêers te kopieer, wys nie watter verbinding foutief is nie.
'n Ongeënkripteerde HTTP-proksie wat CONNECT dra, het geen proksieluisteraar-TLS-sertifikaat om te verifieer nie. 'n Bestemmingsfout daar word nie reggestel deur 'n proksie-CA-lêer uit te dink nie. Gaan ook na dat 'n ingestelde pad binne die werklike houer of CI-taak bestaan, en neem bedryfstelsel- en TLS-agterkantgedrag in ag wanneer jy omgewings vergelyk.
Hou verifikasie geaktiveer. Dit verskaf die identiteitskontrole wat nodig is om die bedoelde diens van 'n oordrag wat bloot voortgaan te onderskei.