git «SSL certificate problem»: как исправить, не отключая проверку

Типичный вывод: «fatal: unable to access 'адрес': SSL certificate problem: unable to get local issuer certificate», «self signed certificate» или «certificate has expired». Начало «fatal: unable to access» лишь говорит, что обращение по сети не удалось, а причина записана после слов про сертификат. Читайте именно её.

Git при работе по HTTPS использует библиотеку проверки сертификатов и свой набор корней. На Windows он может использовать либо встроенный набор, либо хранилище системы, в зависимости от настройки при установке, и это часто объясняет, почему браузер справляется, а git нет.

Первая: рабочая сеть или антивирус подменяют сертификат своим, о котором git не знает. Вторая: git использует устаревший набор корней, тогда помогает обновление самой программы. Третья: внутренний сервер репозиториев (в компании или домашний) с самоподписанным сертификатом или сертификатом собственного центра.

Четвёртая: неверные дата и время. Пятая: сервер действительно отдаёт просроченный сертификат или неполную цепочку. Шестая, менее очевидная: прокси, заданный в настройках git или переменных окружения, через который проходит трафик к другому сертификату.

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

Проверьте настройки git командой, которая выводит конфигурацию, и поищите записи о прокси, путях к файлам сертификатов и параметр отключения проверки. Часто кто-то когда-то добавил его или, наоборот, указал путь к файлу, которого больше нет.

Затем сравните с другой сетью. Если в мобильной сети клонирование проходит, сертификат подкладывается в вашей сети. Обновите git до свежей версии: старые сборки нередко не знают современных корней.

Проверяйте именно тот адрес, который использует репозиторий: у проекта могут быть отдельные адреса для клонирования и для подмодулей, и сертификат может подводить только на одном из них. Просмотрите файл настроек подмодулей и удалённые адреса командой вывода списка удалённых репозиториев.

Для перехвата в организации получите у администратора корневой сертификат и укажите git файл с ним в настройке, отвечающей за путь к центру сертификации, для конкретного хоста либо целиком. После этого проверка сохраняется.

Для внутреннего сервера сделайте то же самое с корнем вашего внутреннего центра. На Windows можно переключить git на использование хранилища системы, если корень уже добавлен туда администратором.

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

Просроченный сертификат или обрыв цепочки у самого хостинга репозиториев видны всем пользователям и сопровождаются такими же ошибками в браузере. Тут остаётся подождать исправления или сообщить владельцу сервера. Работать через SSH-адрес репозитория можно как временный вариант, если вы настроили ключи: там проверка устроена иначе.

Отдельно проверьте, не задана ли переменная окружения с путём к файлу сертификатов от старого проекта. Она переопределяет настройки git для всех репозиториев и тихо ломает соединение, если файл устарел или удалён.

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

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