Git’s HTTPS Proxy Can Require Its Own Client Certificate

Configure the proxy’s TLS CA, client certificate and private key separately from the repository’s TLS and HTTP login settings.

Some HTTPS forward proxies request a client certificate during the TLS connection from Git to the proxy. That is a separate authentication exchange from logging in to the repository.

For a compatible Git/libcurl TLS backend using PEM files, the relevant configuration has this shape:

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

Use the actual files supplied for the proxy’s TLS arrangement. Apply the configuration at the intended Git scope; a repository-local configuration can keep this route limited to that checkout.

SettingRole
proxySSLCAInfoCA bundle used to verify the HTTPS proxy
proxySSLCertClient certificate presented to that proxy
proxySSLKeyPrivate key matching the client certificate
proxySSLCertPasswordProtectedEnables Git’s password prompt for protected proxy certificate/key material

The https:// proxy URL is essential to this TLS exchange. A plain HTTP proxy carrying CONNECT to an HTTPS repository does not thereby perform TLS client-certificate authentication on its own listener.

The repository’s certificate trust and any repository client certificate have their own ssl configuration. Likewise, an HTTP proxy challenge using Proxy-Authenticate is another authentication mechanism.

Check the linked libcurl version, TLS backend and supported certificate format when maintaining this setup. A path to a PEM certificate is not a portable substitute for every platform certificate-store interface.

Artiglyn mynjee