Jak opravit problém se SSL certifikátem: Nelze získat lokální certifikát vydavatele v Gitu

Neexistuje žádná smysluplná změna v roce 2026, která by z starého workaroundu „vypnout ověřování SSL“ učinila dobré řešení. Současná dokumentace Gitu stále nastavuje http.sslVerify ve výchozím nastavení na true a Git stále podporuje důvěru CA založenou na souborech i volitelné TLS backendy, jako jsou OpenSSL a Schannel. Trvalé řešení spočívá v tom, že Gitu umožníte důvěřovat správné certifikační autoritě, nebo v opravě neúplného řetězce certifikátů serveru – nikoli ve vypnutí ověřování.

Chyba SSL certificate problem: unable to get local issuer certificate znamená, že knihovna TLS používaná Gitem nedokázala sestavit důvěryhodný řetězec certifikátů od certifikátu serveru ke certifikační autoritě, které důvěřuje. K tomu může dojít, protože lokální úložiště CA neobsahuje vydávající CA, firemní proxy pro inspekci HTTPS přepisuje provoz s interní CA, Git čte nesprávný svazek CA, nebo samosprávný server Git nepředkládá požadované mezilehlé certifikáty.

Typické selhání Git HTTPS: vzdálený server je dosažitelný, ale ověřování řetězce certifikátů nemůže najít důvěryhodného vydavatele.

Začněte nejbezpečnější odpovědí

Použijte toto pořadí:

1. Ověřte, která nastavení SSL Gitu a TLS backend jsou aktivní.
2. Rozhodněte, zda chybějící důvěra patří do úložiště důvěry operačního systému, nebo do svazku CA Gitu.
3. Pokud mnoho klientů selhává proti stejnému samostatně hostovanému serveru, opravte řetězec certifikátů serveru místo patchování každého klienta.
4. Znovu otestujte s povoleným ověřováním SSL a odstraňte jakékoli dočasné nebo zastaralé konfigurace pro obcházení.

Aktuální dokumentace git-config definuje http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend a specifické chování Schannel používané ve Windows. Výchozí nastavení pro ověřování certifikátů zůstává povolené.

Spolehlivá oprava spočívá v obnovení platného řetězce důvěry, nikoli v potlačení kontroly certifikátu.

Krok 1: Zjistěte, co Git skutečně používá

Než budete instalovat certifikáty nebo upravovat konfiguraci, zkontrolujte hodnoty a jejich původ:

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

Pokud příkaz nic nevypíše, tato možnost může jednoduše používat výchozí nastavení Gitu nebo libcurl. --show-origin je důležité, protože hodnota může pocházet ze systémových, globálních, lokálních repozitářových nebo zahrnutých konfiguračních souborů. Oprava nesprávné úrovně může nechat efektivní nastavení nezměněné.

Zkontrolujte také vzdálený repozitář, ke kterému se skutečně připojujete:

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

Pokud Git selhává pouze pro jeden firemní nebo soukromý hostitel, zatímco veřejné HTTPS stránky fungují, problém je pravděpodobně specifický pro hostitele (důvěra nebo konfigurace serveru). Pokud Git selhává pro mnoho nesouvisejících vzdálených repozitářů HTTPS, nejprve zkontrolujte lokální instalaci Gitu, cestu ke svazku CA, proxy a konfiguraci důvěry systému.

Nepoužívejte tento příkaz jako první

git config --global http.sslVerify false

Toto vypne ověřování certifikátů serveru pro požadavky Git HTTPS na globální uživatelské úrovni. Může způsobit, že chyba zmizí, ale zároveň odstraní ochranu, která ověřuje, že komunikujete se zamýšleným serverem. Git zdokumentoval, že ověřování je ve výchozím nastavení povoleno z dobrého důvodu.

Pokud objevíte staré globální obcházení, které již není vyžadováno, obnovte výchozí chování:

git config --global --unset http.sslVerify

nebo explicitně nastavte:

git config --global http.sslVerify true

Krok 2: Ve Windows si vyberte mezi úložištěm certifikátů Windows a PEM svazkem CA

Vývojáři ve Windows se s touto chybou často setkávají, když prohlížeč funguje, ale Git ne. To nutně neznamená, že je server rozbitý. Prohlížeč může důvěřovat firemnímu kořenovému certifikátu nainstalovanému ve Windows, zatímco Git nakonfigurovaný s backendem typu OpenSSL může používat samostatný svazek CA.

Git podporuje hodnoty http.sslBackend jako openssl a schannel. Oficiální dokumentace certifikátů TLS curl vysvětluje, že Schannel ve výchozím nastavení používá nativní úložiště CA Windows.

Možnost A: Použijte Schannel, když Windows již mají důvěryhodnou firemní CA

git config --global http.sslBackend schannel

To je často dobrá volba pro pracovní stanice pouze ve Windows spravované organizací, která distribuuje důvěryhodné kořenové a mezilehlé certifikáty prostřednictvím politik Windows. Umožňuje Gitu spoléhat na stejný systém důvěry certifikátů Windows, který mohou používat jiné nativní aplikace.

Existuje zde kompromis: změna backendu globálně změní chování HTTPS certifikátů Gitu pro tohoto uživatele. Pokud vaše organizace záměrně spravuje vyhrazený PEM svazek pro Git nebo automatizaci, zůstání u OpenSSL může být předvídatelnější.

Aktuální dokumentace Gitu také uvádí jemné chování Schannel: když je Schannel vybrán prostřednictvím http.sslBackend, Git obvykle neaplikuje http.sslCAInfo, protože dodaný svazek CA by mohl přepsat úložiště certifikátů Windows. Nastavení http.schannelUseSSLCAInfo existuje pro prostředí, která toto chování záměrně chtějí.

Možnost B: Ponechte OpenSSL a nasměrujte Git na schválený svazek CA

Pokud vám vaše organizace poskytne PEM svazek obsahující požadované interní kořenové a mezilehlé certifikáty, nakonfigurujte Git, aby používal tento soubor:

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

Git definuje http.sslCAInfo jako soubor obsahující certifikáty používané k ověření protistrany. Můžete také omezit konfiguraci HTTP na odpovídající URL místo změny každého cíle HTTPS. Konfigurace Gitu http.<url>.* podporuje specifické párování URL podle schématu, hostitele, portu a cesty.

Například:

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

Toto užší nastavení je užitečné, když pouze interní server Git potřebuje soukromou CA, zatímco veřejní hostitelé Gitu by měli pokračovat v používání normálního svazku důvěry.

Krok 3: Na macOS, Linuxu, CI a v kontejnerech opravte zdroj CA, který proces skutečně používá

Princip je mimo Windows stejný: proces Git musí mít přístup k certifikátu CA, který vydal certifikát serveru nebo proxy. Přesné příkazy pro úložiště důvěry systému se liší podle operačního systému a distribuce Linuxu, takže používejte oficiální mechanismus správy certifikátů platformy nebo explicitní svazek CA Gitu dodaný správcem.

Git musí být schopen propojit předložený certifikát serveru přes jeho mezilehlé vydavatele s lokálně důvěryhodnou CA.

Pro kontrolovanou úlohu CI nebo kontejner, kde nechcete upravovat globální úložiště důvěry hostitele, může být svazek CA explicitní:

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

nebo pro jednotlivý proces Git také rozpoznává proměnnou prostředí GIT_SSL_CAINFO. Aktuální dokumentace Gitu uvádí, že tato proměnná prostředí může přepsat http.sslCAInfo.

Nekopírujte náhodný soubor cacert.pem z fóra. Pokud chybějícím certifikátem je firemní CA, získejte ji od týmu IT nebo PKI. Pokud je vzdálený repozitář veřejná služba a váš svazek CA je jednoduše zastaralý, aktualizujte operační systém, distribuci Gitu, základní obraz kontejneru nebo balíček důvěryhodných CA prostřednictvím běžného kanálu aktualizací.

Firemní inspekce TLS je speciální případ

>Některé enterprise proxy inspekují HTTPS a předkládají náhradní certifikát podepsaný interní firemní CA. V takové situaci může prohlížeč uspět, protože firemní CA je nainstalována v úložišti důvěry OS, zatímco samostatný svazek CA Gitu ji neobsahuje.

Správná oprava spočívá v důvěře CA organizace prostřednictvím příslušného úložiště důvěry nebo svazku Gitu. Neexportujte aktuální listový certifikát a trvale mu nedůvěřujte jako náhradě za vydávající firemní CA.

>Rozlišujte také dva samostatné případy proxy:

• Intercepce TLS spojení serveru Git: Firemní CA, která podepisuje náhradní certifikát serveru, musí být důvěryhodná prostřednictvím normální cesty certifikátu serveru, jako je Windows Schannel nebo http.sslCAInfo.
• HTTPS proxy, jejíž vlastní spojení proxy používá TLS: Git poskytuje http.proxySSLCAInfo specificky pro svazek CA používaný k ověření tohoto spojení HTTPS proxy.

Git dokumentuje http.proxy a http.proxySSLCAInfo odděleně, takže použijte nastavení, které odpovídá spojení, které selhává.

Krok 4: Pokud je řetězec serveru neúplný, opravte server, pokud můžete

Pokud mnoho uživatelů nebo nových strojů selhává proti stejnému samostatně hostovanému serveru Git, problém může být na straně serveru, nikoli sbírka rozbitých klientů. Server by měl předkládat řetězec certifikátů potřebný pro klienty k propojení listového certifikátu s důvěryhodným vydavatelem.

Když mnoho klientů selhává proti jednomu soukromému hostiteli Gitu, zkontrolujte řetězec serveru a cestu proxy před distribucí workaroundů na straně klienta.

Oficiální dokumentace řešení problémů se SSL GitLabu specificky popisuje unable to get local issuer certificate jako případ, kdy klient nemůže získat požadovaného vydavatele, a doporučuje buď důvěřovat příslušné CA na klientovi, nebo opravit server tak, aby předkládal kompletní řetězec certifikátů.

Pokud spravujete server, opravte nakonfigurovaný certifikát plného řetězce a znovu otestujte z čistého klienta. To je upřednostňováno před žádostí každému vývojáři, aby přidával ad hoc výjimky.

Ověřte opravu bez oslabení TLS

Po opravě konfigurace důvěry opakujte stejnou operaci Gitu:

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

Pokud to uspěje, zkuste znovu původní clone, fetch, pull nebo push.

Poté zkontrolujte konečnou konfiguraci související se zabezpečením:

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

Očekávaný stav je, že ověřování certifikátů zůstává povolené a Git dokáže sestavit platný řetězec prostřednictvím zamýšleného zdroje důvěry.

Která oprava odpovídá vaší situaci?

Situace	Nejlepší výchozí bod	Proč
Prohlížeč ve Windows funguje; Git selhává v firemní síti	Zkontrolujte, zda je firemní CA v úložišti důvěry Windows; zvažte Schannel	Prohlížeč a důvěra Windows mohou být již správné, zatímco Git OpenSSL používá jiný svazek
Firma poskytuje PEM svazek CA pro vývojářské nástroje	Použijte http.sslCAInfo, pokud je to praktické, preferujte specifické pro hostitele	Explicitní a reprodukovatelné pro Git, CI a kontejnery
Nový kontejner Linuxu selhává, ale pracovní stanice funguje	Nainstalujte/aktualizujte balíček CA nebo přidejte CA organizace do důvěry kontejneru/svazku Gitu	Kontejner má vlastní souborový systém a materiál důvěry
Pouze jedna samostatně hostovaná služba Git selhává pro mnoho uživatelů	Zkontrolujte a opravte řetězec certifikátů serveru	Oprava na straně serveru se vyhne patchům pro každého klienta
Sama HTTPS proxy má soukromý certifikát	Nakonfigurujte důvěryhodnou CA pro HTTPS proxy pomocí http.proxySSLCAInfo, pokud je to适用né	Ověřování TLS proxy je oddělené od ověřování původního serveru
Někdo navrhuje http.sslVerify=false	Nepoužívejte to jako trvalé řešení	Obchází ověřování certifikátů, které chrání spojení HTTPS

Co přepnutí vzdáleného repozitáře Gitu na SSH?

SSH může být platnou alternativní transportní vrstvou, pokud vaše služba hostingu Gitu to podporuje a vaše organizace to povoluje. Změna ze vzdáleného repozitáře HTTPS na vzdálený repozitář SSH zcela vyhne řetězci certifikátů HTTPS, ale neopraví původní problém s důvěrou TLS. SSH má svůj vlastní model ověřování hostitelských klíčů a správy přihlašovacích údajů.

Používejte SSH, protože odpovídá vašemu designu autentizace a nasazení – nikoli pouze k zakrytí chyby konfigurace certifikátu, kterou budou jiné nástroje HTTPS stále Encounterovat.

Běžné chyby, kterým se vyhnout

• Vypnutí ověřování SSL globálně. Toto odstraní ověřování certifikátů serveru pro budoucí spojení Git HTTPS.
• Důvěra listovému certifikátu místo vydávající CA. Listové certifikáty expirují a rotují; důvěra by měla být obvykle ukotvena v schváleném řetězci CA.
• Ruční úprava souboru CA zabaleného v Gitu bez zdokumentování. Aktualizace může nahradit soubor a změna může být nemožná pro spolužáky nebo CI k reprodukování.
• Předpoklad, že úspěch prohlížeče dokazuje, že Git má stejný zdroj důvěry. Git může používat OpenSSL a samostatný PEM svazek, zatímco prohlížeč používá úložiště OS.
• Použití http.proxySSLCAInfo pro nesprávné spojení. Toto nastavení je pro ověřování HTTPS proxy, nikoli pro obecnou náhradu konfigurace CA původního serveru.
• Patchování každé vývojářské pracovní stanice, když server Git posílá neúplný řetězec. Opravte server, pokud ho kontrolujete.

Závěr

Chyba Gitu SSL certificate problem: unable to get local issuer certificate je problém s řetězcem důvěry, nikoli problém s autentizačním tokenem a není to něco, co by mělo být obvykle řešeno vypnutím ověřování certifikátů. Zjistěte, zda Git používá OpenSSL, Schannel, vlastní svazek CA nebo HTTPS proxy; poté umístěte schválenou vydávající CA do zdroje důvěry, který Git skutečně používá.

Ve Windows je Schannel praktickou možností, když je firemní CA již spravována v úložišti certifikátů Windows. V CI, kontejnerech nebo prostředích, která potřebují reprodukovatelnou důvěru založenou na souborech, je http.sslCAInfo často jasnější. A když mnoho klientů selhává proti jedné samostatně hostované službě, opravte řetězec certifikátů serveru místo distribuce nezabezpečených obcházení.