Nav nozīmīgu 2026. gada izmaiņu, kas padarītu veco “izslēgt SSL verifikāciju” risinājumu par labu fiksāciju. Pašreizējā Git dokumentācija joprojām pēc noklusējuma iestata http.sslVerify uz true, un Git joprojām atbalsta gan failos balstītu CA uzticību, gan izvēlamas TLS aizmugurprogrammas, piemēram, OpenSSL un Schannel. Ilgtermiņa risinājums ir likt Git uzticēties pareizajam sertifikātu izdevējam vai labot nepilnīgu servera sertifikātu ķēdi, nevis atspējot verifikāciju.
Kļūda SSL certificate problem: unable to get local issuer certificate nozīmē, ka TLS bibliotēka, ko izmanto Git, nevarēja izveidot uzticamu sertifikātu ķēdi no servera sertifikāta līdz sertifikātu izdevējam, kam tā uzticas. Tas var notikt, jo vietējā CA krātuvē trūkst izdevēja CA, korporatīvais HTTPS inspekcijas starpniekserveris pārparaksta trafiku ar iekšēju CA, Git lasa nepareizo CA kopu vai pašpārvaldīts Git serveris nepiedāvā nepieciešamos starpposma sertifikātus.
Tipiska Git HTTPS kļūme: attālinātais serveris ir sasniedzams, bet sertifikātu ķēdes verifikācija nevar atrast uzticamu izdevēju.
Izmantojiet šādu secību:
Git pašreizējā git-config dokumentācija definē http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend un Schannel specifisko uzvedību, kas tiek izmantota Windows. Noklusējuma stāvoklis sertifikātu verifikācijai joprojām ir iespējots.
Uzticams labojums ir atjaunot derīgu uzticības ķēdi, nevis apspiest sertifikāta pārbaudi.
Pirms instalējat sertifikātus vai rediģējat konfigurāciju, pārbaudiet vērtības un to avotus:
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.proxySSLCAInfoJa komanda neko neizvada, šī opcija var vienkārši izmantot Git vai libcurl noklusējuma iestatījumus. --show-origin ir svarīgs, jo vērtība var nākt no sistēmas, globālās, lokālās repozitorija vai iekļautajām konfigurācijas failiem. Nepareiza līmeņa labošana var atstāt efektīvo iestatījumu nemainītu.
Pārbaudiet arī attālināto serveri, ar kuru jūs patiesībā sazināties:
git remote -v
git ls-remote https://git.example.com/team/repo.gitJa Git neizdodas tikai vienam korporatīvam vai privātam resursdatoram, kamēr publiskās HTTPS vietnes darbojas, problēma, visticamāk, ir saistīta ar konkrēta resursdatora uzticību vai servera konfigurāciju. Ja Git neizdodas daudziem nesaistītiem HTTPS attālinātajiem serveriem, vispirms pārbaudiet vietējo Git instalāciju, CA kopas ceļu, starpniekserveri un sistēmas uzticības konfigurāciju.
git config --global http.sslVerify falseTas atspējo servera sertifikāta verifikāciju Git HTTPS pieprasījumiem globālajā lietotāja līmenī. Tas var likt kļūdai pazust, vienlaikus noņemot aizsardzību, kas pārbauda, vai jūs sazināties ar paredzēto serveri. Git dokumentācija norāda, ka verifikācija pēc noklusējuma ir iespējota ar iemeslu.
Ja atklājat vecu globālu apvedceļu, kas vairs nav nepieciešams, atjaunojiet noklusējuma uzvedību:
git config --global --unset http.sslVerifyvai eksplicīti iestatiet:
git config --global http.sslVerify trueWindows izstrādātāji bieži saskaras ar šo kļūdu, kad pārlūks darbojas, bet Git nē. Tas nenozīmē, ka serveris ir bojāts. Pārlūks var uzticēties korporatīvajam saknes sertifikātam, kas instalēts Windows, kamēr Git, kas konfigurēts ar OpenSSL stila aizmugurprogrammu, var izmantot atsevišķu CA kopu.
Git atbalsta http.sslBackend vērtības, piemēram, openssl un schannel. curl oficiālā TLS sertifikātu dokumentācija paskaidro, ka Schannel pēc noklusējuma izmanto Windows iebūvēto CA krātuvi.
git config --global http.sslBackend schannelTas bieži ir labs risinājums Windows darbstacijām, ko pārvalda organizācija, kas izplatīta uzticamus saknes un starpposma sertifikātus, izmantojot Windows politiku. Tas ļauj Git paļauties uz to pašu Windows sertifikātu uzticības sistēmu, ko var izmantot citas natīvās lietotnes.
Ir kompromiss: aizmugurprogrammas maiņa maina Git HTTPS sertifikāta uzvedību globāli šim lietotājam. Ja jūsu organizācija apzināti pārvalda īpašu PEM kopu Git vai automatizācijai, palikšana pie OpenSSL var būt paredzamāka.
Git pašreizējā dokumentācija arī norāda uz smalku Schannel uzvedību: kad Schannel ir atlasīts, izmantojot http.sslBackend, Git parasti izvairās no http.sslCAInfo piemērošanas, jo piegādātā CA kopa var pārrakstīt Windows Sertifikātu Krātuvi. Iestatījums http.schannelUseSSLCAInfo eksistē vidēm, kas apzināti vēlas šo uzvedību.
Ja jūsu organizācija sniedz jums PEM kopu, kas satur nepieciešamos iekšējos saknes un starpposma sertifikātus, konfigurējiet Git izmantot šo failu:
git config --global http.sslCAInfo "C:/certs/company-ca-bundle.pem"Git definē http.sslCAInfo kā failu, kas satur sertifikātus, kurus izmanto, lai pārbaudītu peer (otru pusi). Jūs varat arī ierobežot HTTP konfigurāciju līdz atbilstošam URL, nevis mainīt katru HTTPS mērķi. Git konfigurācija http.<url>.* atbalsta URL specifisku atbilstību pēc shēmas, resursdatora, porta un ceļa.
Piemēram:
git config --global http."https://git.example.com/".sslCAInfo "C:/certs/company-ca-bundle.pem"Šis šaurākais iestatījums ir noderīgs, kad tikai iekšējam Git serverim ir nepieciešams privāts CA, kamēr publiskajiem Git resursdatoriem jāturpina izmantot parasto uzticības kopu.
Princips ārpus Windows ir tāds pats: Git procesam ir jāpiekļūst CA sertifikātam, kas izdeva servera vai starpniekservera sertifikātu. Precīzās sistēmas uzticības krātuves komandas atšķiras atkarībā no operētājsistēmas un Linux distribūcijas, tāpēc izmantojiet platformas oficiālo sertifikātu pārvaldības mehānismu vai eksplicītu Git CA kopu, ko sniedz jūsu administrators.
Git ir jāspēj savienot piedāvāto servera sertifikātu caur tā starpposma izdevējiem ar lokāli uzticamu CA.
Kontrolētam CI uzdevumam vai konteineram, kur nevēlaties mainīt saimniekdatora globālo uzticības krātuvi, CA kopa var būt eksplicīta:
git config --global http.sslCAInfo /etc/company/git-ca-bundle.pemvai atsevišķam procesam Git arī atpazīst vides mainīgo GIT_SSL_CAINFO. Pašreizējā Git dokumentācija norāda, ka šis vides mainīgais var pārrakstīt http.sslCAInfo.
Nekopējiet nejaušu cacert.pem failu no foruma. Ja trūkstošais sertifikāts ir korporatīvais CA, saņemiet to no jūsu IT vai PKI komandas. Ja attālinātais serveris ir publisks pakalpojums un jūsu CA kopa ir vienkārši novecojusi, atjauniniet operētājsistēmu, Git distribūciju, konteinera bāzes attēlu vai uzticamo CA pakotni, izmantojot tās parasto atjaunināšanas kanālu.
Daži uzņēmumu starpniekserveri inspicē HTTPS un piedāvā aizstājēja sertifikātu, ko parakstījis iekšējs korporatīvais CA. Šādā situācijā pārlūks var izdoties, jo korporatīvais CA ir instalēts OS uzticības krātuvē, kamēr Git atsevišķā CA kopā tas nav iekļauts.
Pareizais risinājums ir uzticēties organizācijas CA, izmantojot atbilstošo uzticības krātuvi vai Git kopu. Neeksportējiet pašreizējo lapas (leaf) sertifikātu un pastāvīgi tam neuzticieties kā aizstājēju izdevēja korporatīvajam CA.
Atšķiriet arī divus atsevišķus starpniekservera gadījumus:
http.sslCAInfo.http.proxySSLCAInfo īpaši CA kopai, ko izmanto, lai pārbaudītu šo HTTPS starpniekservera savienojumu.Git dokumentē http.proxy un http.proxySSLCAInfo atsevišķi, tāpēc izmantojiet iestatījumu, kas atbilst kļūstošajam savienojumam.
Ja daudzi lietotāji vai jaunas iekārtas neizdodas pret to pašu pašmitināto Git serveri, problēma var būt servera pusē, nevis salauzto klientu kopums. Serverim ir jāpiedāvā sertifikātu ķēde, kas klientiem nepieciešama, lai savienotu lapas sertifikātu ar uzticamu izdevēju.
Kad daudzi klienti neizdodas pret vienu privātu Git resursdatoru, pārbaudiet servera ķēdi un starpniekservera ceļu, pirms izplatāt klienta puses apvedceļus.
GitLab oficiālā SSL problēmu novēršanas dokumentācija īpaši apraksta unable to get local issuer certificate kā gadījumu, kad klients nevar iegūt nepieciešamo izdevēju, un iesaka vai nu uzticēties atbilstošajam CA klientā, vai labot serveri, lai tas piedāvātu pilnu sertifikātu ķēdi.
Ja pārvaldāt serveri, labojiet konfigurēto pilnas ķēdes sertifikātu un pārbaudiet no tīra klienta. Tas ir labāk nekā lūgt katram izstrādātājam pievienot ad hoc izņēmumus.
Pēc tam, kad uzticības konfigurācija ir labota, atkārtojiet to pašu Git darbību:
git ls-remote https://git.example.com/team/repo.gitJa tas izdodas, mēģiniet vēlreiz sākotnējo clone, fetch, pull vai push.
Pēc tam pārbaudiet galīgo ar drošību saistīto konfigurāciju:
git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslBackend
git config --show-origin --get http.sslCAInfoParedzētais stāvoklis ir tāds, ka sertifikātu verifikācija paliek iespējota un Git var izveidot derīgu ķēdi, izmantojot paredzēto uzticības avotu.
| Situācija | Labākais sākumpunkts | Kāpēc |
|---|---|---|
| Windows pārlūks darbojas; Git neizdodas korporatīvajā tīklā | Pārbaudiet, vai korporatīvais CA ir Windows uzticības krātuvē; apsveriet Schannel | Pārlūka un Windows uzticība var jau būt pareiza, kamēr Git OpenSSL izmanto citu kopu |
| Uzņēmums nodrošina PEM CA kopu izstrādātāju rīkiem | Izmantojiet http.sslCAInfo, vēlams, resursdatora specifisku, kad praktiski | Eksplicīts un reproducējams Git, CI un konteineriem |
| Jauns Linux konteiners neizdodas, bet darbstacija darbojas | Instalējiet/atjauniniet CA pakotni vai pievienojiet organizācijas CA konteinera uzticības/Git kopai | Konteineram ir sava failu sistēma un uzticības materiāls |
| Tikai viens pašmitināts Git pakalpojums neizdodas daudziem lietotājiem | Pārbaudiet un labojiet servera sertifikātu ķēdi | Servera puses labošana izvairās no klienta līmeņa ielāpiem |
| HTTPS starpniekserverim pašam ir privāts sertifikāts | Konfigurējiet uzticamo CA HTTPS starpniekserverim ar http.proxySSLCAInfo, ja piemērojams | Starpniekservera TLS verifikācija ir atdalīta no izcelsmes servera verifikācijas |
Kāds ierosina http.sslVerify=false | Nelietojiet to kā pastāvīgu risinājumu | Tas apiet sertifikātu verifikāciju, kas aizsargā HTTPS savienojumu |
SSH var būt derīga alternatīva transporta metode, ja jūsu Git mitināšanas pakalpojums to atbalsta un jūsu organizācija to atļauj. Pārslēgšanās no HTTPS attālinātā servera uz SSH attālināto serveri pilnībā izvairās no HTTPS sertifikātu ķēdes, bet tas nelabo sākotnējo TLS uzticības problēmu. SSH ir sava saimnes atslēgas verifikācijas un akreditācijas pārvaldības modelis.
Izmantojiet SSH, jo tas atbilst jūsu autentifikācijas un izvietošanas dizainam, nevis tikai tāpēc, lai slēptu sertifikāta konfigurācijas kļūdu, ar kuru citi HTTPS rīki turpinās saskarties.
http.proxySSLCAInfo izmantošana nepareizam savienojumam. Šis iestatījums ir paredzēts HTTPS starpniekservera verifikācijai, nevis vispārīgai izcelsmes servera CA konfigurācijas aizstāšanai.Git kļūda SSL certificate problem: unable to get local issuer certificate ir uzticības ķēdes problēma, nevis autentifikācijas tokena problēma, un tā parasti nav jārisina, izslēdzot sertifikātu verifikāciju. Noskaidrojiet, vai Git izmanto OpenSSL, Schannel, pielāgotu CA kopu vai HTTPS starpniekserveri; pēc tam ievietojiet apstiprināto izdevēja CA uzticības avotā, ko Git patiesībā izmanto.
Windows sistēmā Schannel ir praktiska opcija, kad korporatīvais CA jau tiek pārvaldīts Windows Sertifikātu Krātuvē. CI, konteineros vai vidēs, kurām nepieciešama reproducējama failos balstīta uzticība, http.sslCAInfo bieži ir skaidrāks. Un, kad daudzi klienti neizdodas pret vienu pašmitinātu pakalpojumu, labojiet servera sertifikātu ķēdi, nevis izplatiet nedrošus apvedceļus.
Novērsiet Linux ENOSPC failu vērotāja kļūdas, pārbaudot inotify ierobežojumus, atrodot procesus, kuros ir daudz vērotāja resursu, droši paaugstinot ierobežojumus un padarot izmaiņas pastāvīgas.
Novērsiet Tailwind CSS stilu neatjaunināšanu pakalpojumā Vite React, pārbaudot Tailwind v4 iestatījumus, CSS importēšanu, avota noteikšanu, dinamiskās klases, HMR un novecojušas kešatmiņas.
Novērsiet Python 3 ModuleNotFoundError kļūdu pip funkcijai operētājsistēmās Windows, macOS un Linux, izmantojot ensurepip, OS pakotnes, virtuālās vides un interpretētāja pārbaudes.
Novērsiet GitHub SSH atļaujas liegšanu (publiskā atslēga), pārbaudot resursdatoru, aktīvo SSH atslēgu, GitHub kontu, SSO autorizāciju, attālo URL un 22. porta piekļuvi.
Droši izlabojiet Git ne-ātrās pārtīšanas kļūdu. Aizsargājiet lokālo darbu, ielādējiet attālinātus izmaiņu izmaiņu ierakstus, izvēlieties apvienošanu vai atkārtotu bāzi, atrisiniet konfliktus un veiciet izmaiņu pārtīšanu, nezaudējot izmaiņas.
Izlabojiet Nginx 502 Bad Gateway kļūdas ar Node.js augšupējo resursu, pārbaudot lietotnes portu, NGINX žurnālus, proxy_pass adresi, konteineru tīklošanu, taimautus un atkārtotu ielādi.
Novērsta TypeScript kļūda “Tips 'null' nav piešķirams tipam”, izmantojot apvienošanas tipus, sašaurināšanu, noklusējuma vērtības un drošas apgalvojumus, izmantojot strictNullChecks.
Novērsiet Prisma Client ģenerēšanas kļūdu, pārbaudot savu ģeneratoru, shēmu, izvades ceļu, importus, versijas, monorepo iestatījumu un izvietošanas būvēšanas soļus.
Izlabojiet Node.js ERR_MODULE_NOT_FOUND kļūdu ESM, pārbaudot importēšanas ceļus, failu paplašinājumus, pakotņu instalēšanu, eksportēšanu, ESM režīmu un tīrās instalācijas.
Novērsiet Git kļūdu “nevar iegūt vietējo izdevēja sertifikātu”, identificējot uzticības aizmugurprogrammu, instalējot pareizo CA ķēdi un saglabājot SSL verifikāciju iespējotu.
