ప్రాక్సీ మరియు ప్యాకేజీ సర్వర్ కోసం Cargo CA బండిల్లు
Cargo cainfo, proxy-cainfo ను సరైన TLS కనెక్షన్కు వర్తింపజేయండి; అన్ని ప్రాక్సీ సర్టిఫికెట్ వైఫల్యాలను ఒకే నమ్మక సమస్యగా పరిగణించవద్దు.
HTTPS ప్రాక్సీ, HTTPS ప్యాకేజీ మూలం కోసం Cargo వేర్వేరు CA బండిల్లతో రెండు TLS కనెక్షన్లను ధృవీకరించగలదు:
[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. తగిన ఆమోదిత సర్టిఫికెట్ అథారిటీ వాడండి; ఏదో సర్టిఫికెట్ను రెండు ఫైళ్లలో కాపీ చేయడం వల్ల ఏ కనెక్షన్ తప్పో తెలియదు.
CONNECT మోసే ఎన్క్రిప్షన్ లేని HTTP ప్రాక్సీలో ధృవీకరించాల్సిన ప్రాక్సీ లిసనర్ TLS సర్టిఫికెట్ ఉండదు. అలాంటి గమ్యస్థాన దోషం కల్పిత ప్రాక్సీ CA ఫైల్తో పరిష్కారం కాదు. కాన్ఫిగర్ చేసిన పథం అసలు కంటైనర్ లేదా CI జాబ్లో ఉందో చూడండి; పర్యావరణాలను పోల్చేటప్పుడు ఆపరేటింగ్ సిస్టమ్, TLS బ్యాక్ఎండ్ ప్రవర్తనను పరిగణించండి.
ధృవీకరణను ప్రారంభించి ఉంచండి. ఉద్దేశించిన సేవను కేవలం కొనసాగుతున్న బదిలీ నుంచి వేరు చేయడానికి అవసరమైన గుర్తింపు తనిఖీని అది అందిస్తుంది.