Unable to Get Local Issuer Certificate Hatası Nasıl Çözülür?

İş bilgisayarınızda npm install çalıştırıyorsunuz ve komut npm error code UNABLE_TO_GET_ISSUER_CERT_LOCALLY hatasıyla duruyor. Aynı makinede Chrome, npm kayıt deposunu (registry) sorunsuz açıyor; evden çalışan bir arkadaşınız da aynı paketleri sorunsuz kuruyor. Bir Python betiği CERTIFICATE_VERIFY_FAILED ile düşüyor, git clone da bir SSL sertifikası sorunu bildiriyor. Kayıt deposunda bir sorun yok: araçlarınız ile tarayıcınız farklı sertifika otoritesi listelerine güveniyor.

Bu yazıda istemcinin neyi denetlediğini anlatıyor, üç nedeni yerel test sunucularında ürettiğimiz hatalarla birbirinden ayırıyor ve Python, npm, Git ile curl için çözümü, ardından sunucu tarafındaki düzeltmeyi veriyoruz.

"Unable to get local issuer certificate" ne anlama gelir?#

Bir TLS sertifikası, sahibini (subject) ve onu imzalayan sertifika otoritesini (CA) yazar; sertifikada bu ikinciye issuer denir. Sunucu tek bir sertifika göndermez: kendi sertifikasını, yani yaprak sertifikayı (leaf), onu bir kök sertifikaya bağlayan bir ya da daha fazla ara sertifikayla birlikte gönderir. Kök sertifikalar bağlantı sırasında gelmez; her istemci güvendiği kökleri kendi güven deposunda tutar. Mesajdaki "local" (yerel) sözcüğü bu depoyu anlatır.

Metin, OpenSSL'in 20 numaralı doğrulama hatasıdır: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. İstemci zincirdeki bir sertifikanın imzalayanını aramış, onu ne sunucunun gönderdiği sertifikalar arasında ne de kendi deposunda bulabilmiştir. El sıkışma, isteğiniz gönderilmeden önce durur.

Sertifika zinciri doğrulaması nasıl çalışır?#

1. Sunucu zincirini gönderir. Önce yaprak sertifika gelir, ardından gelen her sertifika kendinden öncekini imzalar; istemcilerde zaten bulunduğu için kök gönderilmeyebilir (RFC 8446, bölüm 4.4.2).
2. İstemci yaprak sertifikayı denetler: ad, URL'deki host ile eşleşmeli, tarihler geçerli olmalıdır.
3. İstemci her sertifikanın imzalayanını bulur: onu gönderilen sertifikalar arasında arar, imzayı doğrular ve bir üst basamakta aynı işi yineler.
4. Zincirin tepesi güven deposunda bitmelidir; son sertifikayı istemcinin zaten güvendiği bir kök imzalamış olmalıdır.
5. Eksik bir halka el sıkışmayı durdurur; hata metni, zincirin nerede koptuğuna göre değişir.

Güven deposu makineye değil, araca bağlıdır. Requests, Mozilla'nın kök listesini taşıyan certifi adlı Python paketini kullanır; Node.js her sürüme Mozilla deposunun bir kopyasını gömer; Git for Windows kendi ca-bundle.crt dosyasını ya da Windows deposunu okur. Bu yüzden aynı bilgisayarda bir program hata verirken öbürü aynı adrese bağlanabilir.

Üç hata mesajı, tek aile#

OpenSSL ile bir kök, bir ara ve bir yaprak sertifika ürettik, zincirin farklı parçalarını gönderen üç yerel HTTPS sunucusu çalıştırdık ve bunları Windows 11'de Python 3.13.9 (Requests 2.34.2), Node.js 24.11.1 (npm 11.6.2), curl 8.21.0 ve Git 2.55 (OpenSSL ile) üzerinden çağırdık. Hiçbir araç kökümüzü tanımıyordu.

Python ve curl, eksik ara sertifika için de tanınmayan kök için de aynı ifadeyi kullanır; hangi tarafın düzeltileceğini yalnızca zincir söyler. Üçüncü satır, kökün de gönderildiği aynı sorundur: sunucu ya da aradaki bir proxy, aracınızın güvenmediği bir kök göndermiştir.

Hatanın üç nedeni#

1. Sunucu ara sertifikasını göndermiyor#

Yönetici yalnızca yaprak sertifikayı kurmuştur; ara sertifikaya sahip olmayan her istemci, her ağda hata verir. Tarayıcılar bunu çoğu zaman gizler: Mozilla'nın anlattığına göre Firefox bilinen ara sertifikaları önceden kendi içinde taşır, öbür tarayıcılar ise eksik olanı arka planda indirir. Python, Node.js, curl ve Git bunların hiçbirini yapmaz; bu yüzden "Chrome'da açılıyor" demek hiçbir şey kanıtlamaz.

2. TLS denetimi yapan bir proxy ya da antivirüs trafiği yeniden imzalıyor#

Şirketlerin web ağ geçitleri, HTTPS tarama özelliği olan antivirüs ürünleri ve mitmproxy, Charles, Fiddler gibi hata ayıklama araçları şifreli bağlantıyı açar ve site için kendi kökleriyle imzaladıkları yeni bir sertifika sunar. BT ekibi bu kökü yönetilen dizüstü bilgisayarların sistem deposuna kurar, böylece tarayıcılar sertifikayı kabul eder; kendi listesini taşıyan araçlar ise reddeder. İpuçları: hata ofis ağında ya da VPN'de çıkar, evde çıkmaz ve neredeyse her sitede görülür. Böyle bir aracı kendiniz kullanıyorsanız kök sertifika adımı MITM Proxy Nedir? Charles, Fiddler ve mitmproxy Rehberi yazısında anlatılıyor.

3. Aracınız sisteminizden farklı bir listeye güveniyor#

Requests'in, Node.js'in ve Git'in kendi kök listeleri, şirketinizin Windows'a ya da macOS'e kurduğu kökü de iç servisleri imzalayan özel bir CA'yı da görmez. macOS'te python.org yükleyicisiyle kurulan Python da aynı nedenle ayrı bir sertifika adımı ister; eski sistemlerde ve eski paketlerde ise yeni genel kökler bulunmayabilir.

Hangi nedenle karşı karşıya olduğunuzu nasıl anlarsınız?#

Sunucunun gerçekten gönderdiği zincire bakın. Git for Windows openssl ile birlikte gelir, bu yüzden komut Git Bash'te de çalışır:

openssl s_client -connect localhost:47444 -servername localhost -showcerts </dev/null

47444 portundaki sunucumuz yalnızca yaprak sertifikasını gönderiyor. Çıktının ilgili satırları:

Certificate chain
 0 s:CN=localhost
   i:O=Example Corp, CN=Example Corp Issuing CA
Verify return code: 21 (unable to verify the first certificate)

s: sahibi (subject), i: imzalayanı (issuer) gösterir; eksiksiz bir zincirde ikinci bir 1 s: kaydı da bulunur. TLS denetimini görmek için trafiği bir şirket ağ geçidi gibi yeniden imzalayan yerel bir proxy çalıştırdık, CA'sına Example Corp adını verdik ve example.com adresini onun üzerinden istedik (-proxy 127.0.0.1:47461):

Certificate chain
 0 s:CN=example.com
   i:O=Example Corp, CN=Example Corp Issuing CA
 1 s:O=Example Corp, CN=Example Corp Issuing CA
   i:O=Example Corp, CN=Example Corp Root CA
Verify return code: 20 (unable to get local issuer certificate)

Düz bir tünel üzerinden aynı komut sitenin gerçek zincirini gösterdi: sertifikayı Cloudflare TLS Issuing ECC CA 3 imzalamıştı ve sonuç Verify return code: 0 (ok) idi. Kendi çıktınızı şöyle okuyun:

• Yalnızca 0 numaralı kayıt var, imzalayan genel bir CA: sunucu ara sertifikasını göndermiyor (1. neden).
• İmzalayan şirketiniz, bir güvenlik ürünü ya da bir hata ayıklama aracı: trafiği bir şey yeniden imzalıyor (2. neden).
• Zincir eksiksiz ve genel, sonuç 0 (ok), ama aracınız hata veriyor: araç başka bir güven deposunu okuyor (3. neden).

Python'da nasıl çözülür?#

Requests hatayı daha uzun bir satırın içine sarar; Caused by kısmının nasıl okunacağını Max Retries Exceeded With URL Hatası Nedir, Nasıl Çözülür? yazısında anlattık. Testimizin ürettiği satır:

requests.exceptions.SSLError: HTTPSConnectionPool(host='localhost', port=47443): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)')))

BT ekibi şirket kökünü işletim sistemine kurduysa Python'un da o depoyu kullanmasını sağlayın. truststore paketi (Python 3.10 ve sonrası), Requests'in ve ssl modülünün doğrulamayı sistem deposu üzerinden yapmasını sağlar. Dokümantasyonu, inject_into_ssl() çağrısının kütüphanelerde değil yalnızca uygulamalarda ve betiklerde kullanılmasını ister:

import truststore
truststore.inject_into_ssl()  # betiğin başında bir kez çağırın

import requests

print(requests.get("https://example.com/", timeout=10).status_code)

Bu mümkün değilse certifi'nin köklerini ve şirket kökünü içeren bir CA paketi (bundle) dosyası oluşturun, REQUESTS_CA_BUNDLE değişkenini de bu dosyaya yönlendirin:

cat "$(python -m certifi)" corp-root.pem > ca-bundle-plus-corp.pem
export REQUESTS_CA_BUNDLE="$PWD/ca-bundle-plus-corp.pem"

Bundan sonra hem example.com hem de test sunucumuz 200 döndü. Şirket kökünü asla tek başına kullanmayın: bu değişken certifi'ye ekleme yapmaz, onun yerine geçer; testimizde example.com o durumda aynı hatayla düştü. Dosyayı certifi her güncellendiğinde yeniden oluşturun.

Paket yöneticisi pip farklı davranır: 24.2 sürümünden beri certifi'ye ek olarak sistem sertifikalarını da kullanır (pip dokümantasyonu). Bu yüzden Requests'in hata verdiği bir bilgisayarda pip install çalışabilir. Belirli bir CA paketi için --cert seçeneğini verin ya da PIP_CERT değişkenini ayarlayın. macOS'te python.org yükleyicisini kullandıysanız Install Certificates.command dosyasını bir kez çalıştırın.

Veri topladığınız bir site ara sertifikasını göndermiyorsa o ara sertifikayı, onu yayımlayan CA'nın kendi sitesinden indirip birleşik dosyaya ekleyin (yalnızca yaprak gönderen test sunucumuz bu sayede geçti) ve site sahibine haber verin.

Node.js ve npm'de nasıl çözülür?#

npm, Node.js'in hata kodunu basar:

npm error code UNABLE_TO_GET_ISSUER_CERT_LOCALLY
npm error errno UNABLE_TO_GET_ISSUER_CERT_LOCALLY
npm error request to https://localhost:47443/demo-pkg failed, reason: unable to get local issuer certificate

Node.js, NODE_EXTRA_CA_CERTS değişkeninde adı verilen dosyadaki kökleri kendi yerleşik listesine ekler (Node.js dokümantasyonu). npm Node.js üzerinde çalıştığı için tek bir değişken ikisini de düzeltir:

export NODE_EXTRA_CA_CERTS="$PWD/corp-root.pem"
npm view demo-pkg version --registry https://localhost:47443/

İkinci komut 1.0.0 yazdı (PowerShell'de: $env:NODE_EXTRA_CA_CERTS = "C:\certs\corp-root.pem"). Node.js bu değişkeni yalnızca açılışta okur; çalışan bir betiğin içinden ayarlamak işe yaramaz.

npm'in kendi cafile ayarı ise güvenilen listeye ekleme yapmaz, onun yerine geçer. İçinde yalnızca şirket kökü varken genel kayıt deposuna giden isteğimiz düştü:

npm error request to https://registry.npmjs.org/left-pad failed, reason: unable to get local issuer certificate

Kök zaten sistem deposundaysa Node.js o depoyu doğrudan okuyabilir: --use-system-ca seçeneği Node.js 23.8.0'da, NODE_USE_SYSTEM_CA=1 değişkeni 24.6.0 ve 22.19.0'da geldi; ikisi de testimizde npm ile çalıştı (NODE_OPTIONS=--use-system-ca). Node.js üzerine kurulu yapay zekâ kodlama asistanları da aynı değişkenleri okur; Claude Code'un dokümantasyonu şirket CA'ları için NODE_EXTRA_CA_CERTS değişkenini gösterir.

Git'te nasıl çözülür?#

OpenSSL altyapısıyla çalışan Git, curl'ün hata metnini aynen aktarır:

fatal: unable to access 'https://localhost:47443/repo.git/': SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)

Windows'ta Git'in Windows deposunu kullanmasını sağlayın. Git for Windows yükleyicisi "Use the OpenSSL library" (OpenSSL kütüphanesini kullan) ve "Use the native Windows Secure Channel library" (Windows'un yerleşik Secure Channel kütüphanesini kullan) seçeneklerini sunar; tercihinizi sonradan da değiştirebilirsiniz:

git config --global http.sslBackend schannel

Kök orada da yoksa Schannel, SEC_E_UNTRUSTED_ROOT (0x80090325) hatasını sistem dilindeki iletiyle verir; Türkçe Windows'ta bu ileti "Sertifika zinciri güvenilmeyen bir yetkili tarafından verildi." şeklindedir. Schannel, http.schannelUseSSLCAInfo ayarlanmadıkça http.sslCAInfo ayarını yok sayar.

macOS'te, Linux'ta ya da OpenSSL altyapısında Git'e yalnızca tek bir sunucu için bir dosya gösterin:

git config --global http.https://git.example.com/.sslCAInfo /path/to/corp-root.pem

Testimizde ayarlanan host TLS aşamasını geçti, başka bir host hata vermeyi sürdürdü, github.com ise çalışmaya devam etti. Ağ geçidi her siteyi denetliyorsa Schannel'i ya da birleşik bir dosyayı (Git'in CA paketi artı şirket kökü) kullanın.

curl'de nasıl çözülür?#

Bu hatanın curl'deki numarası 60'tır. Kullandığımız curl 8.21.0 bunu aşağıdaki gibi yazıyor; başka derlemeler SSL certificate problem: unable to get local issuer certificate yazar:

curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html

• --cacert corp-root.pem doğrulamayı o dosyaya göre yapar ve varsayılan CA paketinin yerine geçer; genel siteleri de çağırıyorsanız birleşik dosya kullanın.
• --ca-native (curl 8.2.0 ve sonrası) sistem deposunu Windows'taki OpenSSL derlemelerine, Apple'ın SecTrust desteğiyle derlendiğinde de macOS'e ekler.
• Windows'un kendi curl.exe'si Schannel'i ve Windows deposunu kullanır. İptal (revocation) bilgisi yayımlamayan özel bir CA ile schannel: the revocation status is unknown hatasında durur; --ssl-revoke-best-effort bu eksikliği kabul eder ve zinciri yine denetler.
• --proxy-cacert bir HTTPS proxy'yi, yani https:// ile başlayan bir proxy URL'siyle bağlanılan proxy'yi doğrular. Düz http:// proxy'nin kendi sertifikası yoktur; iki kurulumu da cURL ile Proxy Nasıl Kullanılır? yazısında anlattık.

Üretim ortamında doğrulamanın asla atlanmaması gerektiğini curl projesinin SSL sertifika doğrulaması sayfası da önemle vurguluyor.

verify=False, -k ve NODE_TLS_REJECT_UNAUTHORIZED=0 neden çözüm değildir?#

Bu ayarlar zinciri onarmaz, denetlemeyi bırakır. İstemci artık her ad için her sertifikayı kabul eder; aynı ağda trafiğinizi okumak isteyen birinin sunduğu sertifikayı da. Node.js dokümantasyonu NODE_TLS_REJECT_UNAUTHORIZED=0 ayarını açıkça güvensiz diye niteler. Git testimizde http.sslVerify=false hiçbir uyarı vermeden sunucuya ulaştı; yani bozuk kurulum olduğu gibi kalır. Bu ayarlar yayılır da: kabuk profiline yazılan bir değişken her Node.js programına ulaşır, test için yazılan bir verify=False de sonunda üretime gider.

Kendi sunucunuzdan eksiksiz zincir nasıl gönderilir?#

Yaprak sertifikayı ve ardından bütün ara sertifikaları yapılandırın, kökü dışarıda bırakın. Bu sıra nginx'te ssl_certificate dosyasıyla kurulur: dosya önce sunucu sertifikasını, sonra ara sertifikaları içerir (nginx dokümantasyonu); sıra yanlışsa nginx key values mismatch hatasıyla açılmaz. Certbot bu iş için fullchain.pem dosyasını yazar, cert.pem ise yalnızca yaprak sertifikayı içerir; Apache 2.4.8 ve sonrası SSLCertificateFile için fullchain.pem alır. Dışarıdan openssl s_client -connect alanadiniz:443 -servername alanadiniz -showcerts ile denetleyin: 0 ve 1 kayıtlarını ve Verify return code: 0 (ok) sonucunu görmelisiniz.

2026'daki iki değişiklik bu denetimi otomatikleştirmeye değer kılıyor. CA/Browser Forum'un Temel Gereksinimleri (Baseline Requirements), 15 Mart 2026'dan beri genel sertifikaların ömrünü en fazla 200 günle sınırlıyor (Mart 2027'den itibaren 100, Mart 2029'dan itibaren 47 gün); yenilemeler sıklaşıyor ve her yenileme, yanlış dosyanın kurulması için bir fırsat daha demek. Let's Encrypt de 27 Mayıs 2026'da varsayılan profilini, tanıdık ISRG köklerine çapraz imzalarla bağlanan Generation Y ara sertifikalarına geçirdi. Windows için sertifika istemcisi geliştiren Certify The Web, Windows sunucularının yeni köklere giden kısa zinciri gönderebildiğini ve eski istemcilerin bu zinciri doğrulayamadığını belgeliyor.

Bu hataya bir proxy yol açabilir mi?#

Yalnızca trafiğin şifresini çözen bir proxy yol açabilir. HTTP proxy üzerinden yapılan bir https:// isteğinde istemci önce CONNECT host:443 gönderir, proxy de şifreli baytları olduğu gibi aktarır; düz tünelimizin gösterdiği gibi doğruladığınız sertifika sitenin kendi sertifikasıdır. Proxynet'in ağ geçitleri de düz tünel olarak çalışır: HTTPS Proxy bağlantısı için bilgisayarınıza kök sertifika kurmanız gerekmez.

Bir Residential Proxy havuzu üzerinden web scraping (veri kazıma) yaptığınızda çıkış adresi değişir ama sitenin sertifikası değişmez; bu yüzden bir hedefteki zincir hatası sizi her çıkışta izler ve IP döndürmek onu düzeltmez.

Bu hatayla nerelerde karşılaşırsınız?#

• Şirket bilgisayarında paket kurulumu: npm, pip ve yarn, TLS denetimi yapan bir ağ geçidinin arkasında hata verir; tarayıcı ise çalışır.
• CI çalıştırıcıları ve Docker derlemeleri: konteynerin kendi güven deposu vardır, şirket kökünün imajın içine girmesi gerekir.
• Yapay zekâ kodlama asistanları: Node.js üzerine kurulu komut satırı araçları API'lerine aynı ağ geçidinden bağlanır.
• API istemcileri: Postman'de Settings (Ayarlar) penceresinde Certificates (Sertifikalar) sekmesine geçin, CA certificates (CA sertifikaları) anahtarını açıp PEM dosyasını seçin.
• Veri kazıma betikleri: ara sertifikasını göndermeyen bir site tarayıcıda açılır, her betikte hata verir.
• İç servisler: şirket CA'sının imzaladığı paneller ve Git sunucuları.

Sık yapılan hatalar#

• REQUESTS_CA_BUNDLE değişkenini, npm'in cafile ayarını ya da --cacert seçeneğini yalnızca şirket köküne yönlendirmek. Üçü de varsayılan listenin yerine geçer.
• Yanlış sertifikayı eklemek. Dosyada bir sitenin yaprak sertifikası değil, BT ekibinin yayımladığı kök bulunmalıdır.
• Sertifikayı ikili DER biçiminde kaydetmek. Bu ayarlar PEM'i, yani -----BEGIN CERTIFICATE----- ile başlayan metin biçimini bekler.
• NODE_EXTRA_CA_CERTS değişkenini betiğin içinde ayarlamak. Node.js onu yalnızca açılışta okur.
• fullchain.pem yerine cert.pem kurmak. Tarayıcılar çalışmaya devam edebilir, bu yüzden kimse fark etmez.

Karar rehberi#

Sıkça sorulan sorular#

Site tarayıcıda açılıyor ama Python, curl ya da Node.js'te neden hata veriyor?#

Tarayıcı ile araç farklı güven depolarını okur ve tarayıcılar eksik zincirleri kendileri tamamlar. Betik ise kendi CA paketini okur ve bunların hiçbirini yapmaz; hangisinin geçerli olduğunu görmek için zinciri openssl s_client ile inceleyin.

verify=False, -k ya da NODE_TLS_REJECT_UNAUTHORIZED=0 kullanmak güvenli mi?#

Çözüm olarak değil. Bu ayarlar bütün sertifika denetimlerini kapatır; sizinle sunucu arasındaki herkes trafiği okuyabilir ya da değiştirebilir. En fazla kendi test sunucunuza karşı tek bir komut için kullanın.

"Unable to get local issuer certificate" ile "self-signed certificate in certificate chain" arasındaki fark nedir?#

İkisinde de zincir, aracınızın güvenmediği bir kökte biter. Birincisinde kök gönderilmemiş ve yerelde de bulunamamıştır; ikincisinde sunucu ya da bir proxy kökün kendisini göndermiştir. Çözüm aynıdır.

Şirketimin kök sertifikasını nereden alırım?#

BT ya da güvenlik ekibinizden. Yönetilen bir dizüstü bilgisayarda kök zaten sistem deposundadır; truststore, --use-system-ca ve Schannel bu yüzden dosya olmadan çalışır. Kökü asla resmî olmayan bir kaynaktan almayın: güvenilen bir kök, her alan adı için sertifika imzalayabilir.

Aynı makinede pip çalışırken Requests neden hata veriyor?#

24.2 sürümünden beri pip, certifi'nin yanında sistem sertifikalarını da denetler; Requests ise yalnızca certifi'yi okur. Betiğinize aynı davranışı truststore kazandırır.

Bir proxy "unable to get local issuer certificate" hatasına yol açabilir mi?#

Yalnızca trafiğin şifresini çözen bir proxy: şirket ağ geçidi, HTTPS tarama yapan bir antivirüs ya da hata ayıklama proxy'si. CONNECT kullanan bir tünel proxy'si sitenin kendi sertifikasını değiştirmeden geçirir.

Özet#

Bu hata, istemcinizin sunucu sertifikasını güvendiği bir köke bağlayamadığı anlamına gelir. Nedenini openssl s_client söyler: tek başına duran bir yaprak sertifika sunucuyu, şirket adı taşıyan bir imzalayan TLS denetimini, temiz bir genel zincir de aracınızın kendi CA paketini gösterir. Doğru kökü aracın baktığı yere ekleyin ve doğrulamayı açık tutun. Sertifikalara dokunmadan trafiği tünelleyen proxy'ler için proxy hizmetlerimize göz atın.