HTTPS проксито на Git може да бара сопствен клиентски сертификат

Конфигурирајте TLS CA на проксито, клиентскиот сертификат и приватниот клуч одделно од TLS и HTTP нагодувањата за најава на складиштето.

Некои 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 опсег; конфигурацијата на ниво на складиште може да ја ограничи оваа патека на тоа работно копие.

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

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

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

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

Поврзани статии