Git se HTTPS-proxy kan sy eie kliëntsertifikaat vereis

Stel die proxy se TLS-CA, kliëntsertifikaat en private sleutel afsonderlik van die pakhuis se TLS- en HTTP-aanmeldingsinstellings op.

Sommige HTTPS-proxy's vra 'n kliëntsertifikaat tydens die TLS-verbinding van Git na die proxy. Dit is 'n aparte verifikasiestap van die aanmelding by die pakhuis.

Vir 'n versoenbare Git/libcurl TLS-agterkant wat PEM-lêers gebruik, lyk die betrokke konfigurasie so:

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

Gebruik die werklike lêers wat vir die proxy se TLS-opset voorsien is. Pas die konfigurasie op die beoogde Git-vlak toe; 'n pakhuis-plaaslike konfigurasie kan hierdie roete tot daardie kloon beperk.

InstellingRol
proxySSLCAInfoCA-bundel wat gebruik word om die HTTPS-proxy te verifieer
proxySSLCertKliëntsertifikaat wat aan daardie proxy voorgelê word
proxySSLKeyPrivate sleutel wat by die kliëntsertifikaat pas
proxySSLCertPasswordProtectedAktiveer Git se wagwoordvraag vir beskermde proxy-sertifikaat- en sleutelmateriaal

Die https:// proxy-URL is noodsaaklik vir hierdie TLS-uitruiling. 'n Gewone HTTP-proxy wat CONNECT na 'n HTTPS-pakhuis dra, voer nie daarmee TLS-kliëntsertifikaatverifikasie op sy eie luisteraar uit nie.

Die pakhuis se sertifikaatvertroue en enige pakhuis-kliëntsertifikaat het hul eie ssl-konfigurasie. Net so is 'n HTTP-proxy-uitdaging met Proxy-Authenticate 'n ander verifikasiemeganisme.

Kontroleer die gekoppelde libcurl-weergawe, TLS-agterkant en ondersteunde sertifikaatformaat wanneer hierdie opstelling onderhou word. 'n Pad na 'n PEM-sertifikaat is nie 'n draagbare plaasvervanger vir elke platform se sertifikaatstoorkoppelvlak nie.

Verwante artikels