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 не является переносимым заменителем любого интерфейса хранилища сертификатов платформы.

Похожие статьи