--- title: "Unable to Get Local Issuer Certificate Hatası Nasıl Çözülür?" description: "Unable to get local issuer certificate, aracınızın sunucu zincirini imzalayan CA'yı bulamadığını gösterir. Üç neden; Python, npm, Git ve curl için çözümler." url: https://proxynet.io/tr/blog/unable-to-get-local-issuer-certificate date: 2026-10-06 author: "Acar Diveroli" category: "Nasıl Yapılır, Web Scraping" lang: tr --- # 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. > **Not: Kısa cevap** > > İstemciniz, sunucunun gönderdiği sertifika zincirini kendi güvendiği kökler listesindeki, yani yerel güven deposundaki (trust store) bir köke bağlayamadı. Üç neden var: sunucu ara sertifikasını göndermiyordur; TLS denetimi yapan bir proxy ya da antivirüs, trafiği aracınızda bulunmayan bir kökle yeniden imzalıyordur; ya da aracınız sistem deposu yerine kendi CA paketini okuyordur. Doğru kökü aracın baktığı yere ekleyin (`truststore` ya da `REQUESTS_CA_BUNDLE`, `NODE_EXTRA_CA_CERTS`, Schannel ya da `http.sslCAInfo`, `--cacert`) veya sunucunun zincirini düzeltin. `verify=False` ve `-k` hatayı yalnızca gizler. ## "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](https://www.rfc-editor.org/rfc/rfc8446.html#section-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. | Sunucunun gönderdiği | Python (`ssl`, Requests) | Node.js ve npm | curl ve Git (OpenSSL) | |---|---|---|---| | Yaprak + ara sertifika | `unable to get local issuer certificate` | `UNABLE_TO_GET_ISSUER_CERT_LOCALLY` | `unable to get local issuer certificate (20)` | | Yalnız yaprak sertifika | `unable to get local issuer certificate` | `UNABLE_TO_VERIFY_LEAF_SIGNATURE` | `unable to get local issuer certificate (20)` | | Yaprak + ara + kök sertifika | `self-signed certificate in certificate chain` | `SELF_SIGNED_CERT_IN_CHAIN` | `self-signed certificate in certificate chain (19)` | 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](/tr/blog/mitm-proxy) 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: ```bash openssl s_client -connect localhost:47444 -servername localhost -showcerts 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](https://pip.pypa.io/en/stable/topics/https-certificates/)). 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: ```text 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](https://nodejs.org/api/cli.html#node_extra_ca_certsfile)). npm Node.js üzerinde çalıştığı için tek bir değişken ikisini de düzeltir: ```bash 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ü: ```text 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: ```text 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: ```bash 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: ```bash 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: ```text 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?](/tr/blog/curl-proxy) yazısında anlattık. Üretim ortamında doğrulamanın asla atlanmaması gerektiğini curl projesinin [SSL sertifika doğrulaması](https://curl.se/docs/sslcerts.html) 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](https://nginx.org/en/docs/http/configuring_https_servers.html#chains)); 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](https://proxynet.io/tr/https-proxy) bağlantısı için bilgisayarınıza kök sertifika kurmanız gerekmez. Bir [Residential Proxy](https://proxynet.io/tr/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 | Ne görüyorsunuz | Ne yapmalı | |---|---| | Yalnızca `0` kaydı, genel bir imzalayan | Site sahibi eksiksiz zinciri sunmalı; o zamana kadar ara sertifikayı CA paketinize ekleyin | | İmzalayan şirketiniz, antivirüs ya da hata ayıklama aracı | O kökü BT ekibinden alın, her araca ayrı ayrı ekleyin | | Zincir genel ve `0 (ok)`, tek bir araç hata veriyor | Aracın sistem deposunu okumasını sağlayın: truststore, `--use-system-ca`, Schannel | | npm hata veriyor | `NODE_EXTRA_CA_CERTS`; `cafile` yalnızca eksiksiz bir CA paketiyle | | Git tek bir iç sunucuda hata veriyor | O host için `http..sslCAInfo` | | curl hata veriyor | Birleşik dosyayla `--cacert` ya da `--ca-native` | ## 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](/tr/proxy) göz atın.