unable to get local issuer certificate çözümü

unable to get local issuer certificate hatası ne demek?

SSL certificate problem: unable to get local issuer certificate mesajı, istemcinin sunucu sertifikasını imzalayan sertifikayı bulamadığını söyler. İstemci zinciri güvendiği bir köke kadar kuramaz ve bu yüzden bağlantıyı keser. Sunucu sizinse sebep büyük olasılıkla sizin yapılandırmanızdır: sunucu kendi sertifikasını gönderiyor ama ara sertifikayı göndermiyor.

Bu mesajı curl, git, PHP ya da bir dağıtım betiği verebilir. Git ve PHP'nin curl eklentisi HTTPS bağlantısını libcurl ile kurar, bu yüzden teşhis yolu da aynıdır. Önce en sık nedeni düzeltiyoruz: Certbot dosyalarının yanlış kullanılması. Sonra hatayı kendi makinenizde, yalnızca localhost üzerinde üretiyor ve iki ayrı araçla çözüyoruz.

Sertifika zinciri nasıl doğrulanır?

TLS (transport layer security, aktarım katmanı güvenliği) sertifikası tek başına doğrulanmaz. Alan adınızı taşıyan sertifikaya yaprak sertifika (leaf) denir. Onu bir ara sertifika (intermediate CA) imzalar. Ara sertifikayı da bir kök sertifika (root CA) imzalar. CA (certificate authority), sertifika yetkilisi demektir. İstemci yalnızca köke güvenir, çünkü kök onun güven deposunda durur.

Ubuntu'da güven deposu tek bir dosyadır: /etc/ssl/certs/ca-certificates.crt. update-ca-certificates komutu bu dosyayı /etc/ca-certificates.conf içinde etkin olan sertifikalardan üretir. İstemci ara sertifikayı normalde TLS el sıkışması sırasında sunucudan alır.

OpenSSL 3.0 belgesi zincirin nasıl kurulduğunu açıkça anlatır. Eksik bir imzalayan yalnızca iki yerde aranır: güven deposunda ve size verilen güvenilmeyen (untrusted) sertifika listesinde. Bu listedeki sertifikalar zinciri kurmaya yardım eder ama hiçbir zaman güven çapası (trust anchor) olmaz. Ara sertifika ne depoda ne de elinizdeyse zincir yarıda kalır. OpenSSL bu durumu X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY koduyla bildirir. Ubuntu 24.04'ün kullandığı OpenSSL 3.0.13 kaynak kodunda bu kodun metni tam olarak unable to get local issuer certificate şeklindedir. curl, OpenSSL'den gelen bu metni kendi mesajının sonuna ekler.

En sık neden: fullchain.pem yerine cert.pem kullanmak

Certbot her sertifika için /etc/letsencrypt/live/<alan-adı>/ altında birkaç dosya bırakır. Certbot belgesine göre cert.pem yalnızca sunucu sertifikasıdır. chain.pem ara sertifikaları tutar. fullchain.pem ise önce sunucu sertifikasını, ardından ara sertifikaları içerir. Belge, nginx'in ssl_certificate yönergesi ve Apache 2.4.8 ve sonrasının SSLCertificateFile yönergesi için gereken dosyanın fullchain.pem olduğunu yazar. Yalnızca cert.pem verirseniz, yine belgeye göre bazı istemciler siteyi güvenilmez bulur.

Bu hata kolay yapılır, çünkü cert.pem adı doğru dosya gibi görünür. Tarayıcı siteyi açmaya devam edebilir. Bu yüzden sorun çoğu zaman ancak curl ya da PHP'den gelen bir istek başarısız olunca fark edilir. Aynı durum, yenileme sonrası cert.pem dosyasını başka bir servise kopyalayan dağıtım betiklerinde de olur. O servise de zincirin tamamını verin.

nginx için doğru yapılandırma şudur:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

nginx belgesine göre ara sertifikalar aynı dosyada durmalıdır: önce asıl sertifika, sonra ara sertifikalar. chain.pem dosyasını ssl_trusted_certificate yönergesine yazmak sorunu çözmez. nginx belgesi, bu listedeki sertifikaların istemciye gönderilmediğini söyler. Değişikliği sınayıp yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Apache için SSLCertificateFile satırı fullchain.pem dosyasını göstermelidir:

SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Apache 2.4 belgesine göre SSLCertificateFile 2.4.8 sürümünden beri ara sertifikaları da okur. Sıra yapraktan köke doğrudur. Aynı belge SSLCertificateChainFile yönergesinin 2.4.8 ile eskidiğini yazar. Sürümünüzü görün, sonra yapılandırmayı sınayıp yükleyin:

apache2 -v
sudo apachectl configtest && sudo systemctl reload apache2

Sunucunun zinciri gönderip göndermediğini kontrol edin

Aşağıdaki komut, sunucunun el sıkışmada gönderdiği sertifikaları sayar. example.com yerine kendi alan adınızı, 203.0.113.10 yerine sunucunuzun genel IP adresini yazın. Adresi açıkça vermek DNS'i atlar, böylece önünüzde bir CDN ya da eski bir DNS kaydı olsa bile tam olarak bu sunucuyu sınarsınız.

openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Sonuç 1 ise sunucu yalnızca yaprak sertifikayı gönderiyor. Sonuç 2 veya daha fazlaysa zincir gidiyor. Ardından istemci tarafını deneyin: curl -sS -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/ && echo tamam. curl belgesine göre --resolve, verilen ad ve port için DNS yerine bu adresi kullanır. Sıra da önemlidir. TLS 1.3 tanımına (RFC 8446) göre gönderenin kendi sertifikası listede ilk sırada olmak zorundadır, sonraki her sertifika da bir öncekini imzalamalıdır.

Kurulumu sıfırdan yapıyorsanız Ubuntu 24.04'te nginx için Certbot ile Let's Encrypt kurulumu ve Ubuntu 24.04'te Apache için Certbot kurulumu rehberleri adımların tamamını anlatır.

Tarayıcı siteyi açıyor, curl ve PHP neden açmıyor?

Tarayıcılar eksik ara sertifikayı başka yollardan bulabilir. Mozilla'nın wiki sayfasına göre Firefox, yeni ve güncellenmiş ara sertifikaları günde bir kez indirir ve profilinize yükler. Sonuç, o ara sertifikayı kullanan bir siteyi daha önce ziyaret etmişsiniz gibidir. Chromium'un kaynak kodu ise sertifikadaki AIA (authority information access, yetkili bilgi erişimi) uzantısını okur. RFC 5280'e göre bu uzantı, imzalayanın sertifikasına giden bir adres taşıyabilir. Chromium'un kodu bu adresten ara sertifikayı indirir. Bu, belgelenmiş bir garanti değil, kodun bugünkü davranışıdır.

curl ve OpenSSL tarafında böyle bir açıklama yoktur. OpenSSL'in doğrulama belgesi zinciri yalnızca güven deposundan ve verilen sertifikalardan kurmayı anlatır. AIA üzerinden indirmeden söz etmez. Aşağıdaki laboratuvarın ilk curl denemesi, kendi makinenizde ne olduğunu gösterir. PHP de doğrulama yapar: PHP belgesine göre verify_peer bağlam seçeneği varsayılan olarak açıktır.

Sonuç basittir. Tarayıcıda açılan bir site, zincirin doğru gönderildiğini kanıtlamaz. Zinciri göndermek sunucunun işidir.

Laboratuvar: hatayı localhost üzerinde üretin

Bu bölüm yalnızca loopback adresini (127.0.0.1) kullanır. Dışarıya port açmanız gerekmez. Stok Ubuntu paketleri yeterlidir.

sudo apt update && sudo apt install -y openssl curl ca-certificates
openssl version
curl --version | head -n 1
mkdir -p ~/tls-lab && cd ~/tls-lab

Ekim 2026 itibarıyla packages.ubuntu.com, Ubuntu 24.04 için OpenSSL 3.0.13-0ubuntu3.16 ve curl 8.5.0-2ubuntu10.15 paketlerini listeler. Ubuntu 26.04 ise OpenSSL 3.5.5 ve curl 8.18.0 ile gelir. Hata metinlerini karşılaştırırken kendi openssl version çıktınıza bakın, çünkü metinler sürümler arasında değişti.

Kök, ara ve yaprak sertifikayı oluşturun

Önce kök CA:

openssl req -x509 -newkey rsa:2048 -noenc -days 30 -keyout root.key -out root.pem -subj '/CN=Lab Root CA' -addext 'basicConstraints=critical,CA:TRUE' -addext 'keyUsage=critical,keyCertSign,cRLSign'

-noenc anahtarı şifresiz bırakır. OpenSSL 3.0 belgesine göre eski -nodes seçeneği 3.0'dan beri kullanımdan kalkmıştır. -addext uzantıyı doğrudan sertifikaya ekler. x509v3 belgesine göre bir CA sertifikası, CA değeri TRUE olan bir basicConstraints uzantısı taşımak zorundadır. Bu yüzden onu açıkça yazıyoruz.

Sonra ara CA. Önce bir CSR (certificate signing request, sertifika imzalama isteği) üretilir, sonra kök onu imzalar:

openssl req -newkey rsa:2048 -noenc -keyout int.key -out int.csr -subj '/CN=Lab Intermediate CA'
cat > int.ext <<'EOF'
basicConstraints = critical, CA:TRUE
keyUsage = critical, keyCertSign, cRLSign
EOF
openssl x509 -req -in int.csr -CA root.pem -CAkey root.key -CAcreateserial -days 30 -extfile int.ext -out int.pem

openssl x509 -req, CSR içindeki uzantıları -copy_extensions verilmedikçe yok sayar. Bu yüzden uzantıları ayrı bir -extfile dosyasına yazıyoruz. -days vermezseniz belgeye göre sertifika 30 gün geçerli olur. Biz yine de açıkça yazıyoruz.

En son yaprak sertifika. SAN (subject alternative name) uzantısı, sertifikanın localhost adına verildiğini söyler:

openssl req -newkey rsa:2048 -noenc -keyout leaf.key -out leaf.csr -subj '/CN=localhost'
cat > leaf.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:localhost
EOF
openssl x509 -req -in leaf.csr -CA int.pem -CAkey int.key -CAcreateserial -days 30 -extfile leaf.ext -out leaf.pem
openssl x509 -in leaf.pem -noout -subject -issuer

Son komutun çıktısında subject satırı localhost, issuer satırı Lab Intermediate CA adını taşımalıdır. Yaprağı kök değil, ara sertifika imzaladı. Hatanın bütün mantığı bu ayrıntıdadır.

Birinci test: openssl verify, -untrusted ile ve olmadan

openssl verify -CAfile root.pem leaf.pem; echo "çıkış kodu: $?"
openssl verify -CAfile root.pem -untrusted int.pem leaf.pem; echo "çıkış kodu: $?"

İlk komutta elinizde yalnızca kök vardır. Yaprağın imzalayanı ara sertifikadır ve o ne güvenilen dosyada ne de başka bir listededir. İlk komutun hata satırını okuyun ve kendi sürümünüzün yazdırdığı metni not edin. İkinci komutta -untrusted int.pem eksik halkayı verir. Ara sertifika yine güven çapası değildir. Zincir yaprak, ara ve kök olarak kurulur ve güven yine root.pem dosyasından gelir. İki komutun çıkış kodunu karşılaştırın.

İkinci test: curl ile gerçek bir TLS sunucusu

openssl s_server küçük bir test sunucusudur. OpenSSL 3.0 belgesine göre -accept dinlenecek adresi ve portu alır. -cert_chain ise zinciri kurmak için kullanılacak güvenilmeyen sertifikaları alır. -www her isteğe bir durum sayfasıyla yanıt verir. Önce iki yardımcı fonksiyon tanımlayın:

dene() {
  curl -sS -o /dev/null --resolve localhost:4433:127.0.0.1 "$@" https://localhost:4433/
  echo "curl çıkış kodu: $?"
}
zincir() {
  openssl s_client -connect 127.0.0.1:4433 -servername localhost </dev/null 2>/dev/null | sed -n '/^Certificate chain/,/^---$/p'
}

dene, localhost adını 127.0.0.1 adresine bağlayarak curl çalıştırır ve çıkış kodunu yazdırır. zincir, sunucunun gönderdiği sertifikaları listeler. Her sertifika için bir s: (subject, sahibi) ve bir i: (issuer, imzalayanı) satırı görürsünüz.

A durumu: sunucu yalnızca yaprak sertifikayı gönderir. Bu, nginx'e cert.pem vermekle aynı şeydir.

openssl s_server -accept 127.0.0.1:4433 -key leaf.key -cert leaf.pem -www -quiet &
SUNUCU=$!; sleep 1
zincir
dene --cacert root.pem
kill $SUNUCU

B durumu: sunucu ara sertifikayı da gönderir. Bu, fullchain.pem kullanmakla aynı şeydir.

openssl s_server -accept 127.0.0.1:4433 -key leaf.key -cert leaf.pem -cert_chain int.pem -www -quiet &
SUNUCU=$!; sleep 1
zincir
dene --cacert root.pem
kill $SUNUCU

İki durumda da curl aynı köke güvenir. Değişen tek şey sunucunun gönderdiği sertifika sayısıdır. zincir çıktısında A durumunda bir, B durumunda iki girdi olmalıdır. Durumlar arasında curl çıktısının nasıl değiştiğine bakın. A durumunda curl'ün yazdırdığı satır, bu sayfaya getiren mesajla aynıysa sorunu yeniden ürettiniz demektir. s_server başlamazsa 4433 portunu başka bir süreç kullanıyor olabilir. Linux'ta bir portun açık olup olmadığını kontrol etme rehberindeki ss komutuyla bakın.

Çıkış kodunu curl'ün belgelenmiş listesiyle karşılaştırın. 60 numaralı kod, sunucu sertifikasının bilinen CA'larla doğrulanamadığı anlamına gelir. 77, CA dosyasının okunamadığı anlamına gelir. Bu kodu genelde yanlış bir --cacert yolu üretir. 35, el sıkışmanın kendisinin başarısız olduğunu söyler. Bunlar farklı sorunlardır, bu yüzden betiklerinizde ayrı ayrı ele alın.

Kendinden imzalı iki durum

C durumu: sunucu sertifikası kendini imzalamıştır. Kök ya da ara sertifika yoktur. curl bu kez sistemin güven deposunu kullanır, çünkü --cacert vermiyoruz.

openssl req -x509 -newkey rsa:2048 -noenc -days 30 -keyout self.key -out self.pem -subj '/CN=localhost' -addext 'subjectAltName=DNS:localhost'
openssl verify self.pem; echo "çıkış kodu: $?"
openssl s_server -accept 127.0.0.1:4433 -key self.key -cert self.pem -www -quiet &
SUNUCU=$!; sleep 1
zincir
dene
kill $SUNUCU

D durumu: sunucu ara sertifikayla birlikte kökü de gönderir, ama istemci o köke güvenmez. Özel bir CA kullanan iç servisler ve bağlantıyı yeniden imzalayan ara cihazlar bu duruma benzer.

cat int.pem root.pem > int-root.pem
openssl verify -untrusted int-root.pem leaf.pem; echo "çıkış kodu: $?"
openssl s_server -accept 127.0.0.1:4433 -key leaf.key -cert leaf.pem -cert_chain int-root.pem -www -quiet &
SUNUCU=$!; sleep 1
zincir
dene
dene --cacert root.pem
kill $SUNUCU

D durumundaki son dene satırı aynı köke güvenir ve sonucu değiştirir. Sunucunun gönderdiği kök kopyası tek başına güven yaratmaz. Güven yalnızca istemcinin kendi deposundan gelir. Laboratuvar bitince anahtarları silin: cd ~ && rm -rf ~/tls-lab.

Üç hatayı birbirinden nasıl ayırırsınız?

Metinler sürüme göre değişir. OpenSSL 1.1.1 kaynağında self signed certificate ve self signed certificate in certificate chain yazar. OpenSSL 3.0.13 kaynağında aynı iki metin tireyle yazılır: self-signed certificate ve self-signed certificate in certificate chain. unable to get local issuer certificate iki sürümde de aynıdır. Ubuntu 26.04'teki OpenSSL 3.5'in metinlerini burada doğrulamadık, kendi çıktınıza bakın. Bir betikte arama yapacaksanız iki yazımı da yakalayan bir desen kullanın:

curl -sS -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/ 2>&1 | grep -iE 'local issuer|self.signed'

Daha sağlam yol, metin yerine yapıya bakmaktır. İki soru yeterlidir. Sunucu kaç sertifika gönderiyor? Gönderilen son sertifikanın s: ve i: satırları aynı mı? Üretimde zincir fonksiyonundaki s_client komutunu kendi alan adınızla çalıştırın.

• Tek sertifika var ve s: ile i: farklı: imzalayan eksik. Bu, unable to get local issuer certificate ailesidir. Sunucu zinciri göndermiyordur ya da imzalayan CA sizin deponuzda yoktur.
• Tek sertifika var ve s: ile i: aynı: sertifika kendini imzalamış. OpenSSL bunu X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT koduyla bildirir. Addaki depth zero ifadesi, sorunun zincirin en altındaki sunucu sertifikasında olduğunu söyler.
• Birden fazla sertifika var ve sonuncusunda s: ile i: aynı: zincir sonuna kadar kuruldu, ama en üstteki köke güvenmiyorsunuz. Bu X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN durumudur. OpenSSL 1.1.1 belgesi bunu, zincirin güvenilmeyen sertifikalarla kurulabildiği ama kökün yerelde bulunamadığı durum olarak tanımlar.
• Birden fazla sertifika var ve sonuncusunda s: ile i: farklı: zincir kısmen gönderildi ve en üstteki imzalayan deponuzda yok. Bu da imzalayan eksik ailesidir.

Çözüm aileye göre değişir. Sunucu sizinse ve zincir eksikse, sunucuya tam zinciri verin. Kök sizin özel CA'nızsa, onu istemcinin güven deposuna ekleyin. Sunucu sertifikası kendinden imzalıysa ve yalnızca test içinse, onu istemciye --cacert ile verin. Kendinden imzalı sertifikanın ne zaman yeterli olduğunu Ubuntu'da kendinden imzalı sertifika oluşturma rehberi anlatır.

Özel CA, PHP ve Git: istemci tarafındaki çözümler

Kendi CA'nızı kullanıyorsanız kalıcı çözüm, kökü sistem deposuna eklemektir. Adımlar kendi CA'nızı Ubuntu güven deposuna ekleme rehberindedir. Bu yöntem curl, PHP ve Git'i tek seferde düzeltir, çünkü üçü de aynı paketi okuyabilir.

curl'de tek seferlik çözüm --cacert seçeneğidir. curl belgesine göre bu dosya PEM biçiminde olmalıdır, birden fazla CA içerebilir ve curl'ün varsayılan CA dosyasının yerine geçer. Yani o komut için yalnızca bu dosyadaki CA'lara güvenilir. CURL_CA_BUNDLE ortam değişkeni de aynı işi görür.

PHP'de iki ayar vardır. PHP belgesine göre curl eklentisi CA dosyasını curl.cainfo ayarından alır ve bu değer mutlak bir yol olmak zorundadır. OpenSSL eklentisi ve akış sarmalayıcıları ise openssl.cafile ve openssl.capath ayarlarını kullanır. Mevcut değerleri görün:

php -i | grep -E 'curl.cainfo|openssl.cafile|openssl.capath'

Bir değer eski ya da yanlış bir dosyayı gösteriyorsa, onu sistem paketine çevirin:

curl.cainfo = /etc/ssl/certs/ca-certificates.crt
openssl.cafile = /etc/ssl/certs/ca-certificates.crt

Sonra PHP-FPM servisini yeniden başlatın. Servis adı PHP sürümüne göre değişir. systemctl list-units | grep php ile bulun.

Git'te http.sslCAInfo ayarı CA dosyasını gösterir. Bu ayarı yalnızca bir sunucu için koyarsanız diğer siteler etkilenmez:

git config --global http.https://git.sirket.example/.sslCAInfo /home/kullanici/sirket-kok.pem

Git belgesine göre http.sslVerify varsayılan olarak açıktır. GIT_SSL_CAINFO ve GIT_SSL_CAPATH ortam değişkenleri de aynı ayarları tek komut için değiştirir.

Windows'ta kurumsal TLS denetimi ve antivirüs taraması

Hata Windows geliştirme makinenizde çıkıyor ve sunucuda çıkmıyorsa, sorun aradaki bir yazılım olabilir. Bazı şirket ağları ve bazı antivirüs ürünleri HTTPS trafiğini açıp kendi kökleriyle yeniden imzalar. Bunu varsaymayın, aşağıdaki adımlarla kendiniz kontrol edin:

1. Aynı komutu başka bir ağdan deneyin, örneğin telefonunuzun hotspot bağlantısından. Hata yalnızca şirket ağında çıkıyorsa, trafik arada bir cihazdan geçiyor olabilir.
2. Aynı siteyi tarayıcıda açın ve sertifika ayrıntılarında en üstteki kökün adını okuyun. Bu ad sitenin gerçek CA'sı yerine şirketinizin ya da antivirüs ürününüzün adını taşıyorsa, BT ekibinize sorun.
3. Git for Windows kullanıyorsanız Windows sertifika deposunu deneyin: git config --global http.sslBackend schannel. curl belgesine göre Schannel ile derlenmiş curl, Windows'un kendi CA deposunu kullanır. Şirketinizin kökü o depoya yüklüyse Git onu görür. Git belgesine göre curl çalışma anında arka uç seçimini desteklemiyorsa bu ayar yok sayılır.
4. git ls-remote https://github.com/git/git.git ile tekrar deneyin. Bir şey değişmediyse ayarı geri alın: git config --global --unset http.sslBackend.
5. Antivirüsün HTTPS taramasını kapatmak ya da istisna eklemek ürüne göre değişir. Bunu ürünün kendi belgesine ve şirketinizin kurallarına göre yapın.
6. WSL ya da Linux tarafında aynı kökü BT ekibinizden PEM biçiminde isteyin ve güven deposuna ekleyin.

-k ve sslVerify=false yalnızca teşhis içindir

-k seçeneği tek bir soruyu yanıtlar: sorun güven mi, yoksa başka bir şey mi? Bir kez çalıştırın, sonra silin.

curl -k -sS -o /dev/null -w '%{http_code}\n' --resolve example.com:443:203.0.113.10 https://example.com/
git -c http.sslVerify=false ls-remote https://git.example.com/ekip/proje.git

Bir HTTP durum kodu dönerse ağ, port ve el sıkışma çalışıyor demektir. Geriye yalnızca zincir ve güven deposu kalır. curl belgesi bu seçenek için açıkça uyarır: aktarımı güvensiz yapar ve üretimde doğrulama asla atlanmamalıdır. git -c ayarı yalnızca o komut için geçerlidir. git config --global http.sslVerify false yazmayın, çünkü o ayar siz silene kadar kalır ve her bağlantıyı korumasız bırakır. Şifrelemenin neyi koruduğunu sunucunuzda HTTP ile HTTPS farkı yazısı anlatır.

Ubuntu'nun kök deposunda TÜBİTAK Kamu SM kökü var mı?

Türkiye'deki kamu sistemleriyle konuşan betikler yazıyorsanız bu soru aklınıza gelebilir. packages.ubuntu.com dosya listelerine göre Ubuntu 24.04 ve 26.04 ca-certificates paketleri TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.crt dosyasını içerir. Debian'ın değişiklik günlüğüne göre bu kök pakete 20170717 sürümünde eklendi. Ama dosyanın pakette olması, güven deposunda etkin olduğu anlamına gelmez. Kendi sunucunuzda bakın:

ls /usr/share/ca-certificates/mozilla/ | grep -i tubitak
grep -i tubitak /etc/ca-certificates.conf

update-ca-certificates kılavuzuna göre /etc/ca-certificates.conf içinde ! ile başlayan bir satır o sertifikayı devre dışı bırakır. Satırın başında ! yoksa kök /etc/ssl/certs/ca-certificates.crt paketine girer. Mozilla'nın bu köke bugün güvenip güvenmediği ayrı bir sorudur ve bu komutlar onu yanıtlamaz.

Sık sorulan sorular (FAQ)

curl unable to get local issuer certificate diyor ama tarayıcı siteyi açıyor. Neden?

Tarayıcılar eksik ara sertifikayı kendileri bulabilir. Mozilla'nın wiki sayfasına göre Firefox ara sertifikaları günde bir kez önceden indirir. Chromium'un kaynak kodu ise sertifikadaki AIA adresinden imzalayanı indirir. OpenSSL'in doğrulama belgesi zinciri yalnızca güven deposundan ve verilen sertifikalardan kurmayı anlatır. Bu yüzden sunucu ara sertifikayı göndermezse curl ve PHP başarısız olabilir. Çözüm sunucuya tam zinciri vermektir.

Certbot ile nginx'te cert.pem mi, fullchain.pem mi kullanmalıyım?

fullchain.pem kullanın. Certbot belgesine göre bu dosya sunucu sertifikasını ve ardından ara sertifikaları içerir. nginx'in ssl_certificate yönergesi ve Apache 2.4.8 ve sonrasının SSLCertificateFile yönergesi bu dosyayı ister. cert.pem yalnızca yaprak sertifikadır ve tek başına verilirse bazı istemciler siteyi güvenilmez bulur. Düzelttikten sonra openssl s_client -showcerts çıktısındaki sertifika sayısının 2 veya daha fazla olduğunu kontrol edin.

curl -k ile çalışıyor. Bu bir çözüm mü?

Hayır. -k doğrulamayı atlar, bu yüzden yalnızca sorunun güvenle ilgili olduğunu kanıtlar. curl belgesi bu seçeneğin aktarımı güvensiz yaptığını yazar ve üretimde doğrulamanın atlanmamasını söyler. Bir kez teşhis için çalıştırın, sonra gerçek nedeni düzeltin: sunucuda eksik zincir ya da istemcide eksik kök.

self-signed certificate in certificate chain ile unable to get local issuer certificate arasındaki fark ne?

İlkinde zincir sonuna kadar kurulur ve en üstte kendinden imzalı bir kök vardır, ama istemci o köke güvenmez. Çözüm o kökü güven deposuna eklemektir. İkincisinde zincir yarıda kalır, çünkü bir sertifikanın imzalayanı ne depoda ne de sunucunun gönderdikleri arasındadır. Çözüm genelde sunucuya ara sertifikayı göndermektir. Metne güvenmek yerine openssl s_client çıktısındaki sertifika sayısına ve son sertifikanın s: ile i: satırlarının aynı olup olmadığına bakın.

Git for Windows'ta bu hatayı nasıl düzeltirim?

Önce hatanın yalnızca şirket ağında mı çıktığını ve sertifikadaki kökün kimin adını taşıdığını kontrol edin. Kök şirketinize ya da antivirüs ürününüze aitse git config --global http.sslBackend schannel ile Git'i Windows sertifika deposuna yönlendirmeyi deneyin. curl belgesine göre Schannel derlemeleri Windows'un kendi deposunu kullanır. İşe yaramazsa ayarı git config --global --unset http.sslBackend ile geri alın ve kök sertifikayı BT ekibinizden isteyin.