Kaip išspręsti SSL sertifikato problemą: „Unable to Get Local Issuer Certificate“ Git

Nėra jokių reikšmingų 2026 m. pokyčių, kurie paverstų seną „SSL patikros išjungimo“ apėjimą geru sprendimu. Dabartinė Git dokumentacija vis dar numato http.sslVerify reikšmę true, o Git vis dar palaiko tiek failais pagrįstą CA pasitikėjimą, tiek pasirinkamus TLS posistemius, tokius kaip OpenSSL ir Schannel. Patvarus sprendimas yra priversti Git pasitikėti tinkamu sertifikato išdavėju arba sutvarkyti nepilną serverio sertifikatų grandinę, o ne išjungti patikrą.

Klaida SSL certificate problem: unable to get local issuer certificate reiškia, kad Git naudojama TLS biblioteka negalėjo sudaryti patikimos sertifikatų grandinės nuo serverio sertifikato iki sertifikato išdavėjo, kuriuo ji pasitiki. Taip gali atsitikti, jei vietinėje CA saugykloje trūksta išdavėjo CA, įmonės HTTPS inspekcijos tarpinis serveris persirašo srautą naudodamas vidinį CA, Git skaito neteisingą CA paketą arba savarankiškai valdomas Git serveris nepateikia būtinų tarpinių sertifikatų.

Tipinė Git HTTPS nesėkmė: nuotolinis serveris pasiekiamas, tačiau sertifikatų grandinės patikra negali rasti patikimo išdavėjo.

Pradėkite nuo saugiausio sprendimo

Naudokite šią tvarką:

1. Patikrinkite, kurie Git SSL nustatymai ir TLS posistemis yra aktyvūs.
2. Nustatykite, ar trūkstamas pasitikėjimas turėtų būti įtrauktas į operacinės sistemos pasitikėjimo saugyklą, ar į Git CA paketą.
3. Jei daugelis klientų nepavyksta prisijungti prie to paties savarankiškai valdomo serverio, sutvarkykite serverio sertifikatų grandinę, o ne taisykite kiekvieną klientą.
4. Pakartotinai patikrinkite su įjungta SSL patikra ir pašalinkite bet kokius laikinus ar pasenusius apėjimo konfigūracijos nustatymus.

Dabartinė Git git-config dokumentacija apibrėžia http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend ir specifinį Schannel elgesį, naudojamą Windows sistemoje. Sertifikato patikros numatytoji reikšmė lieka įjungta.

Patikimas taisymas yra galiojančios pasitikėjimo grandinės atkūrimas, o ne sertifikato patikros slopinimas.

1 žingsnis: sužinokite, ką iš tikrųjų naudoja Git

Prieš diegdami sertifikatus ar redaguodami konfigūraciją, patikrinkite reikšmes ir jų šaltinius:

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

Jei komanda nieko neišveda, ta parinktis gali tiesiog naudoti Git arba libcurl numatytąsias reikšmes. --show-origin yra svarbus, nes reikšmė gali būti nustatyta sistemos, globaliame, vietiniame repo arba įtrauktame konfigūracijos faile. Netinkamo lygio taisymas gali nepakeisti galiojančio nustatymo.

Taip pat patikrinkite nuotolinį serverį, su kuriuo iš tikrųjų jungiatės:

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

Jei Git nepavyksta tik viename įmonės ar privačiame serveryje, o viešos HTTPS svetainės veikia, problema greičiausiai yra specifinė tam serveriui pasitikėjimo ar serverio konfigūracijos klaida. Jei Git nepavyksta daugelyje nepriklausomų HTTPS nuotolinių serverių, pirmiausia patikrinkite vietinę Git diegtį, CA paketo kelią, tarpinį serverį ir sistemos pasitikėjimo konfigūraciją.

Nepaverskite šios komandos pirmąja

git config --global http.sslVerify false

Tai išjungia serverio sertifikato patikrą Git HTTPS užklausoms globaliame vartotojo lygmenyje. Tai gali paslėpti klaidą, tačiau taip pat pašalina apsaugą, kuri patikrina, ar bendraujate su norimu serveriu. Git dokumentacija nurodo, kad patikra yra įjungta numatytuoju būdu ne be priežasties.

Jei aptinkate seną globalų apėjimą, kuris nebereikalingas, atstatykite numatytąjį elgesį:

git config --global --unset http.sslVerify

arba aiškiai nustatykite:

git config --global http.sslVerify true

2 žingsnis: Windows sistemoje pasirinkite tarp Windows sertifikatų saugyklos ir PEM CA paketo

Windows kūrėjai dažnai susiduria su šia klaida, kai naršyklė veikia, o Git – ne. Tai nebūtinai reiškia, kad serveris sugedęs. Naršyklė gali pasitikėti įmonės šakniniu sertifikatu, įdiegtu Windows sistemoje, o Git, sukonfigūruotas naudoti OpenSSL tipo posistemį, gali naudoti atskirą CA paketą.

Git palaiko http.sslBackend reikšmes, tokias kaip openssl ir schannel. Oficiali curl TLS sertifikatų dokumentacija paaiškina, kad Schannel numatytuoju būdu naudoja Windows natyvią CA saugyklą.

A variantas: naudokite Schannel, jei Windows jau turi patikimą įmonės CA

git config --global http.sslBackend schannel

Tai dažnai yra geras pasirinkimas Windows darbo stotims, kurias valdo organizacija, paskirstanti patikimus šakninius ir tarpinius sertifikatus per Windows politiką. Tai leidžia Git remtis ta pačia Windows sertifikatų pasitikėjimo sistema, kurią gali naudoti kitos natyvios programos.

Yra kompromisas: posistemio keitimas keičia Git HTTPS sertifikatų elgesį globaliai tam vartotojui. Jei jūsų organizacija sąmoningai valdo atskirą PEM paketą Git ar automatizavimui, gali būti nuspėjamausia likti prie OpenSSL.

Dabartinė Git dokumentacija taip pat pabrėžia subtilų Schannel elgesį: kai Schannel pasirenkamas per http.sslBackend, Git paprastai vengia taikyti http.sslCAInfo, nes pateiktas CA paketas gali pergalėti Windows sertifikatų saugyklą. Nustatymas http.schannelUseSSLCAInfo egzistuoja aplinkoms, kurios sąmoningai nori tokio elgesio.

B variantas: palikite OpenSSL ir nukreipkite Git į patvirtintą CA paketą

Jei jūsų organizacija pateikia PEM paketą, kuriame yra būtini vidiniai šakniniai ir tarpiniai sertifikatai, sukonfigūruokite Git naudoti tą failą:

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

Git apibrėžia http.sslCAInfo kaip failą, kuriame yra sertifikatai, naudojami patikrinti partnerį. Taip pat galite apriboti HTTP konfigūraciją atitinkančiu URL, vietoj to, kad keistumėte kiekvieną HTTPS tikslą. Git http.<url>.* konfigūracija palaiko URL specifinį atitikimą pagal schemą, hostą, prievartą ir kelią.

Pavyzdžiui:

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

Toks siauresnis nustatymas yra naudingas, kai tik vidinis Git serveris reikalauja privataus CA, o viešieji Git serveriai turėtų toliau naudoti įprastą pasitikėjimo paketą.

3 žingsnis: macOS, Linux, CI ir konteineriuose sutvarkykite CA šaltinį, kurį procesas iš tikrųjų naudoja

Principas už Windows ribų yra tas pats: Git procesas turi turėti prieigą prie CA sertifikato, kuris išdavė serverio ar tarpinio serverio sertifikatą. Tikslūs sistemos pasitikėjimo saugyklos komandų skirtumai priklauso nuo operacinės sistemos ir Linux distribucijos, todėl naudokite platformos oficialų sertifikatų valdymo mechanizmą arba aiškų Git CA paketą, kurį pateikė jūsų administratorius.

Git turi sugebėti susieti pateiktą serverio sertifikatą per jo tarpinius išdavėjus su vietoje patikimu CA.

Kontroliuojamam CI darbui ar konteineriui, kuriame nenorite keisti pagrindinės sistemos globalios pasitikėjimo saugyklos, CA paketas gali būti nurodytas aiškiai:

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

arba atskiram procesui Git taip pat atpažįsta aplinkos kintamąjį GIT_SSL_CAINFO. Dabartinė Git dokumentacija teigia, kad šis aplinkos kintamasis gali pergalvoti http.sslCAInfo.

Nekopijuokite atsitiktinio cacert.pem failo iš forumo. Jei trūkstamas sertifikatas yra įmonės CA, gaukite jį iš savo IT ar PKI komandos. Jei nuotolinis serveris yra vieša paslauga, o jūsų CA paketas tiesiog pasenęs, atnaujinkite operacinę sistemą, Git distribuciją, konteinerio bazinį atvaizdį arba patikimų CA paketą per įprastą atnaujinimo kanalą.

Įmonės TLS inspekcija yra ypatingas atvejis

Kai kurie įmonių tarpiniai serveriai inspektuoja HTTPS ir pateikia pakeistą sertifikatą, pasirašytą vidiniu įmonės CA. Tokiu atveju naršyklė gali pavykti, nes įmonės CA yra įdiegta OS pasitikėjimo saugykloje, o Git atskiras CA paketas jo neturi.

Teisingas sprendimas yra pasitikėti organizacijos CA per tinkamą pasitikėjimo saugyklą arba Git paketą. Neeksportuokite dabartinio lapo (leaf) sertifikato ir nuolat juo nepasitikėkite kaip pakaitalu išdavėjui įmonės CA.

Taip pat atskirkite du atskirus tarpinio serverio atvejus:

• TLS perėmimas iš Git serverio ryšio: įmonės CA, pasirašanti pakeistą serverio sertifikatą, turi būti patikima per įprastą serverio sertifikato kelią, pvz., Windows Schannel arba http.sslCAInfo.
• HTTPS tarpinis serveris, kurio pačio ryšys naudoja TLS: Git pateikia http.proxySSLCAInfo būtent tam CA paketui, naudojamam patikrinti tą HTTPS tarpinio serverio ryšį.

Git dokumentuoja http.proxy ir http.proxySSLCAInfo atskirai, todėl naudokite nustatymą, kuris atitinka nepavykusį ryšį.

4 žingsnis: jei serverio grandinė nepilna, sutvarkykite serverį, kai galite

Jei daugelis vartotojų ar naujų mašinų nepavyksta prisijungti prie to paties savarankiškai valdomo Git serverio, problema gali būti serverio pusėje, o ne sugriuvusių klientų rinkinyje. Serveris turėtų pateikti sertifikatų grandinę, būtiną klientams susieti lapo sertifikatą su patikimu išdavėju.

Kai daugelis klientų nepavyksta prisijungti prie vieno privataus Git hosto, patikrinkite serverio grandinę ir tarpinio serverio kelią prieš platindami klientų pusės apėjimus.

Oficiali GitLab SSL trikčių šalinimo dokumentacija konkrečiai apibūdina unable to get local issuer certificate kaip atvejį, kai klientas negali gauti reikalingo išdavėjo, ir rekomenduoja arba pasitikėti tinkamu CA kliente, arba koreguoti serverį, kad šis pateiktų pilną sertifikatų grandinę.

Jei administruojate serverį, sutvarkykite sukonfigūruotą pilnos grandinės sertifikatą ir pakartotinai patikrinkite iš švaraus kliento. Tai yra pageidautina, nei prašyti kiekvieno kūrėjo pridėti ad hoc išimtis.

Patikrinkite taisymą nesilpninant TLS

Po to, kai pasitikėjimo konfigūracija yra pakoreguota, pakartokite tą pačią Git operaciją:

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

Jei tai pavyksta, bandykite iš naujo originalią clone, fetch, pull ar push komandą.

Tada patikrinkite galutinę su saugumu susijusią konfigūraciją:

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

Tikėtina būsena yra ta, kad sertifikato patikra lieka įjungta, o Git gali sudaryti galiojančią grandinę per numatytąjį pasitikėjimo šaltinį.

Kuris sprendimas atitinka jūsų situaciją?

O kas dėl Git nuotolinio serverio perjungimo į SSH?

SSH gali būti tinkama alternatyvi transporto priemonė, jei jūsų Git hostingo paslauga ją palaiko ir jūsų organizacija tai leidžia. Perjungimas nuo HTTPS nuotolinio serverio prie SSH nuotolinio serverio visiškai išvengia HTTPS sertifikatų grandinės, tačiau tai neištaiso pradinės TLS pasitikėjimo problemos. SSH turi savo hosto rakto patikrą ir kredencialų valdymo modelį.

Naudokite SSH, nes jis atitinka jūsų autentifikavimo ir diegimo dizainą, o ne vien tam, kad paslėptumėte sertifikato konfigūracijos klaidą, su kuria kitos HTTPS priemonės toliau susidurs.

Dažnos klaidos, kurių reikia vengti

• SSL patikros išjungimas globaliai. Tai pašalina serverio sertifikato patikrą būsimiems Git HTTPS ryšiams.
• Pasitikėjimas lapo (leaf) sertifikatu vietoj išdavėjo CA. Lapo sertifikatai baigia galioti ir keičiasi; pasitikėjimas turėtų būti įtvirtintas patvirtintoje CA grandinėje.
• Git supakuoto CA failo redagavimas rankiniu būdu jį dokumentuojant. Atnaujinimas gali pakeisti failą, o pakeitimas gali būti neįmanomas pakartoti komandos nariams ar CI.
• Prielaida, kad naršyklės sėkmė įrodo, jog Git turi tą patį pasitikėjimo šaltinį. Git gali naudoti OpenSSL ir atskirą PEM paketą, o naršyklė – OS saugyklą.
• http.proxySSLCAInfo naudojimas netinkamam ryšiui. Tas nustatymas skirtas HTTPS tarpiniam serveriui patikrinti, o ne bendram kilmės serverio CA konfigūracijos pakaitalui.
• Kiekvieno kūrėjo darbo stoties taisymas, kai Git serveris siunčia nepilną grandinę. Sutvarkykite serverį, kai jį kontroliuojate.

Išvada

Git klaida SSL certificate problem: unable to get local issuer certificate yra pasitikėjimo grandinės problema, o ne autentifikavimo rakto problema, ir tai nėra tai, ką įprastai reikėtų spręsti išjungiant sertifikato patikrą. Sužinokite, ar Git naudoja OpenSSL, Schannel, custom CA paketą ar HTTPS tarpinį serverį; tada įdėkite patvirtintą išdavėjo CA į pasitikėjimo šaltinį, kurį Git iš tikrųjų naudoja.

Windows sistemoje Schannel yra praktiškas pasirinkimas, kai įmonės CA jau valdoma Windows sertifikatų saugykloje. CI, konteineriuose ar aplinkose, kuriose reikia kartojamo failais pagrįsto pasitikėjimo, http.sslCAInfo dažnai yra aiškesnis. O kai keli klientai nepavyksta prisijungti prie vieno savarankiškai valdomo serviso, sutvarkykite serverio sertifikatų grandinę, o ne platinkite nesaugius apėjimus.