Kako riješiti problem sa SSL certifikatom: Nemoguće dobiti lokalni certifikat izdavatelja u Gitu

Ne postoji značajna promjena u 2026. godini koja bi stari zaobilazni način "isključi SSL verifikaciju" pretvorila u dobro rješenje. Trenutna Git dokumentacija i dalje zadano postavlja http.sslVerify na true, a Git i dalje podržava i povjerenje temeljeno na datotekama CA i odabrive TLS pozadine poput OpenSSLa i Schannela. Trajno rješenje je učiniti da Git vjeruje ispravnom certifikacijskom tijelu ili popraviti nepotpuni lanac certifikata poslužitelja, a ne onemogućiti verifikaciju.

Greška SSL certificate problem: unable to get local issuer certificate znači da TLS biblioteka koju koristi Git nije mogla izgraditi pouzdan lanac certifikata od certifikata poslužitelja do certifikacijskog tijela kojem vjeruje. To se može dogoditi jer lokalnoj pohrani CA nedostaje izdavateljski CA, korporativni HTTPS inspekcijski proxy ponovno potpisuje promet s internim CA, Git čita pogrešan CA paket ili samoupravljani Git poslužitelj ne prikazuje potrebne posredničke certifikate.

Tipičan neuspjeh Git HTTPS-a: udaljena lokacija je dostupna, ali verifikacija lanca certifikata ne može pronaći pouzdanog izdavatelja.

Počnite s najsigurnijim odgovorom

Koristite ovaj redoslijed:

1. Potvrdite koje su Git SSL postavke i TLS pozadina aktivne.
2. Odlučite pripada li nedostajuće povjerenje pohrani povjerenja operativnog sustava ili Git CA paketu.
3. Ako mnogo klijenata ne uspijeva protiv istog samoupravljanog poslužitelja, popravite lanac certifikata poslužitelja umjesto da zakrpate svakog klijenta.
4. Ponovno testirajte s omogućenom SSL verifikacijom i uklonite bilo koju privremenu ili naslijeđenu konfiguraciju za zaobilaženje.

Trenutna Git git-config dokumentacija definira http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend i ponašanje specifično za Schannel koje se koristi na Windowsima. Zadano stanje za verifikaciju certifikata ostaje omogućeno.

Pouzdani popravak je uspostavljanje valjanog lanca povjerenja, a ne suzbijanje provjere certifikata.

Korak 1: saznajte što Git zapravo koristi

Prije instaliranja certifikata ili uređivanja konfiguracije, pregledajte vrijednosti i odakle su došle:

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

Ako naredba ne ispisuje ništa, ta opcija možda jednostavno koristi zadano stanje Gita ili libcurla. --show-origin je važan jer vrijednost može doći iz sustavne, globalne, lokalne repozitorijalne ili uključene konfiguracijske datoteke. Ispravljanje pogrešne razine može ostaviti efektivnu postavku nepromijenjenom.

Također provjerite udaljenu lokaciju s kojom zapravo komunicirate:

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

Ako Git ne uspijeva samo za jednu korporativnu ili privatnu host adresu, dok javne HTTPS stranice rade, problem je vjerojatno specifičan za host ili konfiguracija poslužitelja. Ako Git ne uspijeva za mnogo nepovezanih HTTPS udaljenih lokacija, prvo pregledajte lokalnu Git instalaciju, putanju CA paketa, proxy i konfiguraciju povjerenja sustava.

Nemojte ovo učiniti svojom prvom naredbom

git config --global http.sslVerify false

To onemogućuje verifikaciju certifikata poslužitelja za Git HTTPS zahtjeve na globalnoj razini korisnika. Može učiniti da greška nestane, ali istovremeno uklanja zaštitu koja provjerava komunicirate li s namjerenim poslužiteljem. Git dokumentira da je verifikacija zadano omogućena s razlogom.

Ako otkrijete staru globalnu zaobilaženje koja više nije potrebna, vratite zadano ponašanje:

git config --global --unset http.sslVerify

ili eksplicitno postavite:

git config --global http.sslVerify true

Korak 2: na Windowsima, odaberite između pohrane certifikata Windowsa i PEM CA paketa

Windows developeri često nailaze na ovu grešku kada preglednik radi, ali Git ne. To ne znači nužno da je poslužitelj pokvaren. Preglednik možda vjeruje korporativnom korijenskom certifikatu instaliranom u Windowsima, dok Git konfiguriran s OpenSSL-podobnom pozadinom možda koristi zasebni CA paket.

Git podržava vrijednosti http.sslBackend poput openssl i schannel. Službena TLS dokumentacija o certifikatima curla objašnjava da Schannel zadano koristi nativnu pohranu CA sustava Windows.

Opcija A: koristite Schannel kada Windowsi već imaju pouzdani korporativni CA

git config --global http.sslBackend schannel

Ovo je često dobro rješenje za Windows radne stanice kojima upravlja organizacija koja distribuirira pouzdane korijenske i posredničke certifikate putem Windows politike. Omogućuje Gitu oslanjanje na isti sustav povjerenja certifikata Windowsa koji mogu koristiti i druge nativne aplikacije.

Postoji kompromis: promjena pozadine mijenja Gitovo HTTPS ponašanje s certifikatima globalno za tog korisnika. Ako vaša organizacija namjerno upravlja namjenskim PEM paketom za Git ili automatizaciju, ostajanje uz OpenSSL može biti predvidljivije.

Trenutna Git dokumentacija također napominje suptilno ponašanje Schannela: kada se Schannel odabere putem http.sslBackend, Git obično izbjegava primjenu http.sslCAInfo jer isporučeni CA paket može nadjačati pohranu certifikata Windowsa. Postavka http.schannelUseSSLCAInfo postoji za okruženja koja namjerno žele to ponašanje.

Opcija B: zadržite OpenSSL i usmjerite Git na odobreni CA paket

Ako vam organizacija daje PEM paket koji sadrži potrebne interne korijenske i posredničke certifikate, konfigurirajte Git da koristi tu datoteku:

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

Git definira http.sslCAInfo kao datoteku koja sadrži certifikate korištene za verifikaciju vršnjaka. Također možete ograničiti HTTP konfiguraciju na odgovarajući URL umjesto da mijenjate svaku HTTPS destinaciju. Gitova http.<url>.* konfiguracija podržava specifično podudaranje URL-a po shemi, hostu, portu i putanji.

Na primjer:

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

Ova uža postavka korisna je kada samo interni Git poslužitelj treba privatni CA, dok bi javni Git hostovi trebali nastaviti koristiti normalni paket povjerenja.

Korak 3: na macOSu, Linuxu, CI-u i kontejnerima, popravite izvor CA koji proces zapravo koristi

Princip je isti izvan Windowsa: Git proces mora imati pristup CA certifikatu koji je izdao certifikat poslužitelja ili proxyja. Točne naredbe za pohranu povjerenja sustava razlikuju se po operativnom sustavu i Linux distribuciji, pa koristite službeni mehanizam za upravljanje certifikatima platforme ili eksplicitni Git CA paket koji je dostavio vaš administrator.

Git mora moći povezati prikazani certifikat poslužitelja kroz njegove posredničke izdavatelje do lokalno pouzdanog CA.

Za kontrolirani CI posao ili kontejner gdje ne želite mijenjati globalnu pohranu povjerenja hosta, CA paket može biti eksplicitan:

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

ili, za pojedinačni proces, Git također prepoznaje varijablu okruženja GIT_SSL_CAINFO. Trenutna Git dokumentacija navodi da ova varijabla okruženja može nadjačati http.sslCAInfo.

Nemojte kopirati nasumičnu cacert.pem datoteku s foruma. Ako je nedostajući certifikat korporativni CA, nabavite ga od svog IT ili PKI tima. Ako je udaljena lokacija javna usluga i vaš je CA paket jednostavno zastario, ažurirajte svoj operativni sustav, Git distribuciju, osnovnu sliku kontejnera ili paket pouzdanih CA putem normalnog kanala za ažuriranje.

Korporativna TLS inspekcija je poseban slučaj

Neki korporativni proxyji inspiciraju HTTPS i prikazuju zamjenski certifikat potpisan internim korporativnim CA. U toj situaciji, preglednik može uspjeti jer je korporativni CA instaliran u pohrani povjerenja OS-a, dok Gitov zasebni CA paket ne sadrži taj certifikat.

Ispravno rješenje je vjerovati CA organizacije putem odgovarajuće pohrane povjerenja ili Git paketa. Nemojte izvoziti trenutni listni certifikat i trajno mu vjerovati kao zamjeni za izdavateljski korporativni CA.

Također razlikujte dva zasebna slučaja proxyja:

• TLS presretanje veze s Git poslužiteljem: korporativni CA koji potpisuje zamjenski certifikat poslužitelja mora biti pouzdan putem normalnog puta certifikata poslužitelja, poput Windows Schannela ili http.sslCAInfo.
• HTTPS proxy čija vlastita proxy veza koristi TLS: Git pruža http.proxySSLCAInfo specifično za CA paket korišten za verifikaciju te HTTPS proxy veze.

Git dokumentira http.proxy i http.proxySSLCAInfo zasebno, pa koristite postavku koja odgovara vezi koja ne uspijeva.

Korak 4: ako je lanac poslužitelja nepotpun, popravite poslužitelj kada možete

Ako mnogo korisnika ili svježih strojeva ne uspijeva protiv istog samoupravljanog Git poslužitelja, problem može biti na strani poslužitelja, a ne skup pokvarenih klijenata. Poslužitelj bi trebao prikazati lanac certifikata potreban klijentima da povežu listni certifikat s pouzdanim izdavateljem.

Kada mnogo klijenata ne uspijeva protiv jednog privatnog Git hosta, provjerite lanac poslužitelja i putanju proxyja prije distribuiranja zaobilaznih rješenja na strani klijenta.

Službena dokumentacija za rješavanje problema sa SSL-om GitLaba specifično opisuje unable to get local issuer certificate kao slučaj u kojem klijent ne može dobiti potrebnog izdavatelja i preporučuje ili vjerovanje odgovarajućem CA na klijentu ili ispravljanje poslužitelja da prikaže potpuni lanac certifikata.

Ako upravljate poslužiteljem, popravite konfigurirani certifikat punog lanca i ponovno testirajte s čistog klijenta. To je poželjnije nego tražiti od svakog developera da doda ad hoc iznimke.

Provjerite popravak bez slabljenja TLS-a

Nakon što je konfiguracija povjerenja ispravljena, ponovite istu Git operaciju:

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

Ako to uspije, pokušajte ponovno izvornu clone, fetch, pull ili push operaciju.

Zatim pregledajte konačnu sigurnosno relevantnu konfiguraciju:

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

Očekivano stanje je da verifikacija certifikata ostane omogućena i da Git može izgraditi valjani lanac kroz namjereni izvor povjerenja.

Koje rješenje odgovara vašoj situaciji?

Što s prebacivanjem Git udaljene lokacije na SSH?

SSH može biti valjana alternativna transportna metoda ako vaša usluga hostinga Git-a to podržava i vaša organizacija to dopušta. Promjena s HTTPS udaljene lokacije na SSH udaljenu lokaciju izbjegava cijeli lanac certifikata HTTPS-a, ali ne popravlja izvorni problem povjerenja TLS-a. SSH ima svoj vlastiti model verifikacije host ključeva i upravljanja vjerodajnicama.

Koristite SSH jer odgovara vašem dizajnu autentifikacije i implementacije, a ne samo da sakrijete grešku u konfiguraciji certifikata s kojom će se drugi HTTPS alati i dalje susretati.

Uobičajene greške koje treba izbjegavati

• Onemogućavanje SSL verifikacije globalno. To uklanja verifikaciju certifikata poslužitelja za buduće Git HTTPS veze.
• Vjerovanje listnom certifikatu umjesto izdavateljskom CA. Listni certifikati istječu i rotiraju se; povjerenje bi obično trebalo biti usidreno u odobrenom lancu CA.
• Ručno uređivanje Gitove isporučene CA datoteke bez dokumentiranja. Nadogradnja može zamijeniti datoteku, a promjena može biti nemoguća za reproduciranje od strane kolega ili CI-a.
• Pretpostavljanje da uspjeh preglednika dokazuje da Git ima isti izvor povjerenja. Git može koristiti OpenSSL i zasebni PEM paket, dok preglednik koristi pohranu OS-a.
• Korištenje http.proxySSLCAInfo za pogrešnu vezu. Ta postavka je za verifikaciju HTTPS proxyja, a ne opću zamjenu za konfiguraciju CA poslužitelja izvora.
• Zakrpavanje svake developerske radne stanice kada Git poslužitelj šalje nepotpun lanac. Popravite poslužitelj kada ga kontrolirate.

Zaključak

Git greška SSL certificate problem: unable to get local issuer certificate problem je lanca povjerenja, a ne problem s tokenom za autentifikaciju i nešto što se obično ne bi trebalo rješavati isključivanjem verifikacije certifikata. Saznajte koristi li Git OpenSSL, Schannel, prilagođeni CA paket ili HTTPS proxy; zatim postavite odobreni izdavateljski CA u izvor povjerenja koji Git zapravo koristi.

Na Windowsima, Schannel je praktična opcija kada je korporativni CA već upravljan u pohrani certifikata Windowsa. U CI-u, kontejnerima ili okruženjima koja zahtijevaju ponovljivo povjerenje temeljeno na datotekama, http.sslCAInfo je često jasniji. A kada mnogo klijenata ne uspijeva protiv jedne samoupravljane usluge, popravite lanac certifikata poslužitelja umjesto distribuiranja nesigurnih zaobilaženja.