Il proxy HTTPS di Git può richiedere un proprio certificato client

Configura la CA TLS del proxy, il certificato client e la chiave privata separatamente dalle impostazioni TLS e di accesso HTTP del repository.

Alcuni proxy HTTPS inoltrano una richiesta di certificato client durante la connessione TLS da Git al proxy. È uno scambio di autenticazione distinto dall’accesso al repository.

Per un backend TLS di Git/libcurl compatibile che usa file PEM, la configurazione in questione ha questa forma:

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

Usa i file effettivi forniti per l’assetto TLS del proxy. Applica la configurazione nell’ambito Git previsto; una configurazione locale al repository può limitare questo percorso a quella copia di lavoro.

ImpostazioneRuolo
proxySSLCAInfoBundle CA usato per verificare il proxy HTTPS
proxySSLCertCertificato client presentato a quel proxy
proxySSLKeyChiave privata corrispondente al certificato client
proxySSLCertPasswordProtectedAbilita la richiesta della password di Git per il certificato e il materiale di chiave protetti del proxy

L’URL del proxy con https:// è essenziale per questo scambio TLS. Un proxy HTTP semplice che trasporta CONNECT verso un repository HTTPS non esegue per questo l’autenticazione con certificato client TLS sul proprio listener.

La fiducia nei certificati del repository e un eventuale certificato client del repository hanno una propria configurazione ssl. Allo stesso modo, una richiesta di autenticazione del proxy HTTP tramite Proxy-Authenticate è un altro meccanismo.

Controlla la versione di libcurl collegata, il backend TLS e il formato del certificato supportato quando mantieni questa configurazione. Un percorso a un certificato PEM non è un sostituto portabile dell’interfaccia di archivio certificati di ogni piattaforma.

Articoli correlati