Så här åtgärdar du SSL-certifikatproblemet: Unable to Get Local Issuer Certificate i Git

Det finns ingen meningsfull förändring 2026 som gör den gamla lösningen "stäng av SSL-verifiering" till en bra fix. Gits aktuella dokumentation sätter fortfarande http.sslVerify till true som standard, och Git stöder fortfarande både filbaserad CA-förtroendehantering och valbara TLS-bakgrunder som OpenSSL och Schannel. Den hållbara lösningen är att få Git att lita på rätt certifikatauktoritet eller att reparera en ofullständig servercertifikatkedja – inte att inaktivera verifieringen.

Felet SSL certificate problem: unable to get local issuer certificate innebär att TLS-biblioteket som används av Git inte kunde bygga en betrodd certifikatkedja från servercertifikatet till en certifikatauktoritet som det litar på. Det kan hända eftersom den lokala CA-lagringen saknar den utfärdande CA:n, en företagsproxy för HTTPS-inspektion signerar om trafiken med en intern CA, Git läser fel CA-bundel, eller en självhanterad Git-server inte presenterar de nödvändiga mellanliggande certifikaten.

Ett typiskt Git HTTPS-fel: fjärrservern kan nås, men certifikatkedjeverifieringen kan inte hitta en betrodd utfärdare.

Börja med det säkraste svaret

Använd denna ordning:

1. Bekräfta vilka Gits SSL-inställningar och TLS-bakgrund som är aktiva.
2. Beslut om det saknade förtroendet hör hemma i operativsystemets förtroendelagring eller i en Git CA-bundel.
3. Om många klienter misslyckas mot samma självhostade server, reparera serverns certifikatkedja istället för att lappa varje klient.
4. Testa om med SSL-verifiering aktiverad och ta bort tillfällig eller gammal kringgående konfiguration.

Gits aktuella git-config-dokumentation definierar http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend och det Schannel-specifika beteendet som används på Windows. Standardvärdet för certifikatverifiering förblir aktiverat.

Den pålitliga reparationen är att återställa en giltig förtroendekedja snarare än att undertrycka certifikatkontrollen.

Steg 1: Ta reda på vad Git faktiskt använder

Innan du installerar certifikat eller redigerar konfiguration, inspektera värdena och var de kom ifrån:

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

Om ett kommando inte skriver ut något kan det alternativet helt enkelt använda Git eller libcurl:s standardvärde. --show-origin är viktigt eftersom ett värde kan komma från system-, global-, lokal repository- eller inkluderade konfigurationsfiler. Att fixa fel nivå kan lämna den effektiva inställningen oförändrad.

Kontrollera också den fjärrserver du faktiskt kontaktar:

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

Om Git bara misslyckas för en företags- eller privat värd medan offentliga HTTPS-sajter fungerar, är problemet troligen värd-specifikt förtroende eller serverkonfiguration. Om Git misslyckas för många orelaterade HTTPS-fjärrservrar, inspektera den lokala Git-installationen, CA-bundelsökvägen, proxyn och systemets förtroendekonfiguration först.

Gör inte detta till ditt första kommando

git config --global http.sslVerify false

Detta inaktiverar verifiering av servercertifikat för Git HTTPS-förfrågningar på global användarnivå. Det kan få felet att försvinna samtidigt som det tar bort skyddet som verifierar att du kommunicerar med den avsedda servern. Git dokumenterar att verifiering är aktiverad som standard av en anledning.

Om du upptäcker en gammal global kringgång som inte längre krävs, återställ standardbeteendet:

git config --global --unset http.sslVerify

eller ange explicit:

git config --global http.sslVerify true

Steg 2: På Windows, välj mellan Windows certifikatlagring och en PEM CA-bundel

Windows-utvecklare stöter ofta på detta fel när en webbläsare fungerar men Git inte gör det. Det betyder inte nödvändigtvis att servern är trasig. Webbläsaren kan lita på ett företagsrotcertifikat installerat i Windows, medan Git konfigurerat med en OpenSSL-stil bakgrund kan använda en separat CA-bundel.

Git stöder http.sslBackend-värden som openssl och schannel. curl:s officiella dokumentation för TLS-certifikat förklarar att Schannel använder Windows inbyggda CA-lagring som standard.

Alternativ A: Använd Schannel när Windows redan har den betrodda företags-CA:n

git config --global http.sslBackend schannel

Detta passar ofta bra för Windows-arbetsstationer som hanteras av en organisation som distribuerar betrodda rot- och mellanliggande certifikat via Windows-policy. Det låter Git förlita sig på samma Windows-certifikatförtroendesystem som andra nativa applikationer kan använda.

Det finns en avvägning: att ändra bakgrunden ändrar Gits HTTPS-certifikatbeteende globalt för den användaren. Om din organisation medvetet hanterar en dedikerad PEM-bundel för Git eller automatisering, kan det vara mer förutsägbart att stanna kvar vid OpenSSL.

Gits aktuella dokumentation noterar också ett subtilt Schannel-beteende: när Schannel väljs via http.sslBackend, undviker Git normalt att tillämpa http.sslCAInfo eftersom en tillhandahållen CA-bundel kan åsidosätta Windows-certifikatlagringen. Inställningen http.schannelUseSSLCAInfo finns för miljöer som avsiktligt vill ha det beteendet.

Alternativ B: Behåll OpenSSL och peka Git till en godkänd CA-bundel

Om din organisation ger dig en PEM-bundel som innehåller de nödvändiga interna rot- och mellanliggande certifikaten, konfigurera Git att använda den filen:

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

Git definierar http.sslCAInfo som filen som innehåller certifikat som används för att verifiera peer. Du kan också begränsa HTTP-konfigurationen till en matchande URL istället för att ändra varje HTTPS-destination. Gits http.<url>.*-konfiguration stöder URL-specifik matchning efter schema, värd, port och sökväg.

Till exempel:

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

Denna smalare inställning är användbar när bara en intern Git-server behöver en privat CA medan offentliga Git-värdar bör fortsätta använda den normala förtroendebundeln.

Steg 3: På macOS, Linux, CI och containrar, fixa CA-källan som processen faktiskt använder

Principen är densamma utanför Windows: Git-processen måste ha tillgång till CA-certifikatet som utfärdade server- eller proxycertifikatet. De exakta kommandona för systemets förtroendelagring skiljer sig åt beroende på operativsystem och Linux-distribution, så använd plattformens officiella certifikathanteringsmekanism eller en explicit Git CA-bundel som tillhandahålls av din administratör.

Git måste kunna koppla det presenterade servercertifikatet genom dess mellanliggande utfärdare till en lokalt betrodd CA.

För en kontrollerad CI-jobb eller container där du inte vill modifiera värdens globala förtroendelagring, kan en CA-bundel vara explicit:

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

eller, för en enskild process, känner Git också igen miljövariabeln GIT_SSL_CAINFO. Gits aktuella dokumentation anger att denna miljövariabel kan åsidosätta http.sslCAInfo.

Kopiera inte en slumpmässig cacert.pem-fil från ett forum. Om det saknade certifikatet är en företags-CA, få den från ditt IT- eller PKI-team. Om fjärrservern är en offentlig tjänst och din CA-bundel helt enkelt är föråldrad, uppdatera ditt operativsystem, Git-distribution, containerbasbild eller betrodda CA-paket via dess normala uppdateringskanal.

Företags TLS-inspektion är ett specialfall

Vissa företagsproxyer inspekterar HTTPS och presenterar ett ersättningscertifikat signerat av en intern företags-CA. I den situationen kan webbläsaren lyckas eftersom företags-CA:n är installerad i OS-förtroendelagringen, medan Gits separata CA-bundel inte innehåller den.

Den korrekta lösningen är att lita på organisationens CA via lämplig förtroendelagring eller Git-bundel. Exportera inte det nuvarande lövcertifikatet och lita permanent på det som en ersättning för den utfärdande företags-CA:n.

Skilj också på två separata proxyfall:

• TLS-avlyssning av Git-serveranslutningen: Företags-CA:n som signerar ersättningsservercertifikatet måste vara betrodd via den normala servercertifikatvägen, såsom Windows Schannel eller http.sslCAInfo.
• En HTTPS-proxy vars egen proxyanslutning använder TLS: Git tillhandahåller http.proxySSLCAInfo specifikt för CA-bundeln som används för att verifiera den HTTPS-proxyanslutningen.

Git dokumenterar http.proxy och http.proxySSLCAInfo separat, så använd inställningen som matchar den anslutning som misslyckas.

Steg 4: Om serverkedjan är ofullständig, fixa servern när du kan

Om många användare eller nya maskiner misslyckas mot samma självhostade Git-server, kan problemet vara serversidigt snarare än en samling trasiga klienter. Servern bör presentera certifikatkedjan som krävs för att klienter ska kunna koppla lövcertifikatet till en betrodd utfärdare.

När många klienter misslyckas mot en privat Git-värd, kontrollera serverkedjan och proxyvägen innan du distribuerar klientbaserade kringgångar.

GitLabs officiella dokumentation för SSL-felsökning beskriver specifikt unable to get local issuer certificate som ett fall där klienten inte kan erhålla den nödvändiga utfärdaren och rekommenderar antingen att lita på lämplig CA på klienten eller korrigera servern för att presentera en komplett certifikatkedja.

Om du administrerar servern, reparera den konfigurerade fullständiga kedjans certifikat och testa om från en ren klient. Det är att föredra framför att be varje utvecklare att lägga till ad hoc-undantag.

Verifiera fixen utan att försvaga TLS

Efter att förtroendekonfigurationen är korrigerad, upprepa samma Git-operation:

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

Om det lyckas, försök igen med den ursprungliga clone-, fetch-, pull- eller push-operationen.

Inspektera sedan den slutliga säkerhetsrelaterade konfigurationen:

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

Det förväntade tillståndet är att certifikatverifiering förblir aktiverad och att Git kan bygga en giltig kedja via den avsedda förtroendekällan.

Vilken fix matchar din situation?

Vad händer om man byter Git-fjärrserver till SSH?

SSH kan vara ett giltigt alternativt transportprotokoll om din Git-hostingtjänst stöder det och din organisation tillåter det. Att byta från en HTTPS-fjärrserver till en SSH-fjärrserver undviker HTTPS-certifikatkedjan helt, men det reparerar inte det ursprungliga TLS-förtroendeproblemet. SSH har sin egen modell för värdnyckelverifiering och hantering av inloggningsuppgifter.

Använd SSH eftersom det passar din autentiserings- och deploymentsdesign – inte bara för att dölja ett certifikatkonfigurationsfel som andra HTTPS-verktyg kommer att fortsätta att stöta på.

Vanliga misstag att undvika

• Inaktivera SSL-verifiering globalt. Detta tar bort verifiering av servercertifikat för framtida Git HTTPS-anslutningar.
• Lita på lövcertifikatet istället för den utfärdande CA:n. Lövcertifikat löper ut och roterar; förtroende bör normalt förankras i den godkända CA-kedjan.
• Redigera Gits bundna CA-fil manuellt utan att dokumentera det. En uppgradering kan ersätta filen, och ändringen kan vara omöjlig för kollegor eller CI att reproducera.
• Anta att webbläsarens framgång bevisar att Git har samma förtroendekälla. Git kan använda OpenSSL och en separat PEM-bundel medan webbläsaren använder OS-lagringen.
• Använda http.proxySSLCAInfo för fel anslutning. Den inställningen är för att verifiera en HTTPS-proxy, inte en allmän ersättning för ursprungsserverns CA-konfiguration.
• Lappa varje utvecklarens arbetsstation när Git-servern skickar en ofullständig kedja. Fixa servern när du kontrollerar den.

Sammanfattning

Git-felet SSL certificate problem: unable to get local issuer certificate är ett förtroendekedjeproblem, inte ett autentiseringstokenproblem och inte något som normalt bör lösas genom att stänga av certifikatverifiering. Ta reda på om Git använder OpenSSL, Schannel, en anpassad CA-bundel eller en HTTPS-proxy; placera sedan den godkända utfärdande CA:n i den förtroendekälla som Git faktiskt använder.

På Windows är Schannel ett praktiskt alternativ när företags-CA:n redan hanteras i Windows-certifikatlagringen. I CI, containrar eller miljöer som behöver reproducerbar filbaserad förtroendehantering, är http.sslCAInfo ofta tydligare. Och när flera klienter misslyckas mot en självhostad tjänst, reparera serverns certifikatkedja istället för att distribuera osäkra kringgångar.