Gits HTTPS-proxy kan kräva sitt eget klientcertifikat

Konfigurera proxyns TLS-CA, klientcertifikat och privata nyckel separat från repots TLS- och HTTP-inloggningsinställningar.

Vissa HTTPS-vidarebefordrande proxyservrar begär ett klientcertifikat under TLS-anslutningen från Git till proxyn. Det är ett separat autentiseringsutbyte, skilt från inloggningen mot repot.

För en kompatibel Git/libcurl TLS-backend som använder PEM-filer ser den relevanta konfigurationen ut så här:

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

Använd de faktiska filerna som tillhandahålls för proxyns TLS-upplägg. Använd konfigurationen på avsedd Git-nivå; en konfiguration på reponivå kan hålla denna väg begränsad till den utcheckningen.

InställningRoll
proxySSLCAInfoCA-paket som används för att verifiera HTTPS-proxyn
proxySSLCertKlientcertifikat som presenteras för den proxyn
proxySSLKeyPrivat nyckel som matchar klientcertifikatet
proxySSLCertPasswordProtectedAktiverar Gits lösenordsfråga för skyddat certifikat- och nyckelmaterial för proxyn

Proxy-URL:en med https:// är avgörande för detta TLS-utbyte. En vanlig HTTP-proxy som för CONNECT till ett HTTPS-repo utför inte därmed TLS-klientcertifikatautentisering på sin egen lyssnare.

Repots certifikattillit och eventuellt klientcertifikat för repot har sin egen ssl-konfiguration. På samma sätt är en HTTP-proxyutmaning med Proxy-Authenticate en annan autentiseringsmekanism.

Kontrollera den länkade libcurl-versionen, TLS-backenden och det certifikatformat som stöds när du underhåller denna uppsättning. En sökväg till ett PEM-certifikat är ingen flyttbar ersättning för alla plattformars certifikatlagringsgränssnitt.

Relaterade artiklar