Як виправити помилку SSL-сертифіката: не вдалося отримати локальний сертифікат емітента в Git

У 2026 році немає жодних значущих змін, які б робили старий обхідний шлях «вимкнути перевірку SSL» хорошим рішенням. Поточна документація Git досі встановлює значення за замовчуванням для http.sslVerify як true, а Git продовжує підтримувати як файлову довіру до ЦС, так і вибір TLS-бекендів, таких як OpenSSL та Schannel. Надійне виправлення полягає в тому, щоб змусити Git довіряти правильному центру сертифікації або виправити неповний ланцюжок сертифікатів сервера, а не вимикати перевірку.

Помилка SSL certificate problem: unable to get local issuer certificate означає, що TLS-бібліотека, яку використовує Git, не змогла побудувати довірений ланцюжок сертифікатів від сертифіката сервера до центру сертифікації, якому вона довіряє. Це може статися через те, що в локальному сховищі ЦС відсутній емітуючий ЦС, корпоративний проксі HTTPS-інспекції повторно підписує трафік внутрішнім ЦС, Git читає неправильний пакет ЦС або самостійно керований сервер Git не надає необхідні проміжні сертифікати.

Типовий збій Git HTTPS: віддалений сервер доступний, але перевірка ланцюжка сертифікатів не може знайти довіреного емітента.

Почніть з найбезпечнішого рішення

Дотримуйтесь такого порядку:

1. Перевірте, які налаштування SSL Git та TLS-бекенд активні.
2. Визначте, чи належить відсутня довіра до сховища довіри операційної системи, чи до пакета ЦС Git.
3. Якщо багато клієнтів не можуть підключитися до одного й того ж самостійно розміщеного сервера, виправте ланцюжок сертифікатів сервера замість патчингу кожного клієнта.
4. Повторно протестуйте з увімкненою перевіркою SSL і видаліть будь-які тимчасові або застарілі налаштування обходу.

Поточна документація git-config Git визначає http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend та специфічну для Schannel поведінку, що використовується у Windows. За замовчуванням перевірка сертифікатів залишається увімкненою.

Надійне виправлення полягає у відновленні дійсного ланцюжка довіри, а не в придушенні перевірки сертифіката.

Крок 1: з’ясуйте, що саме використовує Git

Перш ніж встановлювати сертифікати або редагувати конфігурацію, перевірте значення та їх джерела:

git --version
git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslCAInfo
git config --show-origin --get http.sslBackend
git config --show-origin --get http.proxy
git config --show-origin --get http.proxySSLCAInfo

Якщо команда нічого не виводить, цей параметр може просто використовувати значення за замовчуванням Git або libcurl. Прапорець --show-origin важливий, оскільки значення може надходити з системних, глобальних, локальних репозиторних або включених конфігураційних файлів. Виправлення неправильного рівня може залишити ефективне налаштування незмінним.

Також перевірте віддалений сервер, з яким ви фактично зв’язуєтеся:

git remote -v
git ls-remote https://git.example.com/team/repo.git

Якщо Git не працює лише для одного корпоративного або приватного хоста, тоді як публічні HTTPS-сайти працюють, проблема, ймовірно, пов’язана з довірою до конкретного хоста або конфігурацією сервера. Якщо Git не працює для багатьох не пов’язаних між собою HTTPS-віддалених серверів, спочатку перевірте локальну інсталяцію Git, шлях до пакета ЦС, проксі та конфігурацію довіри системи.

Не робіть це вашою першою командою

git config --global http.sslVerify false

Це вимикає перевірку сертифікатів сервера для запитів Git HTTPS на глобальному рівні користувача. Це може усунути помилку, але також видалить захист, який перевіряє, чи спілкуєтеся ви з потрібним сервером. Git документує, що перевірка увімкнена за замовчуванням не просто так.

Якщо ви виявите старий глобальний обхід, який більше не потрібен, відновіть поведінку за замовчуванням:

git config --global --unset http.sslVerify

або явно встановіть:

git config --global http.sslVerify true

Крок 2: у Windows оберіть між сховищем сертифікатів Windows та пакетом ЦС PEM

Розробники на Windows часто стикаються з цією помилкою, коли браузер працює, а Git — ні. Це не обов’язково означає, що сервер зламаний. Браузер може довіряти корпоративному кореневому сертифікату, встановленому в Windows, тоді як Git, налаштований з бекендом стилю OpenSSL, може використовувати окремий пакет ЦС.

Git підтримує значення http.sslBackend, такі як openssl та schannel. Офіційна документація TLS-сертифікатів curl пояснює, що Schannel за замовчуванням використовує нативне сховище ЦС Windows.

Варіант A: використовуйте Schannel, якщо Windows вже має довірений корпоративний ЦС

git config --global http.sslBackend schannel

Це часто є хорошим рішенням для робочих станцій лише під Windows, керованих організацією, яка розповсюджує довірені кореневі та проміжні сертифікати через політику Windows. Це дозволяє Git покладатися на ту саму систему довіри до сертифікатів Windows, яку можуть використовувати інші нативні додатки.

Існує компроміс: зміна бекенда змінює поведінку Git HTTPS щодо сертифікатів глобально для цього користувача. Якщо ваша організація навмисно керує виділеним пакетом PEM для Git або автоматизації, залишення на OpenSSL може бути більш передбачуваним.

Поточна документація Git також зазначає тонку поведінку Schannel: коли Schannel обрано через http.sslBackend, Git зазвичай уникає застосування http.sslCAInfo, оскільки наданий пакет ЦС може перевизначити Сховище сертифікатів Windows. Налаштування http.schannelUseSSLCAInfo існує для середовищ, які навмисно хочуть такої поведінки.

Варіант B: залиште OpenSSL і вкажіть Git на затверджений пакет ЦС

Якщо ваша організація надає вам пакет PEM, що містить необхідні внутрішні кореневі та проміжні сертифікати, налаштуйте Git на використання цього файлу:

git config --global http.sslCAInfo "C:/certs/company-ca-bundle.pem"

Git визначає http.sslCAInfo як файл, що містить сертифікати, які використовуються для перевірки однорангового вузла. Ви також можете обмежити налаштування HTTP відповідним URL-адресам замість зміни всіх HTTPS-призначень. Конфігурація Git http.<url>.* підтримує зіставлення за схемою, хостом, портом і шляхом.

Наприклад:

git config --global http."https://git.example.com/".sslCAInfo "C:/certs/company-ca-bundle.pem"

Це вужче налаштування корисне, коли лише внутрішній сервер Git потребує приватного ЦС, тоді як публічні хости Git повинні продовжувати використовувати звичайний пакет довіри.

Крок 3: на macOS, Linux, CI та в контейнерах виправте джерело ЦС, яке фактично використовує процес

Принцип поза Windows той самий: процес Git повинен мати доступ до сертифіката ЦС, який видав сертифікат сервера або проксі. Точні команди системного сховища довіри відрізняються залежно від операційної системи та дистрибутива Linux, тому використовуйте офіційний механізм керування сертифікатами платформи або явний пакет ЦС Git, наданий вашим адміністратором.

Git повинен мати можливість пов’язати представлений сертифікат сервера через його проміжних емітентів з локально довіреним ЦС.

Для контрольованого завдання CI або контейнера, де ви не хочете змінювати глобальне сховище довіри хоста, пакет ЦС може бути явним:

git config --global http.sslCAInfo /etc/company/git-ca-bundle.pem

або, для окремого процесу, Git також розпізнає змінну середовища GIT_SSL_CAINFO. Поточна документація Git стверджує, що ця змінна середовища може перевизначати http.sslCAInfo.

Не копіюйте випадковий файл cacert.pem з форуму. Якщо відсутній сертифікат є корпоративним ЦС, отримайте його від вашої IT-або PKI-команди. Якщо віддалений сервер є публічною службою, а ваш пакет ЦС просто застарів, оновіть операційну систему, дистрибутив Git, базовий образ контейнера або пакет довірених ЦС через звичайний канал оновлення.

Корпоративна інспекція TLS є особливим випадком

Деякі корпоративні проксі інспектують HTTPS і представляють замінний сертифікат, підписаний внутрішнім корпоративним ЦС. У такій ситуації браузер може працювати успішно, оскільки корпоративний ЦС встановлено в сховищі довіри ОС, тоді як окремий пакет ЦС Git не містить його.

Правильне виправлення — довіряти ЦС організації через відповідне сховище довіри або пакет Git. Не експортуйте поточний листовий сертифікат і не довіряйте йому назавжди як заміні емітуючого корпоративного ЦС.

Також розрізняйте два окремих випадки проксі:

• Перехоплення TLS з’єднання з сервером Git: корпоративний ЦС, який підписує замінний сертифікат сервера, повинен бути довіреним через звичайний шлях сертифіката сервера, такий як Windows Schannel або http.sslCAInfo.
• Проксі HTTPS, власне з’єднання якого використовує TLS: Git надає http.proxySSLCAInfo спеціально для пакета ЦС, який використовується для перевірки цього з’єднання з проксі HTTPS.

Git документує http.proxy та http.proxySSLCAInfo окремо, тому використовуйте налаштування, яке відповідає з’єднанню, що не працює.

Крок 4: якщо ланцюжок сервера неповний, виправте сервер, коли можете

Якщо багато користувачів або нових машин не можуть підключитися до одного й того ж самостійно розміщеного сервера Git, проблема може бути на стороні сервера, а не в наборі зламаних клієнтів. Сервер повинен представляти ланцюжок сертифікатів, необхідну клієнтам для зв’язку листового сертифіката з довіреним емітентом.

Коли багато клієнтів не працюють з одним приватним хостом Git, перевірте ланцюжок сервера та шлях проксі перед розповсюдженням обхідних шляхів на стороні клієнта.

Офіційна документація GitLab з усунення несправностей SSL спеціально описує unable to get local issuer certificate як випадок, коли клієнт не може отримати необхідного емітента, і рекомендує або довіряти відповідному ЦС на клієнті, або виправити сервер для представлення повного ланцюжка сертифікатів.

Якщо ви адмініструєте сервер, виправте налаштований повноланцюговий сертифікат і повторно протестуйте з чистого клієнта. Це краще, ніж просити кожного розробника додавати ад-хок винятки.

Перевірте виправлення без ослаблення TLS

Після виправлення конфігурації довіри повторіть ту саму операцію Git:

git ls-remote https://git.example.com/team/repo.git

Якщо це вдасться, повторіть спробу оригінальної операції clone, fetch, pull або push.

Потім перевірте остаточну конфігурацію, пов’язану з безпекою:

git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslBackend
git config --show-origin --get http.sslCAInfo

Очікуваний стан полягає в тому, що перевірка сертифікатів залишається увімкненою, і Git може побудувати дійсний ланцюжок через призначене джерело довіри.

Яке виправлення відповідає вашій ситуації?

Щодо переходу віддаленого сервера Git на SSH?

SSH може бути дійсною альтернативою транспорту, якщо ваш хостинг Git підтримує це і ваша організація дозволяє це. Зміна з HTTPS-віддаленого сервера на SSH-віддалений сервер повністю уникає ланцюжка сертифікатів HTTPS, але не виправляє початкову проблему довіри TLS. SSH має власну модель перевірки ключів хоста та керування обліковими даними.

Використовуйте SSH, тому що він відповідає вашому дизайну автентифікації та розгортання, а не просто щоб приховати помилку конфігурації сертифікатів, з якою інші інструменти HTTPS продовжуватимуть стикатися.

Поширені помилки, яких слід уникати

• Вимкнення перевірки SSL глобально. Це видаляє перевірку сертифікатів сервера для майбутніх з’єднань Git HTTPS.
• Довіра до листового сертифіката замість емітуючого ЦС. Листові сертифікати закінчуються та ротаються; довіра зазвичай повинна бути закріплена в затвердженому ланцюжку ЦС.
• Ручне редагування пакетного файлу ЦС Git без документування. Оновлення може замінити файл, і зміна може бути неможливою для відтворення командою або CI.
• Припущення, що успіх браузера доводить, що Git має те саме джерело довіри. Git може використовувати OpenSSL і окремий пакет PEM, тоді як браузер використовує сховище ОС.
• Використання http.proxySSLCAInfo для неправильного з’єднання. Це налаштування призначене для перевірки проксі HTTPS, а не для загальної заміни конфігурації ЦС сервера походження.
• Патчинг кожної робочої станції розробника, коли сервер Git надсилає неповний ланцюжок. Виправте сервер, коли ви ним керуєте.

Підсумок

Помилка Git SSL certificate problem: unable to get local issuer certificate є проблемою ланцюжка довіри, а не проблемою токена автентифікації, і її зазвичай не слід вирішувати вимкненням перевірки сертифікатів. З’ясуйте, чи використовує Git OpenSSL, Schannel, власний пакет ЦС або проксі HTTPS; потім розмістіть затверджений емітуючий ЦС у джерелі довіри, яке фактично використовує Git.

У Windows Schannel є практичним варіантом, коли корпоративний ЦС вже керується в Сховищі сертифікатів Windows. У CI, контейнерах або середовищах, які потребують відтворюваної файлової довіри, http.sslCAInfo часто є більш зрозумілим. А коли кілька клієнтів не працюють з одним самостійно розміщеним сервісом, виправте ланцюжок сертифікатів сервера замість розповсюдження небезпечних обхідних шляхів.