Jotkin HTTPS-välityspalvelimet pyytävät asiakasvarmennetta TLS-yhteyden aikana Gitistä välityspalvelimelle. Se on erillinen todentamisvaihto tietovarastoon kirjautumisesta.

Yhteensopivalle PEM-tiedostoja käyttävälle Git/libcurl-TLS-taustalle asiaankuuluva asetuskokonaisuus näyttää tältä:

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

Käytä niitä todellisia tiedostoja, jotka on toimitettu välityspalvelimen TLS-järjestelyä varten. Kohdista asetukset aiottuun Git-laajuuteen; tietovarastokohtainen asetus voi rajata tämän reitin vain siihen työkopioon.

AsetusTehtävä
proxySSLCAInfoCA-nippu, jota käytetään HTTPS-välityspalvelimen vahvistamiseen
proxySSLCertKyseiselle välityspalvelimelle esitettävä asiakasvarmenne
proxySSLKeyAsiakasvarmennetta vastaava yksityinen avain
proxySSLCertPasswordProtectedOttaa käyttöön Gitin salasanakyselyn suojatulle välityspalvelimen varmenteelle ja avainaineistolle

https://-muotoinen välityspalvelimen URL on olennaisen tärkeä tälle TLS-vaihdolle. Tavallinen HTTP-välityspalvelin, joka välittää CONNECTin HTTPS-tietovarastoon, ei siten tee TLS-asiakasvarmenteen todentamista omassa kuuntelijassaan.

Tietovaraston varmennekeskeisyys ja mahdollinen tietovaraston asiakasvarmenne ovat omassa ssl-asetuksessaan. Samoin Proxy-Authenticate-pohjainen HTTP-välityspalvelimen haaste on toinen todentamismekanismi.

Tarkista linkitetty libcurl-versio, TLS-taustajärjestelmä ja tuettu varmennemuoto tätä asetusta ylläpidettäessä. Polku PEM-varmenteeseen ei ole siirrettävä korvaaja kunkin alustan varmennevarastorajapinnalle.

Aiheeseen liittyvät artikkelit