Slik løser du SSL-sertifikatproblemet: Unable to Get Local Issuer Certificate i Git

Det finnes ingen meningsfull endring i 2026 som gjør den gamle løsningen «slå av SSL-verifisering» til en god fiks. Gjeldende Git-dokumentasjon setter fortsatt http.sslVerify til true som standard, og Git støtter fortsatt både filbasert CA-tillit og valgbare TLS-bakgrunner som OpenSSL og Schannel. Den varige løsningen er å få Git til å stole på den riktige sertifikatmyndigheten eller reparere en ufullstendig serversertifikatkjede – ikke å deaktivere verifisering.

Feilmeldingen SSL certificate problem: unable to get local issuer certificate betyr at TLS-biblioteket som brukes av Git, ikke klarte å bygge en betrodd sertifikat-kjede fra serversertifikatet til en sertifikatmyndighet det stoler på. Det kan skje fordi den lokale CA-lageret mangler den utstedende CA-en, en bedrifts HTTPS-inspeksjonsproxy signerer trafikk på nytt med en intern CA, Git leser feil CA-bunt, eller en selvadministrert Git-server ikke presenterer de nødvendige mellomsertifikatene.

En typisk Git HTTPS-feil: serveren kan nås, men sertifikat-kjede-verifisering finner ikke en betrodd utsteder.

Begynn med det tryggeste svaret

Bruk denne rekkefølgen:

1. Bekreft hvilke Git SSL-innstillinger og TLS-bakgrunn som er aktive.
2. Bestem om den manglende tilliten hører hjemme i operativsystemets tillitslager eller i en Git CA-bunt.
3. Hvis mange klienter feiler mot samme selvhostede server, reparer serverens sertifikat-kjede i stedet for å lappe hver enkelt klient.
4. Test på nytt med SSL-verifisering aktivert og fjern eventuelle midlertidige eller utdaterte omgåelseskonfigurasjoner.

Gits gjeldende git-config-dokumentasjon definerer http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend og Schannel-spesifikk atferd som brukes på Windows. Standarden for sertifikatverifisering forblir aktivert.

Den pålitelige reparasjonen er å gjenopprette en gyldig tillitskjede i stedet for å undertrykke sertifikatkontrollen.

Trinn 1: Finn ut hva Git faktisk bruker

Før du installerer sertifikater eller redigerer konfigurasjon, inspiser verdiene 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 skriver ut noe, kan det hende at alternativet bare bruker Git eller libcurls standard. --show-origin er viktig fordi en verdi kan komme fra system-, global-, lokal repository- eller inkluderte konfigurasjonsfiler. Å fikse feil nivå kan la den effektive innstillingen være uendret.

Sjekk også fjernserveren du faktisk kontakter:

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

Hvis Git feiler bare for én bedrifts- eller privat vert mens offentlige HTTPS-sider fungerer, er problemet sannsynligvis verts-spesifikk tillit eller serverkonfigurasjon. Hvis Git feiler for mange urelaterte HTTPS-fjernservere, inspiser den lokale Git-installasjonen, CA-buntbanen, proxyen og systemtillitskonfigurasjonen først.

Ikke gjør dette til din første kommando

git config --global http.sslVerify false

Det deaktiverer serversertifikatverifisering for Git HTTPS-forespørsler på globalt brukernivå. Det kan få feilen til å forsvinne mens det også fjerner beskyttelsen som verifiserer at du kommuniserer med den tiltenkte serveren. Git dokumenterer at verifisering er aktivert som standard av en grunn.

Hvis du oppdager en gammel global omgåelse som ikke lenger er nødvendig, gjenopprett standardatferden:

git config --global --unset http.sslVerify

eller sett eksplisitt:

git config --global http.sslVerify true

Trinn 2: På Windows, velg mellom Windows sertifikatlager og en PEM CA-bunt

Windows-utviklere møter ofte denne feilen når en nettleser fungerer, men Git ikke gjør det. Det betyr ikke nødvendigvis at serveren er ødelagt. Nettleseren kan stole på et bedriftsrotsertifikat installert i Windows, mens Git konfigurert med en OpenSSL-stil bakgrunn kanskje bruker en separat CA-bunt.

Git støtter http.sslBackend-verdier som openssl og schannel. curl sin offisielle TLS-sertifikatdokumentasjon forklarer at Schannel bruker Windows innebygde CA-lager som standard.

Alternativ A: Bruk Schannel når Windows allerede har den betroede bedrifts-CA-en

git config --global http.sslBackend schannel

Dette passer ofte godt for Windows-arbeidsstasjoner administrert av en organisasjon som distribuerer betroede rot- og mellomsertifikater via Windows-policy. Det lar Git stole på samme Windows sertifikat-tillitssystem som andre native applikasjoner kan bruke.

Det er et avveiningsforhold: Å endre bakgrunnen endrer Gits HTTPS-sertifikatatferd globalt for den brukeren. Hvis organisasjonen din bevisst administrerer en dedikert PEM-bunt for Git eller automatisering, kan det være mer forutsigbart å forbli med OpenSSL.

Gits gjeldende dokumentasjon merker også en subtil Schannel-atferd: Når Schannel er valgt via http.sslBackend, unngår Git normalt å anvende http.sslCAInfo fordi en levert CA-bunt kan overstyre Windows Certificate Store. Innstillingen http.schannelUseSSLCAInfo finnes for miljøer som bevisst ønsker den atferden.

Alternativ B: Behold OpenSSL og pek Git til en godkjent CA-bunt

Hvis organisasjonen din gir deg en PEM-bunt som inneholder de nødvendige interne rot- og mellomsertifikatene, konfigurer Git til å bruke den filen:

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

Git definerer http.sslCAInfo som filen som inneholder sertifikater brukt til å verifisere peer-en. Du kan også begrense HTTP-konfigurasjonen til en matchende URL i stedet for å endre alle HTTPS-destinasjoner. Gits http.<url>.*-konfigurasjon støtter URL-spesifikk matching etter skjema, vert, port og sti.

For eksempel:

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

Denne smalere innstillingen er nyttig når bare en intern Git-server trenger en privat CA, mens offentlige Git-verter bør fortsette å bruke den normale tillitsbunten.

Trinn 3: På macOS, Linux, CI og containere, fikse CA-kilden prosessen faktisk bruker

Prinsippet er det samme utenfor Windows: Git-prosessen må ha tilgang til CA-sertifikatet som utstedte server- eller proxiesertifikatet. De nøyaktige kommandoene for systemtillitslager varierer etter operativsystem og Linux-distribusjon, så bruk plattformens offisielle sertifikatadministrasjonsmekanisme eller en eksplisitt Git CA-bunt levert av administratoren din.

Git må kunne koble det presenterte serversertifikatet gjennom dets mellomutstedere til en lokalt betrodd CA.

For en kontrollert CI-jobb eller container der du ikke ønsker å endre vertens globale tillitslager, kan en CA-bunt være eksplisitt:

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

eller, for en individuell prosess, gjenkjenner Git også miljøvariabelen GIT_SSL_CAINFO. Gjeldende Git-dokumentasjon sier at denne miljøvariabelen kan overstyre http.sslCAInfo.

Ikke kopier en tilfeldig cacert.pem-fil fra et forum. Hvis det manglende sertifikatet er en bedrifts-CA, få den fra IT- eller PKI-teamet ditt. Hvis fjernserveren er en offentlig tjeneste og CA-bunten din bare er utdatert, oppdater operativsystemet, Git-distribusjonen, container-basisbildet eller det betroede CA-pakken via den normale oppdateringskanalen.

Bedrifts TLS-inspeksjon er et spesialtilfelle

Noen bedriftsproxyer inspiserer HTTPS og presenterer et erstatningssertifikat signert av en intern bedrifts-CA. I den situasjonen kan nettleseren lykkes fordi bedrifts-CA-en er installert i OS-tillitslageret, mens Gits separate CA-bunt ikke inneholder den.

Den riktige løsningen er å stole på organisasjonens CA via det riktige tillitslageret eller Git-bunten. Eksporter ikke det gjeldende bladsertifikatet og stol permanent på det som en erstatning for den utstedende bedrifts-CA-en.

Skille også mellom to separate proxy-tilfeller:

• TLS-interception av Git-serverforbindelsen: Bedrifts-CA-en som signerer erstatningsserversertifikatet, må være betrodd via den normale serversertifikatbanen, som Windows Schannel eller http.sslCAInfo.
• En HTTPS-proxy hvis egen proxyforbindelse bruker TLS: Git gir http.proxySSLCAInfo spesifikt for CA-bunten som brukes til å verifisere den HTTPS-proxyforbindelsen.

Git dokumenterer http.proxy og http.proxySSLCAInfo separat, så bruk innstillingen som matcher forbindelsen som feiler.

Trinn 4: Hvis serverkjeden er ufullstendig, fikse serveren når du kan

Hvis mange brukere eller nye maskiner feiler mot samme selvhostede Git-server, kan problemet være serverside i stedet for en samling ødelagte klienter. Serveren bør presentere sertifikatkjeden som kreves for at klienter skal koble bladsertifikatet til en betrodd utsteder.

Når mange klienter feiler mot én privat Git-vert, sjekk serverkjeden og proxystien før du distribuerer klient-side omgåelser.

GitLabs offisielle SSL-feilsøkingsdokumentasjon beskriver spesifikt unable to get local issuer certificate som et tilfelle der klienten ikke kan skaffe den nødvendige utstederen, og anbefaler enten å stole på riktig CA på klienten eller korrigere serveren til å presentere en komplett sertifikat-kjede.

Hvis du administrerer serveren, reparer det konfigurerte fullkjede-sertifikatet og test på nytt fra en ren klient. Det er foretrekkelig fremfor å be hver utvikler om å legge til ad hoc unntak.

Verifiser løsningen uten å svekke TLS

Etter at tillitskonfigurasjonen er korrigert, gjenta samme Git-operasjon:

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

Hvis det lykkes, prøv den opprinnelige clone, fetch, pull eller push på nytt.

Inspekter deretter den endelige sikkerhetsrelaterte konfigurasjonen:

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

Den forventede tilstanden er at sertifikatverifisering forblir aktivert og Git kan bygge en gyldig kjede gjennom den tiltenkte tillitskilden.

Hvilken løsning matcher din situasjon?

Hva med å bytte Git-fjernserver til SSH?

SSH kan være et gyldig alternativ transportlag hvis Git-hostingtjenesten din støtter det og organisasjonen din tillater det. Å endre fra en HTTPS-fjernserver til en SSH-fjernserver unngår HTTPS-sertifikatkjeden helt, men det reparerer ikke det opprinnelige TLS-tillitsproblemet. SSH har sin egen vertsnøkkel-verifisering og legitimasjonsadministrasjonsmodell.

Bruk SSH fordi det passer din autentiserings- og utformingsdesign – ikke bare for å skjule en sertifikatkonfigurasjonsfeil som andre HTTPS-verktøy vil fortsette å møte.

Vanlige feil å unngå

• Å deaktivere SSL-verifisering globalt. Dette fjerner serversertifikatverifisering for fremtidige Git HTTPS-forbindelser.
• Å stole på bladsertifikatet i stedet for den utstedende CA-en. Bladsertifikater utløper og roterer; tillit bør normalt forankres i den godkjente CA-kjeden.
• Å redigere Gits buntede CA-fil manuelt uten å dokumentere det. En oppgradering kan erstatte filen, og endringen kan være umulig for teamkolleger eller CI å reprodusere.
• Å anta at nettlesersuksess beviser at Git har samme tillitskilde. Git kan bruke OpenSSL og en separat PEM-bunt mens nettleseren bruker OS-lageret.
• Å bruke http.proxySSLCAInfo for feil forbindelse. Den innstillingen er for å verifisere en HTTPS-proxy, ikke en generell erstatning for opprinnelse-server CA-konfigurasjonen.
• Å lappe hver utviklerarbeidsstasjon når Git-serveren sender en ufullstendig kjede. Fikse serveren når du kontrollerer den.

Konklusjon

Git-feilen SSL certificate problem: unable to get local issuer certificate er et tillitskjedeproblem, ikke et autentiseringstoken-problem, og ikke noe som normalt bør løses ved å slå av sertifikatverifisering. Finn ut om Git bruker OpenSSL, Schannel, en egendefinert CA-bunt eller en HTTPS-proxy; plasser deretter den godkjente utstedende CA-en i tillitskilden som Git faktisk bruker.

På Windows er Schannel et praktisk alternativ når bedrifts-CA-en allerede administreres i Windows Certificate Store. I CI, containere eller miljøer som trenger reproduserbar filbasert tillit, er http.sslCAInfo ofte klarere. Og når flere klienter feiler mot én selvhostet tjeneste, reparer serverens sertifikat-kjede i stedet for å distribuere usikre omgåelser.