Git-ന്റെ HTTPS പ്രോക്സിക്ക് സ്വന്തം ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ആവശ്യമായി വന്നേക്കാം

പ്രോക്സിയുടെ TLS CA, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്, സ്വകാര്യ കീ എന്നിവ റിപ്പോസിറ്ററിയുടെ TLS, HTTP ലോഗിൻ ക്രമീകരണങ്ങളിൽ നിന്ന് വേറിട്ട് ക്രമീകരിക്കുക.

ചില HTTPS ഫോർവേഡ് പ്രോക്സികൾ Git-ൽ നിന്ന് പ്രോക്സിലേക്കുള്ള TLS കണക്ഷനിൽ ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നു. ഇത് റിപ്പോസിറ്ററിയിലേക്ക് ലോഗിൻ ചെയ്യുന്നതിൽ നിന്ന് വേറിട്ട ഒരു പ്രാമാണീകരണ കൈമാറ്റമാണ്.

PEM ഫയലുകൾ ഉപയോഗിക്കുന്ന അനുയോജ്യമായ Git/libcurl TLS ബാക്ക്എൻഡിന്, ബന്ധപ്പെട്ട കോൺഫിഗറേഷൻ ഇങ്ങനെയിരിക്കും:

[http]
    proxy = https://proxy.example:8443
    proxySSLCAInfo = /secure/proxy-ca.pem
    proxySSLCert = /secure/proxy-client.pem
    proxySSLKey = /secure/proxy-client.key
    proxySSLCertPasswordProtected = true

പ്രോക്സിന്റെ TLS ക്രമീകരണത്തിനായി നൽകിയ യഥാർത്ഥ ഫയലുകൾ ഉപയോഗിക്കുക. ഉദ്ദേശിച്ച Git പരിധിയിൽ കോൺഫിഗറേഷൻ പ്രയോഗിക്കുക; റിപ്പോസിറ്ററി-തല കോൺഫിഗറേഷൻ ഈ റൂട്ട് ആ ചെക്കൗട്ടിൽ മാത്രമായി പരിമിതപ്പെടുത്താം.

ക്രമീകരണംപങ്ക്
proxySSLCAInfoHTTPS പ്രോക്സി പരിശോധിക്കാൻ ഉപയോഗിക്കുന്ന CA ബണ്ടിൽ
proxySSLCertആ പ്രോക്സിക്ക് നൽകുന്ന ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്
proxySSLKeyക്ലയന്റ് സർട്ടിഫിക്കറ്റുമായി യോജിക്കുന്ന സ്വകാര്യ കീ
proxySSLCertPasswordProtectedസംരക്ഷിത പ്രോക്സി സർട്ടിഫിക്കറ്റ്, കീ എന്നിവയ്ക്കായി Git-ന്റെ പാസ്‌വേഡ് പ്രോംപ്റ്റ് പ്രവർത്തനക്ഷമമാക്കുന്നു

ഈ TLS കൈമാറ്റത്തിന് https:// പ്രോക്സി URL അനിവാര്യമാണ്. HTTPS റിപ്പോസിറ്ററിയിലേക്ക് CONNECT കൊണ്ടുപോകുന്ന സാധാരണ HTTP പ്രോക്സി അതിലൂടെ സ്വന്തം ലിസണറിൽ TLS ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണം നടത്തുന്നില്ല.

റിപ്പോസിറ്ററിയുടെ സർട്ടിഫിക്കറ്റ് വിശ്വാസവും ഏതെങ്കിലും റിപ്പോസിറ്ററി ക്ലയന്റ് സർട്ടിഫിക്കറ്റും സ്വന്തം ssl കോൺഫിഗറേഷൻ ഉള്ളവയാണ്. അതുപോലെ, Proxy-Authenticate ഉപയോഗിക്കുന്ന HTTP പ്രോക്സി ചലഞ്ച് മറ്റൊരു പ്രാമാണീകരണ സംവിധാനമാണ്.

ഈ ക്രമീകരണം പരിപാലിക്കുമ്പോൾ ബന്ധിപ്പിച്ച libcurl പതിപ്പ്, TLS ബാക്ക്എൻഡ്, പിന്തുണയ്ക്കുന്ന സർട്ടിഫിക്കറ്റ് ഫോർമാറ്റ് എന്നിവ പരിശോധിക്കുക. PEM സർട്ടിഫിക്കറ്റിലേക്കുള്ള ഒരു പാത എല്ലാ പ്ലാറ്റ്ഫോം സർട്ടിഫിക്കറ്റ് സ്റ്റോർ ഇന്റർഫേസുകൾക്കും കൈമാറാവുന്ന പകരമല്ല.

അനുബന്ധ ലേഖനങ്ങൾ