Proksi ya HTTPS ya Git inaweza kuhitaji cheti chake cha mteja

Sanidi CA ya TLS ya proksi, cheti cha mteja na ufunguo wa faragha kando na mipangilio ya TLS na kuingia kwa HTTP ya hazina.

Baadhi ya proksi za HTTPS zinazopeleka maombi huomba cheti cha mteja wakati wa muunganisho wa TLS kutoka Git hadi proksi. Hiyo ni mabadilishano ya uthibitishaji tofauti na kuingia kwenye hazina.

Kwa backend ya TLS ya Git/libcurl inayooana na inayotumia faili za PEM, usanidi husika una umbo hili:

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

Tumia faili halisi zilizotolewa kwa mpangilio wa TLS wa proksi. Tumia usanidi katika wigo wa Git uliokusudiwa; usanidi wa ngazi ya hazina inaweza kuweka njia hii ndani ya checkout hiyo pekee.

MpangilioJukumu
proxySSLCAInfoKifurushi cha CA kinachotumika kuthibitisha proksi ya HTTPS
proxySSLCertCheti cha mteja kinachowasilishwa kwa proksi hiyo
proxySSLKeyUfunguo wa faragha unaoendana na cheti cha mteja
proxySSLCertPasswordProtectedHuwezesha kidokezo cha neno la siri la Git kwa nyenzo za cheti na ufunguo wa proksi zilizolindwa

URL ya proksi ya https:// ni muhimu kwa mabadilishano haya ya TLS. Proksi ya kawaida ya HTTP inayobeba CONNECT hadi hazina ya HTTPS haifanyi kwa hivyo uthibitishaji wa cheti cha mteja wa TLS kwenye kisikilizaji chake yenyewe.

Uaminifu wa vyeti vya hazina na cheti chochote cha mteja cha hazina vina usanidi wao wa ssl. Vivyo hivyo, changamoto ya proksi ya HTTP inayotumia Proxy-Authenticate ni utaratibu mwingine wa uthibitishaji.

Unapohudumia mpangilio huu, angalia toleo la libcurl lililounganishwa, backend ya TLS na umbo la cheti linalotumika. Njia ya kuelekea cheti cha PEM si mbadala unaoweza kuhamishwa kwa kila kiolesura cha hifadhi ya vyeti cha jukwaa.

Makala zinazohusiana