fatal: unable to access 'https://git.example.com/team/app.git/': server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)

URL в сообщении — адрес вашего удалённого репозитория. Старые выпуски Debian и Ubuntu (libcurl 7.x) выводят более короткое «server certificate verification failed. CAfile: none CRLfile: none», где «CAfile: none» означает лишь, что файл CA явно не задан и использовался системный пакет сертификатов.

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

HTTPS-транспорт git (libcurl, собранная с GnuTLS в Debian и Ubuntu) не смог проверить сертификат Git-сервера: ни один сертификат цепочки не ведёт к CA из пакета сертификатов, который он читает. «certificate signer not trusted» — так GnuTLS сообщает, что издатель неизвестен; ваши учётные данные и репозиторий ещё не проверялись.

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

• Собственный GitLab, Gitea или Bitbucket с корпоративным сертификатом

  часто

  Собственные Git-серверы часто получают сертификаты от внутреннего CA. На ноутбуках разработчиков этот корневой сертификат есть благодаря системе управления устройствами, а в Linux-контейнерах, CI-раннерах и дистрибутивах WSL его обычно нет.

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

  часто

  GitLab, Gitea и обратные прокси перед ними часто настроены так, что отдают только конечный сертификат. Браузеры восполняют пробел, а GnuTLS — нет.

• Между вами и Git-хостом стоит прокси с инспекцией TLS

  иногда

  Если клонирование с github.com или gitlab.com не проходит только в корпоративной сети, соединения переподписывает прокси, чьего корневого сертификата нет в пакете сертификатов машины.

• В образе нет пакета сертификатов CA

  иногда

  Облегчённый образ с установленным git, но без ca-certificates не может работать ни с одним удалённым репозиторием по HTTPS.

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

1. 1.

   Посмотрите, какие сертификаты отправляет Git-сервер

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

   openssl s_client -connect git.example.com:443 -servername git.example.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'

2. 2.

   Добавьте доверие к CA только для одного Git-сервера

   http.<url>.sslCAInfo ограничивает действие собственного CA одним хостом, так что публичные удалённые репозитории по-прежнему используют системный пакет сертификатов. GIT_SSL_CAINFO делает то же самое для одной команды или одного задания CI.

   # Trust the company CA for this server only; other remotes keep the system bundle
   git config --global http."https://git.example.com/".sslCAInfo /etc/ssl/private-ca/corp-root-ca.pem
   git ls-remote https://git.example.com/team/app.git

3. 3.

   Добавьте корневой сертификат в системный пакет сертификатов

   Установка корневого сертификата через update-ca-certificates за один шаг исправляет git, curl, wget и менеджеры пакетов. В образах Docker делайте это в Dockerfile, в CI — в образе раннера.

   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
   sudo update-ca-certificates     # git, curl and wget read /etc/ssl/certs/ca-certificates.crt

4. 4.

   Владельцам серверов: настройте полную цепочку

   Файл сертификата, который использует веб-фронтенд Git-сервера, должен содержать конечный сертификат, а за ним все промежуточные.

   # GitLab Omnibus (/etc/gitlab/gitlab.rb): the .crt file must contain leaf + intermediates
   nginx['ssl_certificate'] = "/etc/gitlab/ssl/git.example.com.crt"
   # then: sudo gitlab-ctl reconfigure

5. 5.

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

   -c http.sslVerify=false для одной команды подтверждает, что проблема только в доверии. Если задать этот параметр глобально, ваши учётные данные и код получит любой, кто может перехватить соединение.

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

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