Няма значима промяна през 2026 г., която да прави старото заобикаляне „изключване на SSL верификацията“ добро решение. Текущата документация на Git все още задава http.sslVerify по подразбиране на true, а Git все още поддържа както CA доверие, базирано на файлове, така и избираеми TLS бекенди като OpenSSL и Schannel. Трайното решение е да накарате Git да се довери на правилния сертификатен орган или да поправите непълна верига от сертификати на сървъра, а не да деактивирате верификацията.
Грешката SSL certificate problem: unable to get local issuer certificate означава, че TLS библиотеката, използвана от Git, не е могла да изгради доверена верига от сертификати от сървърния сертификат до сертификатен орган, на който се доверява. Това може да се случи, защото локалното CA хранилище липсва издаващия CA, корпоративен HTTPS инспекционен прокси пре-подписва трафика с вътрешен CA, Git чете грешния CA пакет или самостоятелно управляван Git сървър не представя необходимите междинни сертификати.
Типичен отказ на Git HTTPS: отдалеченият хост е достъпен, но верификацията на веригата от сертификати не може да намери доверен издател.
Използвайте следния ред:
Текущата документация на git-config дефинира http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend и специфичното за Schannel поведение, използвано в Windows. По подразбиране верификацията на сертификати остава активирана.
Надеждното поправяне е да възстановите валидна верига на доверие, вместо да потискате проверката на сертификата.
Преди да инсталирате сертификати или да редактирате конфигурацията, проверете стойностите и откъде идват те:
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, пътя на CA пакета, проксито и конфигурацията за доверие на системата.
git config --global http.sslVerify falseТова деактивира верификацията на сървърния сертификат за Git HTTPS заявки на глобално потребителско ниво. Може да накара грешката да изчезне, като същевременно премахне защитата, която проверява дали комуникирате с желания сървър. Git документира, че верификацията е активирана по подразбиране с причина.
Ако откриете старо глобално заобикаляне, което вече не е необходимо, възстановете поведението по подразбиране:
git config --global --unset http.sslVerifyили задайте изрично:
git config --global http.sslVerify trueРазработчиците в Windows често срещат тази грешка, когато браузърът работи, но Git не. Това не означава непременно, че сървърът е счупен. Браузърът може да се доверява на корпоративен коренов сертификат, инсталиран в Windows, докато Git, конфигуриран с бекенд от тип OpenSSL, може да използва отделен CA пакет.
Git поддържа стойности за http.sslBackend като openssl и schannel. Официалната документация за TLS сертификати на curl обяснява, че Schannel използва по подразбиране нативното CA хранилище на Windows.
git config --global http.sslBackend schannelТова често е добър избор за работни станции само с Windows, управлявани от организация, която разпространява доверени коренови и междинни сертификати чрез политика на Windows. Това позволява на Git да разчита на същата система за доверие на сертификати на Windows, която други нативни приложения могат да използват.
Има компромис: промяната на бекенда променя поведението на Git за HTTPS сертификати глобално за този потребител. Ако вашата организация умишлено управлява специален PEM пакет за Git или автоматизация, оставането с OpenSSL може да е по-предсказуемо.
Текущата документация на Git също отбелязва фино поведение на Schannel: когато Schannel е избран чрез http.sslBackend, Git обикновено избягва прилагането на http.sslCAInfo, защото предоставеният CA пакет може да замени Хранилището за сертификати на Windows. Настройката http.schannelUseSSLCAInfo съществува за среди, които умишлено искат това поведение.
Ако вашата организация ви предоставя PEM пакет, съдържащ необходимите вътрешни коренови и междинни сертификати, конфигурирайте Git да използва този файл:
git config --global http.sslCAInfo "C:/certs/company-ca-bundle.pem"Git дефинира http.sslCAInfo като файл, съдържащ сертификати, използвани за верификация на пиъра. Можете също да ограничите HTTP конфигурацията до съвпадащ URL, вместо да променяте всяка HTTPS дестинация. Конфигурацията на Git http.<url>.* поддържа съвпадения, специфични за URL, по схема, хост, порт и път.
Например:
git config --global http."https://git.example.com/".sslCAInfo "C:/certs/company-ca-bundle.pem"Тази по-тясна настройка е полезна, когато само вътрешен Git сървър се нуждае от частен CA, докато публичните Git хостове трябва да продължат да използват нормалния пакет за доверие.
Принципът е същият извън Windows: Git процесът трябва да има достъп до CA сертификата, който е издал сървърния или прокси сертификата. Точните команди за системното хранилище за доверие се различават в зависимост от операционната система и Linux дистрибуцията, затова използвайте официалния механизъм за управление на сертификати на платформата или явен Git CA пакет, предоставен от вашия администратор.
Git трябва да може да свърже представения сървърен сертификат чрез неговите междинни издатели до локално доверен CA.
За контролирана CI задача или контейнер, където не искате да модифицирате глобалното хранилище за доверие на хоста, CA пакетът може да бъде явен:
git config --global http.sslCAInfo /etc/company/git-ca-bundle.pemили, за отделен процес, Git също разпознава променливата на средата GIT_SSL_CAINFO. Текущата документация на Git посочва, че тази променлива на средата може да замени http.sslCAInfo.
Не копирайте случаен файл cacert.pem от форум. Ако липсващият сертификат е корпоративен CA, получете го от вашия IT или PKI екип. Ако отдалеченият хост е публична услуга и вашият CA пакет просто е остарял, актуализирайте операционната система, Git дистрибуцията, базовия образ на контейнера или пакета с доверени CA чрез нормалния канал за актуализация.
Някои корпоративни прокси инспектират HTTPS и представят заместителен сертификат, подписан от вътрешен корпоративен CA. В тази ситуация браузърът може да успее, защото корпоративният CA е инсталиран в хранилището за доверие на ОС, докато отделният CA пакет на Git не го съдържа.
Правилното решение е да се доверите на CA на организацията чрез подходящото хранилище за доверие или Git пакет. Не експортирайте текущия листов сертификат и не го доверявайте постоянно като заместител на издаващия корпоративен CA.
Също така разграничете два отделни случая с прокси:
http.sslCAInfo.http.proxySSLCAInfo специално за CA пакета, използван за верификация на тази HTTPS прокси връзка.Git документира http.proxy и http.proxySSLCAInfo поотделно, затова използвайте настройката, която съответства на връзката, която се проваля.
Ако много потребители или нови машини се провалят срещу един и същ самостоятелно хостван Git сървър, проблемът може да е от страна на сървъра, а не колекция от счупени клиенти. Сървърът трябва да представи веригата от сертификати, необходима на клиентите, за да свържат листовия сертификат с доверен издател.
Когато много клиенти се провалят срещу един частен Git хост, проверете веригата на сървъра и пътя на проксито, преди да разпространявате заобикаляния от страна на клиента.
Официалната документация за отстраняване на неизправности със SSL на GitLab конкретно описва unable to get local issuer certificate като случай, в който клиентът не може да получи необходимия издател и препоръчва или да се довери на подходящия CA на клиента, или да се коригира сървърът, за да представи пълна верига от сертификати.
Ако администрирате сървъра, поправете конфигурирания пълен верижен сертификат и тествайте отново от чист клиент. Това е предпочитано пред моленето на всеки разработчик да добавя ad hoc изключения.
След като конфигурацията за доверие е коригирана, повторете същата 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 да може да изгради валидна верига чрез желания източник на доверие.
| Ситуация | Най-добро начало | Защо |
|---|---|---|
| Браузърът в Windows работи; Git се проваля в корпоративна мрежа | Проверете дали корпоративният CA е в хранилището за доверие на Windows; помислете за Schannel | Доверието на браузъра и Windows може вече да е правилно, докато Git OpenSSL използва друг пакет |
| Компанията предоставя PEM CA пакет за инструменти за разработчици | Използвайте http.sslCAInfo, за предпочитане специфичен за хоста, когато е практично | Явно и възпроизводимо за Git, CI и контейнери |
| Нов Linux контейнер се проваля, но работната станция работи | Инсталирайте/актуализирайте CA пакета или добавете CA на организацията към доверието/Git пакета на контейнера | Контейнерът има своя собствена файлова система и материали за доверие |
| Само една самостоятелно хоствана Git услуга се проваля за много потребители | Инспектирайте и поправете веригата от сертификати на сървъра | Поправката от страна на сървъра избягва корекции за всеки клиент |
| Самият HTTPS прокси има частен сертификат | Конфигурирайте доверения CA за HTTPS проксито с http.proxySSLCAInfo, ако е приложимо | Верификацията на TLS на проксито е отделна от верификацията на сървъра на произход |
Някой предлага http.sslVerify=false | Не го използвайте като постоянно решение | Това заобикаля верификацията на сертификата, която защитава HTTPS връзката |
SSH може да бъде валидна алтернативна транспортна опция, ако вашата Git хостинг услуга я поддържа и вашата организация я разрешава. Промяната от HTTPS отдалечен хост към SSH отдалечен хост избягва напълно HTTPS веригата от сертификати, но не поправя оригиналния проблем с TLS доверието. SSH има свой собствен модел за верификация на хост ключове и управление на удостоверения.
Използвайте SSH, защото пасва на вашия дизайн за удостоверяване и внедряване, а не просто за да скриете грешка в конфигурацията на сертификата, която други HTTPS инструменти ще продължат да срещат.
http.proxySSLCAInfo за грешната връзка. Тази настройка е за верификация на HTTPS прокси, а не за обща замяна на конфигурацията на CA на сървъра на произход.Грешката на Git SSL certificate problem: unable to get local issuer certificate е проблем с веригата на доверие, а не проблем с токена за удостоверяване и не е нещо, което обикновено трябва да се решава чрез изключване на верификацията на сертификата. Разберете дали Git използва OpenSSL, Schannel, персонализиран CA пакет или HTTPS прокси; след това поставете одобрения издаващ CA в източника на доверие, който Git всъщност използва.
В Windows Schannel е практична опция, когато корпоративният CA вече се управлява в Хранилището за сертификати на Windows. В CI, контейнери или среди, които се нуждаят от възпроизводимо доверие, базирано на файлове, http.sslCAInfo често е по-ясен. И когато множество клиенти се провалят срещу една самостоятелно хоствана услуга, поправете веригата от сертификати на сървъра, вместо да разпространявате несигурни заобикаляния.
Поправете CSS стиловете на Tailwind, които не се актуализират във Vite React, като проверите настройката на Tailwind v4, CSS импортирането, откриването на източници, динамичните класове, HMR и остарелите кешове.
Поправете ModuleNotFoundError на Python 3 за pip на Windows, macOS и Linux с ensurepip, OS пакети, виртуални среди и проверки на интерпретатора.
Поправете отказан достъп до GitHub SSH (публичен ключ), като проверите хоста, активния SSH ключ, GitHub акаунта, SSO оторизацията, отдалечения URL адрес и достъпа до порт 22.
Поправете безопасно Git push, който не превърта напред. Защитете локалната работа, извлечете отдалечени коммити, изберете сливане или пребазиране, разрешите конфликти и push-вайте без загуба на промени.
Поправете грешките Nginx 502 Bad Gateway с Node.js upstream, като проверите порта на приложението, NGINX лог файловете, proxy_pass адреса, мрежата на контейнера, времето за изчакване и презареждането.
Поправете грешката на TypeScript „Тип 'null' не може да се присвоява на тип“ с типове обединения, стесняване, стойности по подразбиране и безопасни твърдения под strictNullChecks.
Поправете грешката за негенериран Prisma Client, като проверите генератора, схемата, изходния път, импортите, версиите, настройката на монорепо и стъпките за изграждане при внедряване.
Поправете Node.js ERR_MODULE_NOT_FOUND в ESM, като проверите пътищата за импортиране, файловите разширения, инсталирането на пакети, експортирането, ESM режима и чистите инсталации.
Поправете грешката на Git "unable to get local issuer certificate", като идентифицирате бекенда за доверие, инсталирате правилната CA верига и запазите SSL верификацията активирана.
Поправете грешките за изтичане на мрежовото време в Mongoose, като идентифицирате типа на таймаута, тествате достъпността на Atlas или TCP, коригирате URI и настройвате таймаутите само когато е оправдано.
