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

Схожі статті