Enkelte HTTPS-proxyer som videresender trafikk ber om et klientsertifikat i TLS-forbindelsen mellom Git og proxyen. Dette er en egen autentiseringsutveksling, uavhengig av påloggingen til repositoriet.

For en kompatibel Git/libcurl TLS-backend med PEM-filer ser den aktuelle konfigurasjonen slik ut:

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

Bruk filene som faktisk er utlevert for proxyens TLS-oppsett. Sett konfigurasjonen på riktig Git-nivå; en konfigurasjon på repositorinivå kan holde denne ruten begrenset til den arbeidskopien.

InnstillingFunksjon
proxySSLCAInfoCA-pakke som brukes til å verifisere HTTPS-proxyen
proxySSLCertKlientsertifikat som legges frem for proxyen
proxySSLKeyPrivat nøkkel som samsvarer med klientsertifikatet
proxySSLCertPasswordProtectedAktiverer Gits passordforespørsel for beskyttet sertifikat- og nøkkelmateriale for proxyen

https://-adressen til proxyen er nødvendig for denne TLS-utvekslingen. En vanlig HTTP-proxy som sender CONNECT til et HTTPS-repositorium, utfører ikke av den grunn TLS-autentisering med klientsertifikat på sin egen lytter.

Repositoriets sertifikattillit og et eventuelt klientsertifikat for repositoriet har sin egen ssl-konfigurasjon. Tilsvarende er en HTTP-proxyutfordring med Proxy-Authenticate en annen autentiseringsmekanisme.

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

Relaterte artikler