Nincs olyan jelentős 2026-os változás, amely a régi „SSL-ellenőrzés kikapcsolása” kerülő megoldást jó javítássá tenné. A jelenlegi Git dokumentáció továbbra is igaz értékre állítja alapértelmezettként a http.sslVerify beállítást, és a Git továbbra is támogatja mind a fájlalapú CA-megbízást, mind a választható TLS-háttérprogramokat, mint például az OpenSSL és a Schannel. A tartós megoldás az, hogy a Git megbízzon a helyes tanúsítványkiadó hatóságban, vagy javítsa meg a hiányos szervertanúsítvány-láncot – ne pedig tiltsa le az ellenőrzést.
Az SSL certificate problem: unable to get local issuer certificate hiba azt jelenti, hogy a Git által használt TLS-könyvtár nem tudott megbízható tanúsítványláncot felépíteni a szervertanúsítványtól egy olyan tanúsítványkiadó hatóságig, amelyben a Git megbízik. Ez akkor fordulhat elő, ha a helyi CA-tároló hiányos a kiállító CA miatt, egy vállalati HTTPS-ellenőrző proxy belső CA-val újra aláírja a forgalmat, a Git rossz CA-csomagot olvas be, vagy egy saját üzemeltetésű Git-szerver nem szolgáltatja a szükséges közvetítő tanúsítványokat.
Egy tipikus Git HTTPS hiba: a távoli elérés elérhető, de a tanúsítványlánc-ellenőrzés nem talál megbízható kiadót.
Használja ezt a sorrendet:
A Git jelenlegi git-config dokumentációja definiálja a http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend beállításokat, valamint a Windows-on használt Schannel-specifikus viselkedést. A tanúsítvány-ellenőrzés alapértelmezése továbbra is engedélyezett.
A megbízható javítás egy érvényes megbízhatósági lánc visszaállítása, nem pedig a tanúsítvány-ellenőrzés elnyomása.
Mielőtt tanúsítványokat telepítene vagy konfigurációt szerkesztene, vizsgálja meg az értékeket és azok forrását:
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.proxySSLCAInfoHa egy parancs semmit nem ír ki, az az opció egyszerűen a Git vagy a libcurl alapértelmezését használhatja. A --show-origin fontos, mert egy érték származhat rendszer-, globális, helyi repó- vagy beágyazott konfigurációs fájlokból. A rossz szint javítása változatlanul hagyhatja a tényleges beállítást.
Ellenőrizze azt a távoli elérést is, amelyhez valójában kapcsolódik:
git remote -v
git ls-remote https://git.example.com/team/repo.gitHa a Git csak egy vállalati vagy privát hoszt esetén bukik el, miközben a nyilvános HTTPS-oldalak működnek, a probléma valószínűleg hoszt-specifikus megbízás vagy szerverkonfiguráció. Ha a Git sok, egymástól független HTTPS-távoli elérésnél bukik el, először vizsgálja meg a helyi Git-telepítést, a CA-csomag útvonalát, a proxyt és a rendszer megbízhatósági konfigurációját.
git config --global http.sslVerify falseEz globális felhasználói szinten letiltja a szervertanúsítvány-ellenőrzést a Git HTTPS-kéréseihez. Ez eltüntetheti a hibát, miközben megszünteti azt a védelmet is, amely ellenőrzi, hogy a kívánt szerverrel kommunikál. A Git dokumentációja okkal állítja, hogy az ellenőrzés alapértelmezetten engedélyezett.
Ha talál egy régi globális kerülőt, amely már nem szükséges, állítsa vissza az alapértelmezett viselkedést:
git config --global --unset http.sslVerifyvagy állítsa be kifejezetten:
git config --global http.sslVerify trueA Windows-fejlesztők gyakran találkoznak ezzel a hibával, amikor a böngésző működik, de a Git nem. Ez nem feltétlenül jelenti azt, hogy a szerver hibás. A böngésző megbízhat egy vállalati gyökértanúsítványban, amely telepítve van a Windowsban, míg az OpenSSL-stílusú háttérprogrammal konfigurált Git külön CA-csomagot használhat.
A Git támogatja az olyan http.sslBackend értékeket, mint az openssl és a schannel. A curl hivatalos TLS-tanúsítvány dokumentációja magyarázza, hogy a Schannel alapértelmezetten a Windows natív CA-tárolóját használja.
git config --global http.sslBackend schannelEz gyakran jó választás Windows-kizárólagos munkahelyi állomásokhoz, amelyeket olyan szervezet kezel, amely megbízható gyökér- és közvetítő tanúsítványokat terjeszt Windows-házirendeken keresztül. Ez lehetővé teszi, hogy a Git ugyanarra a Windows-tanúsítvány-megbízhatósági rendszerre támaszkodjon, amelyet más natív alkalmazások is használnak.
Van egy kompromisszum: a háttérprogram megváltoztatása globálisan megváltoztatja a Git HTTPS-tanúsítvány viselkedését az adott felhasználó számára. Ha a szervezete szándékosan kezel egy dedikált PEM-csomagot a Git vagy az automatizálás számára, az OpenSSL-nél maradás kiszámíthatóbb lehet.
A Git jelenlegi dokumentációja egy finom Schannel-viselkedést is megjegyez: amikor a Schannelt választják a http.sslBackend révén, a Git normál esetben kerüli a http.sslCAInfo alkalmazását, mert egy megadott CA-csomag felülírhatja a Windows Tanúsítványtárolóját. A http.schannelUseSSLCAInfo beállítás létezik azokhoz a környezetekhez, amelyek szándékosan ezt a viselkedést kívánják.
Ha a szervezete ad egy PEM-csomagot, amely tartalmazza a szükséges belső gyökér- és közvetítő tanúsítványokat, konfigurálja a Gitet, hogy ezt a fájlt használja:
git config --global http.sslCAInfo "C:/certs/company-ca-bundle.pem"A Git a http.sslCAInfo-t úgy definiálja, mint azt a fájlt, amely a peer ellenőrzéséhez használt tanúsítványokat tartalmazza. Az HTTP-konfigurációt korlátozhatja egy illeszkedő URL-re is, ahelyett, hogy minden HTTPS-célt megváltoztatna. A Git http.<url>.* konfigurációja támogatja az URL-specifikus egyeztetést séma, hoszt, port és útvonal alapján.
Például:
git config --global http."https://git.example.com/".sslCAInfo "C:/certs/company-ca-bundle.pem"Ez a szűkebb beállítás hasznos, amikor csak egy belső Git-szervernek van szüksége privát CA-ra, miközben a nyilvános Git-hosztoknak továbbra is a normál megbízhatósági csomagot kell használniuk.
Az elv ugyanaz a Windowson kívül is: a Git-folyamatnak hozzáféréssel kell rendelkeznie ahhoz a CA-tanúsítványhoz, amely a szerver- vagy proxytanúsítványt kiállította. A pontos rendszer-megbízhatósági tároló parancsok operációs rendszerenként és Linux-disztribúciónként eltérnek, ezért használja a platform hivatalos tanúsítványkezelési mechanizmusát, vagy egy rendszergazda által biztosított explicit Git CA-csomagot.
A Gitnek képesnek kell lennie arra, hogy a bemutatott szervertanúsítványt a közvetítő kiadók révén egy helyileg megbízott CA-hoz kösse.
Egy kontrollált CI-feladatban vagy konténerben, ahol nem kívánja módosítani a gazdagép globális megbízhatósági tárolóját, a CA-csomag explicit lehet:
git config --global http.sslCAInfo /etc/company/git-ca-bundle.pemvagy, egyetlen folyamathoz, a Git felismeri a GIT_SSL_CAINFO környezeti változót is. A jelenlegi Git-dokumentáció kimondja, hogy ez a környezeti változó felülírhatja a http.sslCAInfo-t.
Ne másoljon egy véletlenszerű cacert.pem fájlt egy fórumról. Ha a hiányzó tanúsítvány egy vállalati CA, szerezze be az IT vagy PKI csapatától. Ha a távoli elérés egy nyilvános szolgáltatás, és a CA-csomagja egyszerűen elavult, frissítse az operációs rendszert, a Git-disztribúciót, a konténer alapimage-et vagy a megbízható CA-csomagot a normál frissítési csatornán keresztül.
Egyes vállalati proxyk ellenőrzik a HTTPS-forgalmat, és egy belső vállalati CA által aláírt helyettesítő tanúsítványt szolgáltatnak. Ebben a helyzetben a böngésző sikeres lehet, mert a vállalati CA telepítve van az OS megbízhatósági tárolójába, míg a Git külön CA-csomagja nem tartalmazza.
A helyes megoldás az, hogy megbízzon a szervezet CA-jában a megfelelő megbízhatósági tárolón vagy Git-csomagon keresztül. Ne exportálja a jelenlegi levél-tanúsítványt, és ne bízzon benne állandóan a kiállító vállalati CA helyettesítéseként.
Különböztesse meg a két különálló proxy esetet is:
http.sslCAInfo.http.proxySSLCAInfo-t ahhoz a CA-csomaghoz, amelyet az adott HTTPS-proxykapcsolat ellenőrzésére használnak.A Git külön dokumentálja a http.proxy és a http.proxySSLCAInfo beállításokat, ezért használja azt a beállítást, amely a hibás kapcsolathoz illeszkedik.
Ha sok felhasználó vagy új gép ugyanazon a saját üzemeltetésű Git-szerveren bukik el, a probléma lehet szerveroldali, és nem egy törött ügyfelek gyűjteménye. A szervernek azt a tanúsítványláncot kell szolgáltatnia, amelyre az ügyfeleknek szükségük van a levél-tanúsítvány egy megbízható kiadóhoz kötéséhez.
Amikor sok ügyfél bukik el egy privát Git-hoszt ellen, ellenőrizze a szerverláncot és a proxyútvonalat, mielőtt ügyféloldali kerülő megoldásokat terjesztene.
A GitLab hivatalos SSL-hibaelhárítási dokumentációja kifejezetten úgy írja le az unable to get local issuer certificate esetet, mint amikor az ügyfél nem tudja beszerezni a szükséges kiadót, és azt javasolja, hogy vagy bízzon a megfelelő CA-ban az ügyfélen, vagy javítsa meg a szervert, hogy teljes tanúsítványláncot szolgáltasson.
Ha Ön kezeli a szervert, javítsa meg a konfigurált teljes láncú tanúsítványt, és tesztelje újra egy tiszta ügyfélről. Ez előnyösebb, mint arra kérni minden fejlesztőt, hogy ad hoc kivételeket adjon hozzá.
Miután a megbízhatósági konfiguráció helyes, ismételje meg ugyanazt a Git-műveletet:
git ls-remote https://git.example.com/team/repo.gitHa ez sikeres, próbálja újra az eredeti clone, fetch, pull vagy push műveletet.
Ezután vizsgálja meg a végső biztonsági vonatkozású konfigurációt:
git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslBackend
git config --show-origin --get http.sslCAInfoA várt állapot az, hogy a tanúsítvány-ellenőrzés engedélyezve marad, és a Git képes érvényes láncot felépíteni a szándékolt megbízhatósági forráson keresztül.
| Helyzet | Legjobb kiindulópont | Miért |
|---|---|---|
| A Windows-böngésző működik; a Git bukik egy vállalati hálózaton | Ellenőrizze, hogy a vállalati CA benne van-e a Windows megbízhatósági tárolójában; fontolja meg a Schannelt | A böngésző és a Windows-megbízás már helyes lehet, míg a Git OpenSSL más csomagot használ |
| A cég PEM CA-csomagot biztosít fejlesztői eszközökhöz | Használja a http.sslCAInfo-t, lehetőleg hoszt-specifikusan, ha lehetséges | Explicit és reprodukálható a Git, CI és konténerek számára |
| Egy új Linux-konténer bukik el, de a munkahelyi állomás működik | Telepítse/frissítse a CA-csomagot, vagy adja hozzá a szervezet CA-ját a konténer megbízhatósági/Git-csomagjához | A konténernek saját fájlrendszere és megbízhatósági anyagai vannak |
| Csak egy saját üzemeltetésű Git-szolgáltatás bukik el sok felhasználó esetén | Vizsgálja meg és javítsa meg a szerver tanúsítványláncát | A szerveroldali javítás elkerüli az ügyfélenkénti javításokat |
| A HTTPS-proxynak saját privát tanúsítványa van | Konfigurálja a megbízható CA-t a HTTPS-proxyhoz a http.proxySSLCAInfo-val, ha alkalmazható | A proxy TLS-ellenőrzése külön áll az eredeti szerver ellenőrzésétől |
Valaki a http.sslVerify=false beállítást javasolja | Ne használja állandó megoldásként | Ez megkerüli a tanúsítvány-ellenőrzést, amely védi a HTTPS-kapcsolatot |
Az SSH érvényes alternatív transzport lehet, ha a Git-hosztolási szolgáltatása támogatja, és a szervezete engedélyezi. Az HTTPS-távoli elérésről SSH-távoli elérésre váltás teljesen elkerüli az HTTPS-tanúsítványláncot, de nem javítja meg az eredeti TLS-megbízhatósági problémát. Az SSH-nak saját hosztkulcs-ellenőrzési és hitelesítőadat-kezelési modellje van.
Az SSH-t azért használja, mert illik az Ön hitelesítési és telepítési tervezetébe – nem pusztán azért, hogy elrejtsen egy tanúsítványkonfigurációs hibát, amellyel más HTTPS-eszközök továbbra is találkozni fognak.
http.proxySSLCAInfo használata rossz kapcsolathoz. Ez a beállítás egy HTTPS-proxy ellenőrzésére szolgál, nem általános helyettesítője az eredeti szerver CA-konfigurációjának.A Git SSL certificate problem: unable to get local issuer certificate hibája egy megbízhatósági lánc probléma, nem egy hitelesítő token probléma, és nem valami, amit normál esetben a tanúsítvány-ellenőrzés kikapcsolásával kellene megoldani. Derítse ki, hogy a Git OpenSSL-t, Schannelt, egyéni CA-csomagot vagy HTTPS-proxyt használ-e; majd helyezze el a jóváhagyott kiállító CA-t abban a megbízhatósági forrásban, amelyet a Git valójában használ.
Windows-on a Schannel gyakorlati opció, amikor a vállalati CA már kezelt a Windows Tanúsítványtárolójában. CI-ben, konténerekben vagy olyan környezetekben, amelyek reprodukálható, fájlapú megbízást igényelnek, a http.sslCAInfo gyakran tisztább. És amikor több ügyfél bukik el egy saját üzemeltetésű szolgáltatás ellen, javítsa meg a szerver tanúsítványláncát ahelyett, hogy nem biztonságos kerülőket terjesztene.
Fix Tailwind CSS styles not updating in Vite React by checking Tailwind v4 setup, CSS imports, source detection, dynamic classes, HMR, and stale caches.
Javítsd ki a Python 3 ModuleNotFoundError hibáját a pip esetében Windows, macOS és Linux rendszereken ensurepip, operációsrendszer-csomagok, virtuális környezetek és interpreter-ellenőrzések segítségével.
Javítsd ki a GitHub SSH engedély megtagadva (nyilvános kulcs) hibát a gazdagép, az aktív SSH kulcs, a GitHub fiók, az SSO-engedélyezés, a távoli URL és a 22-es port hozzáférésének ellenőrzésével.
Git nem gyorsított push hiba javítása biztonságosan. Helyi munka védelme, távoli commitok beolvasása, egyesítés vagy újraalapozás kiválasztása, ütközések feloldása és push végrehajtása a változtatások elvesztése nélkül.
Javítsd ki az Nginx 502 Bad Gateway hibákat egy Node.js upstream fájllal az alkalmazásport, az NGINX naplók, a proxy_pass cím, a konténerhálózat, az időtúllépések és az újratöltés ellenőrzésével.
Kijavítottuk a TypeScript „A 'null' típus nem rendelhető típushoz” hibáját uniótípusokkal, szűkítéssel, alapértelmezett értékekkel és biztonságos állításokkal a strictNullChecks alatt.
Javítsa ki a Prisma Client nem generált hibát a generátor, a séma, a kimeneti útvonal, az importok, a verziók, a monorepo beállítás és a telepítési build lépések ellenőrzésével.
Javítsd ki a Node.js ERR_MODULE_NOT_FOUND hibát az ESM-ben az importálási útvonalak, fájlkiterjesztések, csomagtelepítés, exportálások, ESM mód és tiszta telepítések ellenőrzésével.
Javítsd ki a Git 'unable to get local issuer certificate' hibáját a megbízható háttérprogram azonosításával, a helyes CA-lánc telepítésével, és az SSL-ellenőrzés engedélyezve tartásával.
Javítsa a Mongoose MongoDB hálózati időtúllépési hibáit az időtúllépés típusának azonosításával, az Atlas vagy TCP elérhetőség tesztelésével, az URI helyesbítésével, és az időtúllépések beállításával csak akkor, ha az indokolt.
