Hvernig á að laga SSL-vottorðavandamál: Get ekki fengið staðvært útgefandavottorð í Git

Það er engin marktæk breyting árið 2026 sem gerir gömlu „slökktu á SSL-staðfestingu“ lausnina að góðri lagfæringu. Núverandi Git-skjöl stilla enn http.sslVerify sjálfgefið á true, og Git styður enn bæði skrábyggt CA-traust og valanleg TLS-bakenda eins og OpenSSL og Schannel. Varanlega lausnin er að fá Git til að treysta rétta vottorðsvald (certificate authority) eða að laga ófullkomna vottorðakeðju þjónsins – ekki að slökkva á staðfestingu.

Villan SSL certificate problem: unable to get local issuer certificate þýðir að TLS-bókasafnið sem Git notar gat ekki byggt upp traustavottorðakeðju frá þjónsvottorðinu upp í vottorðsvald sem það treystir. Það getur gerst vegna þess að staðvært CA-geymslurými vantar útgefandann, fyrirtækis HTTPS-eftirlitsmiðlari er að endurskrifa umferð með innri CA, Git er að lesa rangt CA-bundal, eða sjálfsstýrður Git-þjónn er ekki að birta nauðsynleg millivottorð (intermediate certificates).

Dæmigerð Git HTTPS-mistök: fjarlægur þjónn er náð en vottorðakeðjustaðfesting finnur ekki traustan útgefanda.

Byrjaðu með öruggustu svarið

Notaðu þessa röð:

1. Staðfestu hvaða Git SSL-stillingar og TLS-bakendi eru virk.
2. Ákvarðaðu hvort vantið traust tilheyri traustageymslu stjórnkerfisins eða Git CA-bundali.
3. Ef mörg viðtæki mistakast gegn sama sjálfsstýrða þjóninum, lagaðu vottorðakeðju þjónsins í stað þess að lappa upp á hvert viðtæki.
4. Endurprófaðu með SSL-staðfestingu virka og fjarlægðu tímabundnar eða eldri umgengnisstillingar.

Núverandi git-config skjöl skilgreina http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend og Schannel-sérstaka hegðun sem notuð er á Windows. Sjálfgefið fyrir vottorðastaðfestingu er enn virkt.

Áreiðanlega lagfæringin er að endurheimta gilda traustakeðju frekar en að þagga niður í vottorðaprófuninni.

Skref 1: Finndu út hvað Git er í raun að nota

Áður en þú setur upp vottorð eða breytir stillingum, skoðaðu gildin og hvaðan þau komu:

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

Ef skipanin prentar ekkert, gæti valkosturinn einfaldlega verið að nota sjálfgefna stillingu Git eða libcurl. --show-origin skiptir máli vegna þess að gildi getur komið frá kerfis-, almennum, staðbundnum repository- eða innfelldum stillingaskrám. Að laga rangt stig getur skilið virku stillinguna óbreytta.

Skoðaðu einnig fjarlægðina sem þú ert í raun að tengjast:

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

Ef Git mistakast aðeins fyrir einn fyrirtækis- eða einkavæddan hýsilþjón en opinberar HTTPS-síður virka, er vandamálið líklega hýsilþjónssértækt traust eða þjónastilling. Ef Git mistakast fyrir mörg óskyld HTTPS-fjarlægð, skoðaðu staðbundna Git-uppsetningu, CA-bundal-slóð, miðlara og kerfistrauststillingu fyrst.

Ekki gera þetta að fyrstu skipuninni þinni

git config --global http.sslVerify false

Það slökkvir á þjónsvottorðastaðfestingu fyrir Git HTTPS-beiðnir á almennum notendastigi. Það getur látið villuna hverfa en fjarlægir einnig verndina sem staðfestir að þú sért að samskiptast við æskilegan þjón. Git skjalfest að staðfesting sé virk sjálfgefin á ástæðu.

Ef þú uppgötvar gamalt almennt umgengnisbrot sem er ekki lengur nauðsynlegt, endurheimtu sjálfgefna hegðun:

git config --global --unset http.sslVerify

eða stilltu sérstaklega:

git config --global http.sslVerify true

Skref 2: Á Windows, veldu á milli Windows vottorðageymslu og PEM CA-bundals

Windows forritarar rekast oft á þessa villu þegar vafri virkar en Git gerir það ekki. Það þýðir ekki endilega að þjóninn sé bilaður. Vafri gæti treyst fyrirtækis-rótvottorði sem er uppsett í Windows, en Git sem er stillt með OpenSSL-stíls bakenda gæti verið að nota sérstakan CA-bundal.

Git styður http.sslBackend gildi eins og openssl og schannel. Opinber TLS vottorðaskjöl curl útskýra að Schannel noti Windows innbyggða CA-geymsluna sjálfgefið.

Valkostur A: Notaðu Schannel þegar Windows hefur þegar traust fyrirtækis CA

git config --global http.sslBackend schannel

Þetta passar oft vel fyrir Windows-einangraðar vinnustöðvar sem stjórnað er af stofnun sem dreifir traustum rót- og millivottorðum í gegnum Windows stefnu. Það leyfir Git að reiða sig á sama Windows vottorðstraustakerfi og önnur innbyggð forrit geta notað.

Það er ákvörðun: að breyta bakendanum breytir HTTPS vottorðahégðun Git almennt fyrir þann notanda. Ef stofnunin þín stjórnar meðvitað sérstökum PEM-bundali fyrir Git eða sjálfvirkni, gæti það verið spáanlegra að halda OpenSSL.

Núverandi Git-skjöl taka einnig fram smáatriði í Schannel hegðun: þegar Schannel er valið í gegnum http.sslBackend, forðast Git venjulega að beita http.sslCAInfo vegna þess að veittur CA-bundal gæti yfirtekið Windows vottorðageymsluna. http.schannelUseSSLCAInfo stillingin er til staðar fyrir umhverfi sem vilja meðvitað þessa hegðun.

Valkostur B: Haltu OpenSSL og bendu Git á samþykktan CA-bundal

Ef stofnunin þín gefur þér PEM-bundal sem inniheldur nauðsynleg innri rót- og millivottorð, stilltu Git til að nota þá skrá:

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

Git skilgreinir http.sslCAInfo sem skrána sem inniheldur vottorð sem notuð eru til að staðfesta samstarfsaðila (peer). Þú getur einnig takmarkað HTTP-stillingar við samsvarandi URL í stað þess að breyta öllum HTTPS-áfangastaðum. http.<url>.* stilling Git styður URL-sértæka samsvaran með skema, hýsilþjón, port og slóð.

Til dæmis:

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

Þessi þrengri stilling er gagnleg þegar aðeins innri Git-þjónn þarf einkavæddan CA en opinberir Git-hýslar ættu að halda áfram að nota venjulega traustabundal.

Skref 3: Á macOS, Linux, CI og í ílátum, lagaðu CA-upprunann sem ferlið notar í raun

Prinsippið er það sama utan Windows: Git-ferlið verður að hafa aðgang að CA-vottorðinu sem gaf út þjón- eða miðlaravottorðið. Nákvæmar skipanir fyrir kerfisstraustageymslu eru mismunandi eftir stjórnkerfi og Linux-dreifingu, svo notaðu opinbera vottorðastjórnunarhætti pallins eða sérstakan Git CA-bundal sem veittur er af kerfisstjóranum þínum.

Git verður að geta tengt birta þjónsvottorðið í gegnum millivottorð útgefenda við staðbundið traust CA.

Fyrir stjórnað CI-verkefni eða ílát þar sem þú vilt ekki breyta almennri traustageymslu hýsilvélarinnar, getur CA-bundal verið sérstakur:

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

eða, fyrir einstakt ferli, viðurkennir Git einnig GIT_SSL_CAINFO umhverfisbreytuna. Núverandi Git-skjöl segja að þessi umhverfisbreyta geti yfirtekið http.sslCAInfo.

Ekki afrita handahófskennda cacert.pem skrá frá spjallborði. Ef vantið vottorð er fyrirtækis CA, fáðu það frá IT- eða PKI-teyminu þínu. Ef fjarlægðin er opinber þjónusta og CA-bundalinn þinn er einfaldlega úreltur, uppfærðu stjórnkerfið, Git-dreifinguna, grunnímynd ílátsins eða traust CA-pakkann í gegnum venjulega uppfærslurás.

Fyrirtækis TLS-eftirlit er sérstakt tilfelli

Sumir fyrirtækis miðlarar skoða HTTPS og birta staðgengilsvottorð sem undirritað er af innri fyrirtækis CA. Í því tilviki gæti vafri tekist vegna þess að fyrirtækis CA er uppsett í OS traustageymslunni, en sérstakur CA-bundal Git inniheldur hann ekki.

Rétta lagfæringin er að treysta CA stofnunarinnar í gegnum viðeigandi traustageymslu eða Git-bundal. Ekki flytja út núverandi blaðvottorð (leaf certificate) og treysta því varanlega sem staðgengli fyrir útgefanda fyrirtækis CA.

Aðgreindu einnig tvö aðskilin miðlaratilfelli:

• TLS-undirhöfðun á Git-þjónatengingunni: Fyrirtækis CA sem undirritar staðgengil þjónsvottorðsins verður að vera treyst í gegnum venjulega þjónsvottorðaleið, eins og Windows Schannel eða http.sslCAInfo.
• HTTPS miðlari sem sjálfur tengingin hans notar TLS: Git veitir http.proxySSLCAInfo sérstaklega fyrir CA-bundalinn sem notaður er til að staðfesta þá HTTPS miðlaratengingu.

Git skjalfest http.proxy og http.proxySSLCAInfo aðskilið, svo notaðu stillinguna sem passar við tenginguna sem mistakast.

Skref 4: Ef þjónakeðjan er ófullkomin, lagaðu þjóninn þegar þú getur

Ef margir notendur eða nýjar vélar mistakast gegn sama sjálfsstýrða Git-þjóninum, gæti vandamálið verið þjónshliðar frekar en safn bilaðra viðtækja. Þjónninn ætti að birta vottorðakeðjuna sem krafist er til að viðtæki geti tengt blaðvottorðið við traustan útgefanda.

Þegar mörg viðtæki mistakast gegn einum einkavæddum Git-hýslar, athugaðu þjónakeðjuna og miðlaraleiðina áður en þú dreifir viðtækislausnum.

Opinber SSL villuleitar skjöl GitLab lýsa sérstaklega unable to get local issuer certificate sem tilviki þar sem viðtækið getur ekki fengið nauðsynlegan útgefanda og mælir með annaðhvort að treysta viðeigandi CA á viðtækinu eða leiðrétta þjóninn til að birta fullkomna vottorðakeðju.

Ef þú stjórnar þjóninum, lagaðu stillta fullkeðju vottorðið og endurprófaðu frá hreinum viðtæki. Það er aðlaðandi frekar en að biðja hvern forritara um að bæta við handahófskenndum undantekningum.

Staðfestu lagfæringuna án þess að veika TLS

Eftir að traustastillingin er leiðrétt, endurtaktu sömu Git-aðgerð:

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

Ef það tekst, reyndu upprunalega clone, fetch, pull eða push.

Skoðaðu síðan lokastillingar öryggis:

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

Væntanlegt ástand er að vottorðastaðfesting haldist virk og Git geti byggt gilda keðju í gegnum æskilega traustauppruna.

Hvaða lagfæring passar við aðstæður þínar?

Hvað með að skipta Git fjarlægðinni yfir í SSH?

SSH getur verið gildur valkostur fyrir flutning ef Git hýsingarþjónustan þín styður það og stofnunin þín leyfir það. Að skipta úr HTTPS fjarlægð yfir í SSH fjarlægð forðast HTTPS vottorðakeðjuna alveg, en það lagar ekki upprunalega TLS traustavandamálið. SSH hefur sitt eigið hýsillyklastaðfestingar- og auðkennistjórnunarkerfi.

Notaðu SSH vegna þess að það passar við auðkenningar- og útfærsluhönnun þína – ekki eingöngu til að fela vottorðastillingavillu sem önnur HTTPS-verkfæri munu halda áfram að rekast á.

Algengar mistök sem forðast á

• Að slökkva á SSL-staðfestingu almennt. Þetta fjarlægir þjónsvottorðastaðfestingu fyrir framtíðar Git HTTPS tengingar.
• Að treysta blaðvottorðinu í stað útgefanda CA. Blaðvottorð renna út og skiptast; traust ætti venjulega að vera fest í samþykktu CA keðju.
• Að breyta Git innbyggðu CA skránni handvirkt án þess að skrá það. Uppfærsla getur skipt um skrána, og breytingin gæti verið ómöguleg fyrir teymisfélaga eða CI að endurtaka.
• Að gera ráð fyrir að vafra velgengni sanni að Git hafi sama traustauppruna. Git gæti notað OpenSSL og sérstakan PEM-bundal en vafri notar OS-geymsluna.
• Að nota http.proxySSLCAInfo fyrir rangt tengingu. Sú stilling er fyrir staðfestingu á HTTPS miðlara, ekki almennan staðgengil fyrir upprunaþjóns CA stillingu.
• Að lappa upp á hverja forritaravinnustöð þegar Git þjónninn er að senda ófullkomna keðju. Lagaðu þjóninn þegar þú hefur stjórn á honum.

Í stuttu máli

Git villan SSL certificate problem: unable to get local issuer certificate er traustakeðjuvandamál, ekki auðkennismerkjavandamál og ekki eitthvað sem ætti venjulega að leysa með því að slökkva á vottorðastaðfestingu. Finndu út hvort Git noti OpenSSL, Schannel, sérsniðinn CA-bundal eða HTTPS miðlara; staðsettu síðan samþykktan útgefanda CA í traustaupprunanum sem Git notar í raun.

Á Windows er Schannel praktískur valkostur þegar fyrirtækis CA er þegar stjórnað í Windows vottorðageymslunni. Í CI, ílátum eða umhverfum sem þurfa endurtekjanlegt skrábyggt traust, er http.sslCAInfo oft skýrara. Og þegar mörg viðtæki mistakast gegn einum sjálfsstýrðum þjóni, lagaðu vottorðakeðju þjónsins í stað þess að dreifa óöruggum umgengnisleiðum.