አንዳንድ የ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 ደረጃ ላይ ይተግብሩ፤ በማከማቻ ደረጃ የሚደረግ ውቅር ይህን መንገድ በዚያ የሥራ ቅጂ ላይ ብቻ ይወስነዋል።

ቅንብርሚና
proxySSLCAInfoየHTTPS ፕሮክሲውን ለማረጋገጥ የሚያገለግል የCA ጥቅል
proxySSLCertለዚያ ፕሮክሲ የሚቀርብ የደንበኛ ሰርተፊኬት
proxySSLKeyከደንበኛ ሰርተፊኬቱ ጋር የሚዛመድ የግል ቁልፍ
proxySSLCertPasswordProtectedለተጠበቀ የፕሮክሲ ሰርተፊኬትና ቁልፍ ቁሳቁስ የGit የይለፍ ቃል ጥያቄን ያስችላል

የhttps:// ፕሮክሲ URL ለዚህ የTLS ልውውጥ አስፈላጊ ነው። ወደ HTTPS ማከማቻ CONNECT የሚያስተላልፍ ተራ የHTTP ፕሮክሲ በዚህ ምክንያት በራሱ ማዳመጫ ላይ የTLS የደንበኛ ሰርተፊኬት ማረጋገጫ አያደርግም።

የማከማቻው የሰርተፊኬት እምነትና ማንኛውም የማከማቻ ደንበኛ ሰርተፊኬት የራሳቸው ssl ውቅር አላቸው። እንደዚሁም Proxy-Authenticate የሚጠቀም የHTTP ፕሮክሲ ፈተና ሌላ የማረጋገጫ ዘዴ ነው።

ይህን አቀራረብ በሚጠብቁበት ጊዜ የተገናኘውን libcurl ቅጂ፣ የTLS የኋላ ክፍልና የሚደገፈውን የሰርተፊኬት ቅርጸት ይመልከቱ። ወደ PEM ሰርተፊኬት የሚወስድ መንገድ ለሁሉም የመድረክ የሰርተፊኬት መጋዘን በይነገጽ ተጓዳኝ ምትክ አይደለም።

ተዛማጅ ጽሑፎች