Gits HTTPS-proxy kan kreve sitt eget klientsertifikat

Konfigurer proxyens TLS-CA, klientsertifikat og private nøkkel separat fra repositoriets TLS- og HTTP-innstillinger for innlogging.

Noen HTTPS-videreformidlende proxyer ber om et klientsertifikat under TLS-forbindelsen fra Git til proxyen. Det er en egen autentiseringsutveksling, atskilt fra innloggingen mot repositoriet.

For en kompatibel Git/libcurl TLS-backend som bruker PEM-filer, har den relevante konfigurasjonen denne formen:

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

Bruk de faktiske filene som er levert for proxyens TLS-oppsett. Bruk konfigurasjonen på det tiltenkte Git-nivået; en konfigurasjon på repositorinivå kan holde denne ruten begrenset til den utsjekkingen.

InnstillingRolle
proxySSLCAInfoCA-pakke som brukes til å verifisere HTTPS-proxyen
proxySSLCertKlientsertifikat som presenteres for den proxyen
proxySSLKeyPrivat nøkkel som hører til klientsertifikatet
proxySSLCertPasswordProtectedSlår på Gits passordspørring for beskyttet sertifikat- og nøkkelmateriale for proxyen

https://-proxyadressen er avgjørende for denne TLS-utvekslingen. En vanlig HTTP-proxy som fører CONNECT til et HTTPS-repositorium utfører ikke dermed TLS-klientsertifikatautentisering på sin egen lytter.

Repositoriets sertifikattillit og eventuelt klientsertifikat for repositoriet har sin egen ssl-konfigurasjon. På samme måte er en HTTP-proxyutfordring med Proxy-Authenticate en annen autentiseringsmekanisme.

Kontroller den koblede libcurl-versjonen, TLS-backenden og støttet sertifikatformat når du vedlikeholder dette oppsettet. En sti til et PEM-sertifikat er ikke en portabel erstatning for alle plattformers sertifikatlager-grensesnitt.

Relaterte artikler