fatal: unable to access 'https://git.example.com/team/app.git/': SSL certificate problem: self-signed certificate in certificate chain

URL в сообщении — адрес вашего удалённого репозитория. Сборки на базе OpenSSL 1.1.1 выводят «self signed» без дефиса; libcurl 8.22 выводит «SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19)».

Что это означает

Git-сервер (или что-то перед ним) отправил полную цепочку, которая заканчивается самоподписанным корневым сертификатом, а этого корневого сертификата нет в пакете сертификатов CA, который использует libcurl в git. Если так происходит с публичными хостами вроде github.com, корневой сертификат почти всегда принадлежит прокси с инспекцией TLS в вашей сети, а у собственных серверов — корпоративному CA.

Почему это происходит

• Корпоративный прокси с инспекцией TLS

  часто

  Zscaler, Netskope, Palo Alto, Fortinet и подобные продукты расшифровывают трафик и снова шифруют его, используя собственный корневой сертификат. Windows доверяет ему благодаря групповой политике, а встроенный файл CA в Git for Windows, WSL, Docker и образы CI — нет.

• Собственный Git-сервер отправляет свой частный корневой сертификат

  часто

  Даже если внутренний GitLab или Gitea отдаёт конечный, промежуточный и корневой сертификат компании, корневой сертификат всё равно нужно установить на каждом клиенте.

• Сканирование HTTPS антивирусом

  иногда

  Средства защиты конечных точек с функциями вроде «сканирования HTTPS» или «веб-щита» устанавливают на машину собственный корневой сертификат; в этой цепочке он появляется так же, как корневой сертификат прокси.

Как исправить

1. 1.

   Определите корневой сертификат

   Выведите цепочку для публичного хоста. Если верхний сертификат назван по имени вашей компании или производителя средств защиты, соединение инспектируется, и git должен доверять именно этому корневому сертификату. Если вы его вообще не узнаёте, не доверяйте ему: сначала разберитесь, откуда он взялся.

   openssl s_client -connect github.com:443 -servername github.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'
   # A root named after your company or a security vendor = interception proxy

2. 2.

   Windows: используйте хранилище сертификатов Windows

   Git for Windows с http.sslBackend schannel доверяет всему, чему доверяет Windows, а на управляемых машинах Windows уже доверяет и корневому сертификату прокси.

   # Git for Windows: use the Windows certificate store, which already trusts the proxy root
   git config --global http.sslBackend schannel

3. 3.

   Добавьте корневой сертификат в пакет, который использует git

   http.sslCAInfo заменяет пакет сертификатов по умолчанию, поэтому соберите файл, в котором есть публичные корневые сертификаты и вдобавок корневой сертификат прокси или компании.

   # Linux/macOS/WSL: append the proxy root to a bundle that keeps the public roots
   cat /etc/ssl/certs/ca-certificates.crt corp-proxy-root.pem > ~/.config/git/ca-bundle.pem
   git config --global http.sslCAInfo ~/.config/git/ca-bundle.pem

4. 4.

   Установите корневой сертификат на уровне системы в Linux

   update-ca-certificates добавляет корневой сертификат сразу для git, curl, wget, pip и большинства других инструментов.

   sudo cp corp-proxy-root.pem /usr/local/share/ca-certificates/corp-proxy-root.crt
   sudo update-ca-certificates

5. 5.

   Временная диагностика: отключите проверку для одной команды

   Только чтобы подтвердить диагноз. Если отключить проверку в реальной работе, ваши учётные данные Git и исходный код достанутся любому, кто терминирует соединение.

   # Diagnostic only, for one command
   git -c http.sslVerify=false ls-remote https://git.example.com/team/app.git

← Открыть всю базу ошибок подписей