Sådan løser du SSL-certifikatproblemet: Unable to get local issuer certificate i Git

Der er ingen meningsfuld ændring i 2026, der gør den gamle workaround "slå SSL-verifikation fra" til en god løsning. Den nuværende Git-dokumentation sætter stadig http.sslVerify til true som standard, og Git understøtter stadig både filbaseret CA-tillid og valgbare TLS-backends som OpenSSL og Schannel. Den holdbare løsning er at få Git til at stole på den korrekte certifikatautoritet eller at reparere en ufuldstændig servercertifikatkæde – ikke at deaktivere verifikation.

Fejlen SSL certificate problem: unable to get local issuer certificate betyder, at TLS-biblioteket brugt af Git ikke kunne opbygge en betroet certifikatkæde fra servercertifikatet til en certifikatautoritet, det stoler på. Det kan ske, fordi den lokale CA-lager mangler den udstedende CA, en korporativ HTTPS-inspektionsproxy gensignerer trafik med en intern CA, Git læser den forkerte CA-pakke, eller en selvadministreret Git-server ikke præsenterer de nødvendige mellemliggende certifikater.

En typisk Git HTTPS-fejl: Fjernserveren kan nås, men certifikatkædeverifikation kan ikke finde en betroet udsteder.

Begynd med det sikreste svar

Brug denne rækkefølge:

1. Bekræft, hvilke Git SSL-indstillinger og TLS-backend der er aktive.
2. Afgør, om den manglende tillid hører til i operativsystemets tillidslager eller i en Git CA-pakke.
3. Hvis mange klienter fejler mod den samme selvhostede server, skal du reparere serverens certifikatkæde i stedet for at lappe hver enkelt klient.
4. Test igen med SSL-verifikation aktiveret og fjern eventuelle midlertidige eller forældede bypass-konfigurationer.

Gits nuværende git-config-dokumentation definerer http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend og den Schannel-specifikke adfærd, der bruges på Windows. Standarden for certifikatverifikation forbliver aktiveret.

Den pålidelige reparation er at genoprette en gyldig tillidskæde frem for at undertrykke certifikattjekket.

Trin 1: Find ud af, hvad Git faktisk bruger

Før du installerer certifikater eller redigerer konfiguration, skal du inspicere værdierne og hvor de kom fra:

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

Hvis en kommando ikke udskriver noget, bruger den muligheden måske blot Gits eller libcurls standard. --show-origin er vigtigt, fordi en værdi kan komme fra system-, global-, lokal repository- eller inkluderet konfigurationsfiler. At rette på det forkerte niveau kan efterlade den effektive indstilling uændret.

Tjek også den fjernserver, du faktisk kontakter:

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

Hvis Git kun fejler for én korporativ eller privat host, mens offentlige HTTPS-websteder virker, er problemet sandsynligvis host-specifik tillid eller serverkonfiguration. Hvis Git fejler for mange urelaterede HTTPS-fjernservere, skal du først inspicere den lokale Git-installation, CA-pakkestien, proxyen og systemets tillidskonfiguration.

Gør ikke dette til din første kommando

git config --global http.sslVerify false

Det deaktiverer servercertifikatverifikation for Git HTTPS-anmodninger på globalt brugerniveau. Det kan få fejlen til at forsvinde, mens det også fjerner beskyttelsen, der verificerer, at du kommunikerer med den tilsigtede server. Git dokumenterer, at verifikation er aktiveret som standard af en grund.

Hvis du opdager et gammelt globalt bypass, der ikke længere er nødvendigt, skal du genoprette standardadfærden:

git config --global --unset http.sslVerify

eller sæt eksplicit:

git config --global http.sslVerify true

Trin 2: På Windows, vælg mellem Windows-certifikatlageret og en PEM CA-pakke

Windows-udviklere oplever ofte denne fejl, når en browser virker, men Git gør ikke. Det betyder ikke nødvendigvis, at serveren er defekt. Browseren stoler måske på et korporativt rodcertifikat installeret i Windows, mens Git konfigureret med en OpenSSL-lignende backend bruger en separat CA-pakke.

Git understøtter http.sslBackend-værdier som openssl og schannel. Curls officielle TLS-certifikatdokumentation forklarer, at Schannel som standard bruger Windows' native CA-lager.

Mulighed A: Brug Schannel, når Windows allerede har den betroede korporative CA

git config --global http.sslBackend schannel

Dette passer ofte godt til Windows-only arbejdsstationer administreret af en organisation, der distribuerer betroede rod- og mellemliggende certifikater via Windows-politik. Det lader Git stole på det samme Windows-certifikattillidssystem, som andre native applikationer kan bruge.

Der er et afvejning: At ændre backenden ændrer Gits HTTPS-certifikatadfærd globalt for den bruger. Hvis din organisation bevidst administrerer en dedikeret PEM-pakke til Git eller automatisering, kan det være mere forudsigeligt at blive hos OpenSSL.

Gits nuværende dokumentation nævner også en subtil Schannel-adfærd: Når Schannel vælges via http.sslBackend, undgår Git normalt at anvende http.sslCAInfo, fordi en leveret CA-pakke kan tilsidesætte Windows-certifikatlageret. Indstillingen http.schannelUseSSLCAInfo findes til miljøer, der bevidst ønsker denne adfærd.

Mulighed B: Behold OpenSSL og peg Git mod en godkendt CA-pakke

Hvis din organisation giver dig en PEM-pakke, der indeholder de nødvendige interne rod- og mellemliggende certifikater, skal du konfigurere Git til at bruge den fil:

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

Git definerer http.sslCAInfo som filen, der indeholder certifikater brugt til at verificere peer'en. Du kan også begrænse HTTP-konfigurationen til en matchende URL i stedet for at ændre alle HTTPS-destinationer. Gits http.<url>.*-konfiguration understøtter URL-specifik matchning efter skema, host, port og sti.

For eksempel:

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

Denne snævrere indstilling er nyttig, når kun en intern Git-server har brug for en privat CA, mens offentlige Git-hosts skal fortsætte med at bruge den normale tillidspakke.

Trin 3: På macOS, Linux, CI og containere, reparer CA-kilden, som processen faktisk bruger

Princippet er det samme uden for Windows: Git-processen skal have adgang til CA-certifikatet, der udstedte server- eller proxycertifikatet. De præcise kommandoer til systemtillidslageret varierer efter operativsystem og Linux-distribution, så brug platformens officielle certifikatadministrationsmekanisme eller en eksplicit Git CA-pakke leveret af din administrator.

Git skal kunne forbinde det præsenterede servercertifikat gennem dets mellemliggende udstedere til en lokalt betroet CA.

For et kontrolleret CI-job eller container, hvor du ikke ønsker at ændre værtsens globale tillidslager, kan en CA-pakke være eksplicit:

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

eller, for en individuel proces, genkender Git også miljøvariablen GIT_SSL_CAINFO. Den nuværende Git-dokumentation angiver, at denne miljøvariabel kan tilsidesætte http.sslCAInfo.

Kopiér ikke en tilfældig cacert.pem-fil fra et forum. Hvis det manglende certifikat er en korporativ CA, skal du hente den fra dit IT- eller PKI-team. Hvis fjernserveren er en offentlig tjeneste, og din CA-pakke blot er forældet, skal du opdatere dit operativsystem, Git-distribution, container-basisimage eller betroede CA-pakke via dens normale opdateringskanal.

Korporativ TLS-inspektion er et særligt tilfælde

Nogle enterprise-proxyer inspicere HTTPS og præsenterer et erstatningscertifikat signeret af en intern korporativ CA. I den situation kan browseren lykkes, fordi den korporative CA er installeret i OS-tillidslageret, mens Gits separate CA-pakke ikke indeholder den.

Den korrekte løsning er at stole på organisationens CA via det passende tillidslager eller Git-pakke. Eksportér ikke det nuværende bladcertifikat og stol permanent på det som erstatning for den udstedende korporative CA.

Skeln også mellem to separate proxytilfælde:

• TLS-aflytning af Git-serverforbindelsen: Den korporative CA, der signerer erstatningsservercertifikatet, skal være betroet via den normale servercertifikatsti, såsom Windows Schannel eller http.sslCAInfo.
• En HTTPS-proxy, hvis egen proxyforbindelse bruger TLS: Git giver http.proxySSLCAInfo specifikt til CA-pakken brugt til at verificere den HTTPS-proxyforbindelse.

Git dokumenterer http.proxy og http.proxySSLCAInfo separat, så brug den indstilling, der matcher den forbindelse, der fejler.

Trin 4: Hvis serverkæden er ufuldstændig, reparer serveren, når du kan

Hvis mange brugere eller nye maskiner fejler mod den samme selvhostede Git-server, kan problemet være serverside snarere end en samling af defekte klienter. Serveren skal præsentere certifikatkæden, der kræves for, at klienter kan forbinde bladcertifikatet til en betroet udsteder.

Når mange klienter fejler mod én privat Git-host, skal du tjekke serverkæden og proxystien, før du distribuerer klient-side workarounds.

GitLabs officielle SSL-fejlfindingsdokumentation beskriver specifikt unable to get local issuer certificate som et tilfælde, hvor klienten ikke kan opnå den nødvendige udsteder, og anbefaler enten at stole på den passende CA på klienten eller at korrigere serveren til at præsentere en komplet certifikatkæde.

Hvis du administrerer serveren, skal du reparere den konfigurerede fuld-kæde certifikat og teste igen fra en ren klient. Det er foretrukket frem for at bede hver udvikler om at tilføje ad hoc-undtagelser.

Verificer løsningen uden at svække TLS

Efter at tillidskonfigurationen er korrigeret, skal du gentage den samme Git-operation:

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

Hvis det lykkes, skal du prøve den oprindelige clone, fetch, pull eller push igen.

Inspektion derefter den endelige sikkerhedsrelaterede konfiguration:

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

Den forventede tilstand er, at certifikatverifikation forbliver aktiveret, og at Git kan opbygge en gyldig kæde gennem den tilsigtede tillidskilde.

Hvilken løsning matcher din situation?

Hvad med at skifte Git-fjernserveren til SSH?

SSH kan være et gyldigt alternativ transport, hvis din Git-hostingtjeneste understøtter det, og din organisation tillader det. At ændre fra en HTTPS-fjernserver til en SSH-fjernserver undgår HTTPS-certifikatkæden helt, men det reparerer ikke det oprindelige TLS-tillidsproblem. SSH har sin egen host-nøgleverifikation og legitimationsstyringsmodel.

Brug SSH, fordi det passer til din autentificerings- og deploymentsdesign – ikke blot for at skjule en certifikatkonfigurationsfejl, som andre HTTPS-værktøjer vil fortsætte med at opleve.

Almindelige fejl at undgå

• Deaktivering af SSL-verifikation globalt. Dette fjerner servercertifikatverifikation for fremtidige Git HTTPS-forbindelser.
• At stole på bladcertifikatet i stedet for den udstedende CA. Bladcertifikater udløber og roterer; tillid skal normalt forankres i den godkendte CA-kæde.
• Manuel redigering af Gits bundtede CA-fil uden dokumentation. En opgradering kan erstatte filen, og ændringen kan være umulig for kolleger eller CI at reproducere.
• At antage, at browser-succes beviser, at Git har den samme tillidskilde. Git kan bruge OpenSSL og en separat PEM-pakke, mens browseren bruger OS-lageret.
• At bruge http.proxySSLCAInfo til den forkerte forbindelse. Den indstilling er til verifikation af en HTTPS-proxy, ikke en generel erstatning for oprindelses-server CA-konfigurationen.
• At lappe hver udviklerarbejdsstation, når Git-serveren sender en ufuldstændig kæde. Reparer serveren, når du kontrollerer den.

Konklusion

Git-fejlen SSL certificate problem: unable to get local issuer certificate er et tillidskædeproblem, ikke et autentificeringstokenproblem, og ikke noget, der normalt skal løses ved at slå certifikatverifikation fra. Find ud af, om Git bruger OpenSSL, Schannel, en brugerdefineret CA-pakke eller en HTTPS-proxy; placer derefter den godkendte udstedende CA i den tillidskilde, som Git faktisk bruger.

På Windows er Schannel et praktisk valg, når den korporative CA allerede administreres i Windows-certifikatlageret. I CI, containere eller miljøer, der behøver reproducerbar filbaseret tillid, er http.sslCAInfo ofte klarere. Og når flere klienter fejler mod én selvhostet tjeneste, skal du reparere serverens certifikatkæde i stedet for at distribuere usikre bypasses.