De HTTPS-proxy fan Git kin in eigen kliïntsertifikaat ferlange
Konfigurearje de TLS-CA fan 'e proxy, it kliïntsertifikaat en de priveesleutel apart fan 'e TLS- en HTTP-oanmeldynstellings fan it depot.
Guon HTTPS-proxy's freegje by de TLS-ferbining fan Git nei de proxy om in kliïntsertifikaat. Dat is in aparte autentikaasje-útwikseling fan it oanmelden by it depot.
Foar in kompatibele Git/libcurl TLS-backend dy't PEM-bestannen brûkt, hat de oangeande konfiguraasje dizze foarm:
[http]
proxy = https://proxy.example:8443
proxySSLCAInfo = /secure/proxy-ca.pem
proxySSLCert = /secure/proxy-client.pem
proxySSLKey = /secure/proxy-client.key
proxySSLCertPasswordProtected = trueBrûk de werklike bestannen dy't foar de TLS-opset fan 'e proxy levere binne. Pas de konfiguraasje ta op it bedoelde Git-berik; in depot-lokale konfiguraasje kin dizze rûte beheine ta dy wurkkopy.
| Ynstelling | Rol |
|---|---|
| proxySSLCAInfo | CA-bondel dy't brûkt wurdt om de HTTPS-proxy te ferifiearjen |
| proxySSLCert | Kliïntsertifikaat dat oan dy proxy presintearre wurdt |
| proxySSLKey | Priveesleutel dy't by it kliïntsertifikaat past |
| proxySSLCertPasswordProtected | Skeakelt Git syn wachtwurd-freechjen yn foar beskerme proxy-sertifikaat- en sleutelmateriaal |
De https:// proxy-URL is essinsjeel foar dizze TLS-útwikseling. In gewoane HTTP-proxy dy't CONNECT nei in HTTPS-depot draacht, docht dêrmei gjin TLS-kliïntsertifikaat-autentikaasje op syn eigen listener.
It sertifikaatfertrouwen fan it depot en in mooglik depot-kliïntsertifikaat hawwe har eigen ssl-konfiguraasje. Likegoed is in HTTP-proxy-útdaging mei Proxy-Authenticate in oar autentikaasjemeganisme.
Kontrolearje de keppele libcurl-ferzje, de TLS-backend en it stipe sertifikaatformaat by it ûnderhâlden fan dizze opset. In paad nei in PEM-sertifikaat is gjin draachber ferfanging foar de sertifikaatopslach-ynterface fan elk platfoarm.