Неки HTTPS проксији за прослеђивање траже клијентски сертификат током TLS везе од Git-а до проксија. То је одвојена размена аутентификације од пријаве на репозиторијум.

За компатибилан Git/libcurl TLS бекенд који користи PEM датотеке, одговарајућа конфигурација изгледа овако:

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

Користите стварне датотеке испоручене за TLS поставку проксија. Примените конфигурацију у жељеном Git обиму; конфигурација на нивоу репозиторијума може да ограничи ову путању на тај checkout.

ПодешавањеУлога
proxySSLCAInfoCA пакет који се користи за верификацију HTTPS проксија
proxySSLCertКлијентски сертификат који се представља том проксију
proxySSLKeyПриватни кључ који одговара клијентском сертификату
proxySSLCertPasswordProtectedОмогућава Git-ов упит за лозинку за заштићени материјал сертификата и кључа проксија

https:// URL проксија је кључан за ову TLS размену. Обичан HTTP прокси који преноси CONNECT до HTTPS репозиторијума тиме не обавља TLS аутентификацију клијентским сертификатом на сопственом слушаоцу.

Поверење у сертификате репозиторијума и евентуални клијентски сертификат репозиторијума имају сопствену ssl конфигурацију. Исто тако, HTTP прокси изазов са Proxy-Authenticate је други механизам аутентификације.

Када одржавате ово подешавање, проверите повезану верзију libcurl-а, TLS бекенд и подржани формат сертификата. Путања до PEM сертификата није преносива замена за сваки интерфејс платформског складишта сертификата.

Повезани чланци