Kuinka korjata SSL-varmenneongelma: Paikallisen myöntäjän varmenteen haku epäonnistui Gitissä

Vuonna 2026 ei ole tapahtunut merkittäviä muutoksia, jotka tekisivät vanhasta "SSL-varmenteiden tarkistuksen poistamisesta käytöstä" -kiertotiestä hyvän korjauksen. Nykyinen Git-dokumentointi asettaa edelleen oletusarvoksi http.sslVerify-asetukselle arvon true, ja Git tukee edelleen sekä tiedostopohjaista CA-luottamusta että valittavia TLS-taustajärjestelmiä, kuten OpenSSLiä ja Schannelia. Kestävä korjaus on saada Git luottamaan oikeaan varmenteiden myöntäjään (CA) tai korjata puutteellinen palvelimen varmenneketju – ei poistaa varmenteiden tarkistusta käytöstä.

Virhe SSL certificate problem: unable to get local issuer certificate tarkoittaa, että Gitin käyttämä TLS-kirjasto ei pystynyt rakentamaan luotettavaa varmenneketjua palvelimen varmenteesta varmenteiden myöntäjään, jota se luottaa. Tämä voi johtua siitä, että paikallisesta CA-varastosta puuttuu myöntävä CA, yrityksen HTTPS-tarkistusvälityspalvelin allekirjoittaa liikenteen uudelleen sisäisellä CA:lla, Git lukee väärää CA-pakettia tai itse hallinnoitu Git-palvelin ei esitä vaadittuja välivarmenteita.

Tyypillinen Git HTTPS-virhe: etäpalvelimeen saadaan yhteys, mutta varmenneketjun tarkistus ei löydä luotettavaa myöntäjää.

Aloita turvallisimmasta vastauksesta

Käytä seuraavaa järjestystä:

1. Varmista, mitkä Gitin SSL-asetukset ja TLS-taustajärjestelmä ovat aktiivisia.
2. Päätä, kuuluuko puuttuva luottamus käyttöjärjestelmän luottamusvarastoon vai Gitin CA-pakettiin.
3. Jos monet asiakkaat epäonnistuvat samaa itse isännöityä palvelinta vastaan, korjaa palvelimen varmenneketju sen sijaan, että korjaisit jokaista asiakasta erikseen.
4. Testaa uudelleen SSL-varmenteiden tarkistus päällä ja poista kaikki väliaikaiset tai vanhentuneet kiertotieasetukset.

Gitin nykyinen git-config-dokumentointi määrittelee asetukset http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend sekä Windowsissa käytettävän Schannel-kohtaisen toimintatavan. Varmenteiden tarkistuksen oletusarvo on edelleen käytössä.

Luotettava korjaus on palauttaa kelvollinen luottamusketju sen sijaan, että varmenteen tarkistus ohitettaisiin.

Vaihe 1: Selvitä, mitä Git todellisuudessa käyttää

Ennen varmenteiden asentamista tai asetusten muokkaamista, tutki arvot ja niiden alkuperä:

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

Jos komento ei tulosta mitään, kyseinen asetus saattaa yksinkertaisesti käyttää Gitin tai libcurlin oletusarvoa. --show-origin on tärkeä, koska arvo voi tulla järjestelmän, globaalista, paikallisesta repositoriosta tai sisällytetyistä asetustiedostoista. Väärän tason korjaaminen voi jättää tehokkaan asetuksen ennalleen.

Tarkista myös etäpalvelin, johon todellisuudessa otat yhteyttä:

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

Jos Git epäonnistuu vain yhtä yrityksen tai yksityistä isäntää kohtaan, mutta julkiset HTTPS-sivustot toimivat, ongelma on todennäköisesti isäntäkohtainen luottamus tai palvelimen konfiguraatio. Jos Git epäonnistuu monissa epäsuhteisissa HTTPS-etäpalvelimissa, tutki ensin paikallinen Git-asennus, CA-paketin polku, välityspalvelin ja järjestelmän luottamusasetukset.

Älä tee tästä ensimmäistä komentoasi

git config --global http.sslVerify false

Tämä poistaa palvelinvarmenteiden tarkistuksen käytöstä Gitin HTTPS-pyynnöissä globaalilla käyttäjätasolla. Se voi saada virheen katoamaan, mutta samalla se poistaa suojauksen, joka varmistaa, että viestit tarkoituksenmukaisen palvelimen kanssa. Git dokumentoi, että varmenteiden tarkistus on oletuksena käytössä syystä.

Jos löydät vanhan globaalin kiertotien, jota ei enää tarvita, palauta oletustoiminta:

git config --global --unset http.sslVerify

tai aseta eksplisiittisesti:

git config --global http.sslVerify true

Vaihe 2: Windowsissa valitse Windowsin varmennevaraston ja PEM CA -paketin välillä

Windows-kehittäjät kohtaavat tämän virheen usein, kun selain toimii mutta Git ei. Se ei välttämättä tarkoita, että palvelin on rikki. Selain saattaa luottaa yrityksen juurivarmenteeseen, joka on asennettu Windowsiin, kun taas OpenSSL-tyyliseen taustajärjestelmään määritetty Git saattaa käyttää erillistä CA-pakettia.

Git tukee http.sslBackend-arvoja, kuten openssl ja schannel. curlin virallinen TLS-varmentedokumentointi selittää, että Schannel käyttää oletuksena Windowsin natiivia CA-varastoa.

Vaihtoehto A: Käytä Schannelia, kun Windowsissa on jo luotettu yrityksen CA

git config --global http.sslBackend schannel

Tämä sopii usein hyvin Windows-työasemiin, joita hallinnoi organisaatio, joka jakaa luotettuja juuri- ja välivarmenteita Windowsin käytännön kautta. Sen avulla Git voi luottaa samaan Windowsin varmenne-luottamusjärjestelmään, jota muut natiivit sovellukset voivat käyttää.

Siinä on kompromissi: taustajärjestelmän vaihtaminen muuttaa Gitin HTTPS-varmennekäyttäytymistä globaalisti kyseiselle käyttäjälle. Jos organisaatiosi hallinnoi tietoisesti omistautunutta PEM-pakettia Gitille tai automaatiolle, OpenSSLin käyttäminen voi olla ennustettavampaa.

Gitin nykyinen dokumentointi huomauttaa myös hienovaraisesta Schannel-toiminnasta: kun Schannel valitaan http.sslBackend-asetuksella, Git välttää normaalisti http.sslCAInfo-asetuksen soveltamista, koska toimitettu CA-paketti voisi ohittaa Windowsin varmennevaraston. Asetus http.schannelUseSSLCAInfo on olemassa ympäristöjä varten, jotka tietoisesti haluavat tämän toiminnan.

Vaihtoehto B: Pidä OpenSSL ja ohjaa Git hyväksyttyyn CA-pakettiin

Jos organisaatiosi antaa sinulle PEM-paketin, joka sisältää vaaditut sisäiset juuri- ja välivarmenteet, määritä Git käyttämään sitä tiedostoa:

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

Git määrittelee http.sslCAInfo-asetuksen tiedostoksi, joka sisältää varmenteet, joita käytetään vastapuolen varmenteiden tarkistamiseen. Voit myös rajoittaa HTTP-asetukset vastaavaan URL-osoitteeseen sen sijaan, että muuttaisit jokaista HTTPS-kohdetta. Gitin http.<url>.*-asetus tukee URL-kohtaista sovittamista skeeman, isännän, portin ja polun perusteella.

Esimerkiksi:

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

Tämä kapeampi asetus on hyödyllinen, kun vain sisäinen Git-palvelin tarvitsee yksityisen CA:n, kun taas julkisten Git-isäntien tulisi jatkaa normaalin luottamuspaketin käyttöä.

Vaihe 3: macOS:ssä, Linuxissa, CI:ssä ja konteissa korjaa CA-lähde, jota prosessi todellisuudessa käyttää

Periaate on sama Windowsin ulkopuolella: Git-prosessin on päästävä käsiksi CA-varmenteeseen, joka myönsi palvelin- tai välityspalvelinvarmenteen. Tarkat järjestelmän luottamusvaraston komennot vaihtelevat käyttöjärjestelmän ja Linux-jakelun mukaan, joten käytä alustan virallista varmenteiden hallintamekanismia tai järjestelmänvalvojan toimittamaa eksplisiittistä Git CA -pakettia.

Gitin on pystyttävä yhdistämään esitetty palvelinvarmenne sen välivarmenteiden kautta paikallisesti luotettuun CA:han.

Hallitussa CI-työssä tai kontissa, jossa et halua muokata isäntäkoneen globaalia luottamusvarastoa, CA-paketti voi olla eksplisiittinen:

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

tai yksittäiselle prosessille Git tunnistaa myös GIT_SSL_CAINFO-ympäristömuuttujan. Nykyinen Git-dokumentointi toteaa, että tämä ympäristömuuttuja voi ohittaa http.sslCAInfo-asetuksen.

Älä kopioi satunnaista cacert.pem-tiedostoa foorumilta. Jos puuttuva varmenne on yrityksen CA, hanki se IT- tai PKI-tiimiltäsi. Jos etäpalvelin on julkinen palvelu ja CA-pakettisi on yksinkertaisesti vanhentunut, päivitä käyttöjärjestelmäsi, Git-jakelusi, kontin peruskuva tai luotettujen CA-pakettien paketti normaalin päivityskanavan kautta.

Yritysten TLS-tarkistus on erityistapaus

Jotkut yritysten välityspalvelimet tarkistavat HTTPS-liikenteen ja esittävät korvaavan varmenteen, joka on allekirjoitettu sisäisellä yrityksen CA:lla. Tässä tilanteessa selain voi onnistua, koska yrityksen CA on asennettu käyttöjärjestelmän luottamusvarastoon, kun taas Gitin erillinen CA-paketti ei sisällä sitä.

Oikea korjaus on luottaa organisaation CA:han asianmukaisen luottamusvaraston tai Git-paketin kautta. Älä vie nykyistä lehtivarmennetta ja luota siihen pysyvästi myöntävän yrityksen CA:n sijasta.

Erota myös kaksi erillistä välityspalvelintapausta:

• TLS-kaappaus Git-palvelinyhteydelle: Yrityksen CA, joka allekirjoittaa korvaavan palvelinvarmenteen, on luotettava normaalia palvelinvarmenne-polun kautta, kuten Windowsin Schannel tai http.sslCAInfo.
• HTTPS-välityspalvelin, jonka oma välityspalvelinyhteys käyttää TLS:ää: Git tarjoaa http.proxySSLCAInfo-asetuksen nimenomaan CA-paketille, jota käytetään kyseisen HTTPS-välityspalvelinyhteyden tarkistamiseen.

Git dokumentoi http.proxy- ja http.proxySSLCAInfo-asetukset erikseen, joten käytä asetusta, joka vastaa epäonnistuvaa yhteyttä.

Vaihe 4: Jos palvelimen ketju on puutteellinen, korjaa palvelin kun voit

Jos monet käyttäjät tai uudet koneet epäonnistuvat samaa itse isännöityä Git-palvelinta vastaan, ongelma voi olla palvelinpohjainen eikä kokoelma rikki olevia asiakkaita. Palvelimen tulisi esittää varmenneketju, joka on vaadittu, jotta asiakkaat voivat yhdistää lehtivarmenteen luotettavaan myöntäjään.

Kun monet asiakkaat epäonnistuvat yhtä yksityistä Git-isäntää kohtaan, tarkista palvelimen ketju ja välityspalvelinpolku ennen asiakaspuolisten kiertotien jakamista.

GitLabin virallinen SSL-vianmääritysdokumentointi kuvaa nimenomaan virheen unable to get local issuer certificate tapaukseksi, jossa asiakas ei voi hankkia vaadittua myöntäjää, ja suosittelee joko asianmukaisen CA:n luottamista asiakkaalla tai palvelimen korjaamista esittämään täydellinen varmenneketju.

Jos hallinnoit palvelinta, korjaa määritetty täyden ketjun varmenne ja testaa uudelleen puhtaasta asiakkaasta. Se on parempi kuin pyytää jokaista kehittäjää lisäämään ad hoc -poikkeuksia.

Varmista korjaus heikentämättä TLS:ää

Kun luottamusasetus on korjattu, toista sama Git-toiminto:

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

Jos se onnistuu, yritä alkuperäistä clone-, fetch-, pull- tai push-komentoa uudelleen.

Tarkista sitten lopullinen tietoturvaan liittyvä asetuskokonaisuus:

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

Odotettu tila on, että varmenteiden tarkistus pysyy käytössä ja Git pystyy rakentamaan kelvollisen ketjun tarkoitetun luottamuksen lähteen kautta.

Mikä korjaus sopii tilanteeseesi?

Entä Git-etäpalvelimen vaihtaminen SSH:ksi?

SSH voi olla kelvollinen vaihtoehtoinen kuljetuskerros, jos Git-hosting-palvelusi tukee sitä ja organisaatiosi sallii sen. HTTPS-etäpalvelimesta SSH-etäpalvelimeen siirtyminen välttää HTTPS-varmenneketjun kokonaan, mutta se ei korjaa alkuperäistä TLS-luottamusongelmaa. SSH:lla on oma isäntäavaimen tarkistus- ja valtuutusten hallintamalli.

Käytä SSH:ta, koska se sopii valtuutus- ja käyttöönottoarkkitehtuuriisi – ei pelkästään piilottaaksesi varmenneasetusvirheen, jonka muut HTTPS-työkalut tulevat edelleen kohtaamaan.

Yleisiä virheitä, joita tulee välttää

• SSL-varmenteiden tarkistuksen poistaminen käytöstä globaalisti. Tämä poistaa palvelinvarmenteiden tarkistuksen tulevilta Git HTTPS-yhteyksiltä.
• Lehtivarmenteen luottaminen myöntävän CA:n sijaan. Lehtivarmenteet vanhenevat ja vaihtuvat; luottamuksen tulisi normaalisti ankkuroitua hyväksyttyyn CA-ketjuun.
• Gitin pakatun CA-tiedoston manuaalinen muokkaaminen dokumentoimatta sitä. Päivitys voi korvata tiedoston, ja muutos voi olla mahdoton toistaa tiimikollegoille tai CI:lle.
• Olettaa, että selaimen onnistuminen todistaa Gitin käyttävän samaa luottamuslähdettä. Git saattaa käyttää OpenSSLiä ja erillistä PEM-pakettia, kun selain käyttää käyttöjärjestelmän varastoa.
• http.proxySSLCAInfo-asetuksen käyttäminen väärään yhteyteen. Tämä asetus on HTTPS-välityspalvelimen tarkistamista varten, ei yleinen korvike alkuperäisen palvelimen CA-asetukselle.
• Jokaisen kehittäjän työaseman paikkaaminen, kun Git-palvelin lähettää puutteellisen ketjun. Korjaa palvelin, kun hallitset sitä.

Yhteenveto

Git-virhe SSL certificate problem: unable to get local issuer certificate on luottamusketjuongelma, ei todennusmerkkiongelma eikä asia, joka tulisi normaalisti ratkaista kääntämällä varmenteiden tarkistus pois päältä. Selvitä, käyttääkö Git OpenSSLiä, Schannelia, mukautettua CA-pakettia vai HTTPS-välityspalvelinta; aseta sitten hyväksytty myöntävä CA siihen luottamuslähteeseen, jota Git todellisuudessa käyttää.

Windowsissa Schannel on käytännöllinen vaihtoehto, kun yrityksen CA on jo hallinnoitu Windowsin varmennevarastossa. CI:ssä, konteissa tai ympäristöissä, jotka tarvitsevat toistettavan tiedostopohjaisen luottamuksen, http.sslCAInfo on usein selkeämpi. Ja kun useat asiakkaat epäonnistuvat yhtä itse isännöityä palvelua kohtaan, korjaa palvelimen varmenneketju sen sijaan, että jakaisit turvattomia kiertoteitä.