HTTPS-праксі Git можа патрабаваць уласны кліенцкі сертыфікат

Наладзьце TLS CA праксі, кліенцкі сертыфікат і прыватны ключ асобна ад TLS і HTTP-наладак уваходу ў рэпазіторый.

Некаторыя праксі HTTPS запытваюць кліенцкі сертыфікат падчас TLS-злучэння ад Git да праксі. Гэта асобны абмен аўтэнтыфікацыі, не звязаны з уваходам у рэпазіторый.

Для сумяшчальнага TLS-бэкенда Git/libcurl, які выкарыстоўвае 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; канфігурацыя на ўзроўні рэпазіторыя можа абмежаваць гэты шлях толькі тым працоўным каталогам.

ПараметрРоля
proxySSLCAInfoНабор CA для праверкі праксі HTTPS
proxySSLCertКліенцкі сертыфікат, які прад'яўляецца гэтаму праксі
proxySSLKeyПрыватны ключ, што адпавядае кліенцкаму сертыфікату
proxySSLCertPasswordProtectedУключае запыт пароля Git для абароненага сертыфіката і ключа праксі

URL праксі з https:// мае вырашальнае значэнне для гэтага TLS-абмену. Звычайнае HTTP-проксі, якое перадае CONNECT да рэпазіторыя HTTPS, не выконвае тым самым аўтэнтыфікацыю кліенцкага сертыфіката TLS на ўласным слухачы.

Давер да сертыфікатаў рэпазіторыя і любы кліенцкі сертыфікат рэпазіторыя маюць уласную канфігурацыю ssl. Гэтак жа выклік HTTP-проксі з Proxy-Authenticate — іншы механізм аўтэнтыфікацыі.

Правярайце звязаную версію libcurl, TLS-бэкенд і падтрымоўваны фармат сертыфіката пры падтрымцы такой наладкі. Шлях да PEM-сертыфіката не з'яўляецца пераноснай заменай для інтэрфейсу сховішча сертыфікатаў кожнай платформы.

Падобныя артыкулы