പ്രോക്സിക്കും പാക്കേജ് സെർവറിനുമുള്ള 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 ബാക്ക്‌എൻഡിന്റെയും പെരുമാറ്റം കണക്കിലെടുക്കുക.
പരിശോധന പ്രവർത്തനക്ഷമമായി നിലനിർത്തുക. ഉദ്ദേശിച്ച സേവനത്തെ വെറുതെ തുടരുന്ന കൈമാറ്റത്തിൽനിന്ന് വേർതിരിക്കാനുള്ള തിരിച്ചറിയൽ പരിശോധന അത് നൽകുന്നു.