SSL Certificate Chain Incomplete Hatası Nasıl Çözülür? Eksik Sertifika Zinciri Rehberi

SSL certificate chain incomplete hatası, sunucunun alan adınıza ait SSL/TLS sertifikasını göndermesine rağmen istemcinin doğrulama için ihtiyaç duyduğu bir veya daha fazla ara sertifikayı (intermediate CA) göndermediğini belirtir. Tarayıcıların bir kısmında site açılırken, eski işletim sistemlerinde, API istemcilerinde, mobil uygulamalarda veya ödeme/e-posta entegrasyonlarında sertifika güven hatası görülebilir. Sorun çoğunlukla sertifika yenilemesi sırasında yalnızca sunucu sertifikasının kurulması, yanlış bundle kullanılması ya da CDN/yük dengeleyici üzerindeki ayrı TLS yapılandırmasından kaynaklanır. Bu rehber, zinciri önce güvenli biçimde doğrulamanızı, ardından kullandığınız web sunucusuna göre doğru sertifika dosyasını tanımlamanızı sağlar.

Belirti ve kapsam: Hata hangi katmanda oluşur?

Tarayıcıdaki uyarı metni her zaman aynı değildir. SSL Labs benzeri denetim araçları “Chain issues: Incomplete” gösterebilir; OpenSSL ise doğrulama hatası veya eksik issuer bilgisi döndürebilir. Bazı modern tarayıcılar ara sertifikayı önbellekten ya da AIA kaydından bulabildiği için sorun görünmeyebilir. Bu, sunucu yapılandırmasının doğru olduğu anlamına gelmez.

Özellikle aşağıdaki durumlarda eksik zincir kritik hale gelir:

• Java, .NET, curl veya kurumsal proxy kullanan API istemcileri bağlantıyı reddediyorsa,
• Eski Android, gömülü cihaz veya güncel olmayan işletim sistemlerinde güven hatası oluşuyorsa,
• Sertifika yenilemesinden hemen sonra yalnızca bazı kullanıcılar hata almaya başladıysa,
• CDN, reverse proxy veya load balancer arkasında farklı bir sertifika sunuluyorsa.

SSL certificate chain incomplete hatası için hızlı teşhis özeti

• Doğru alan adı ve doğru TLS uç noktası test edilir; SNI kullanan yapılarda alan adı belirtilmelidir.
• Sunucunun gönderdiği sertifikalar, sertifika otoritesinin sağladığı zincirle karşılaştırılır.
• Sunucu sertifikası ile ara sertifikalar doğru sırada tek bir bundle içinde tanımlanır.
• Yapılandırma sözdizimi test edilir, hizmet kontrollü biçimde yeniden yüklenir.
• Hem harici bağlantı hem de farklı bir istemciyle sertifika yolu doğrulanır.

Önemli: Sertifika yapılandırmasını değiştirmeden önce mevcut sanal ana bilgisayar (vhost), web sunucusu veya panel ayarlarının yedeğini alın. Üretim ortamında yapılandırma hatası HTTPS erişimini kesintiye uğratabilir; değişikliği bakım penceresinde ve mümkünse geri dönüş planıyla yapın.

Olası nedenler

Neden	Tipik sonuç	Doğru yaklaşım
Yalnızca leaf/sunucu sertifikası yüklenmiştir	Issuer sertifikası istemcide bulunamaz	CA tarafından verilen ara sertifikaları ekleyin
Yanlış veya eski CA bundle kullanılmıştır	Zincir doğrulaması kopar ya da yanlış köke gider	Sertifikanın güncel issuer zincirini CA kaynağından alın
Sertifikalar yanlış sıradadır	Bazı istemciler zinciri kuramaz	Leaf, ardından issuer sırasıyla intermediate sertifikaları kullanın
CDN veya yük dengeleyici farklı sertifika sunuyordur	Origin doğruyken dış test başarısız olur	İnternete açık TLS uç noktasını ayrıca düzeltin
Yenileme otomasyonu yalnızca sertifikayı değiştirmiştir	Yenileme sonrası aniden hata oluşur	fullchain/bundle dosya referanslarını yenileme akışında denetleyin

Kök CA sertifikası genellikle sunucunun göndereceği zincire eklenmez. İstemcilerin güven deposunda bulunan kök sertifikanın gönderilmesi, zinciri iyileştirmez ve gereksiz veri aktarımına neden olur.

Log ve teşhis komutlarıyla eksik zinciri doğrulama

Sunucunun gerçekte ne gönderdiğini inceleyin

Linux, macOS veya OpenSSL bulunan bir yönetim istasyonunda aşağıdaki komutu çalıştırın. example.com yerine alan adınızı yazın. -servername parametresi, aynı IP üzerinde birden çok HTTPS sitesi varsa doğru sertifikanın seçilmesi için gereklidir.

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error < /dev/null

Çıktıda birden fazla BEGIN CERTIFICATE bloğu görünmelidir: önce alan adı sertifikası, sonra gerekli ara sertifikalar. Komut sonunda Verify return code: 0 (ok) görülmesi olumlu bir göstergedir. Ancak bu sonuç, komutu çalıştıran makinenin yerel CA deposuna da bağlıdır; asıl inceleme sunucunun gönderdiği blokların sayısı ve sırasıdır.

Sertifikanın issuer ve subject bilgisini daha okunur görmek için:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Bu komut boru hattında ilk sertifikayı gösterir. Tüm zinciri ayırarak incelemek gerektiğinde, CA’nın yayımladığı bundle ile karşılaştırma yapmak daha güvenlidir.

Uygulama katmanından bağlantıyı sınayın

curl -Iv https://example.com/

curl doğrulama hatası döndürüyorsa işletim sisteminizin CA deposu, güvenilir bir istemci testi sunar. Test sırasında -k veya --insecure kullanmayın; bu seçenek sertifika doğrulamasını devre dışı bırakarak sorunu gizler.

Web sunucusu hata kayıtlarını kontrol edin

Günlük dosyasının konumu dağıtıma, paketlemeye ve panel yapılandırmasına göre değişir. Aktif hata günlüğü yolunu web sunucusu yapılandırmanızdan teyit edin. Apache’de yapılandırma denetimi sırasında, Nginx’te ise test komutunda sertifika dosyasının okunamadığı veya anahtarın eşleşmediği gibi bilgiler görülebilir.

Eksik sertifika zincirini güvenli biçimde tamamlama

1. Doğru sertifika dosyalarını hazırlayın

Sertifika otoritenizin yönetim ekranından ya da resmi dokümantasyonundan şu dosyaları indirin: alan adınıza ait sunucu sertifikası ve bu sertifikayı imzalayan ara CA sertifikası veya sertifikaları. Sertifika farklı bir issuer tarafından yenilendiyse eski bundle’ı tekrar kullanmayın.

Bir PEM zincir dosyası oluşturmanız gerekiyorsa sıra şu şekilde olmalıdır:

cat server-certificate.pem intermediate-ca-1.pem intermediate-ca-2.pem > fullchain.pem

server-certificate.pem alan adınızın sertifikasıdır. Ardından, her sertifikanın Issuer bilgisi bir sonraki sertifikanın Subject bilgisiyle eşleşecek biçimde ara sertifikalar gelir. Özel anahtarı bu dosyaya eklemeyin. Dosya adları örnektir; kendi güvenli çalışma dizininizde gerçek dosya adlarını kullanın.

Sunucu sertifikası ile özel anahtarın eşleştiğini, dosya içeriğini açığa çıkarmadan aşağıdaki şekilde denetleyebilirsiniz:

openssl x509 -noout -modulus -in server-certificate.pem | openssl sha256
openssl rsa -noout -modulus -in private-key.pem | openssl sha256

İki özet aynı olmalıdır. ECDSA anahtarlarda openssl rsa yerine anahtar türünüze uygun OpenSSL komutu gerekebilir. Özel anahtar dosyasına en az ayrıcalık ilkesiyle erişim verin ve bu dosyayı paylaşmayın.

2. Apache HTTP Server yapılandırmasını güncelleyin

Güncel Apache 2.4 sürümlerinde sanal ana bilgisayarın TLS bölümünde SSLCertificateFile için leaf ve intermediate sertifikaları içeren birleşik dosyayı kullanın. SSLCertificateKeyFile ise mevcut özel anahtar dosyasını göstermelidir.

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /path/to/fullchain.pem
    SSLCertificateKeyFile /path/to/private-key.pem
</VirtualHost>

Eski kurulumlarda görülen SSLCertificateChainFile yaklaşımını, Apache sürümünüz ve mevcut yapılandırmanız gerektirmedikçe yeni bir çözüm olarak eklemeyin. Aynı zinciri hem SSLCertificateFile içinde hem ayrı chain direktifiyle tanımlamak belirsizliğe yol açabilir.

Dağıtıma uygun yapılandırma testi komutunu çalıştırın. Komut adı sisteminize göre değişebilir:

apachectl configtest
# veya
httpd -t

Test başarılıysa, açık bağlantıları mümkün olduğunca koruyan kontrollü yeniden yükleme komutunu kullanın. Hizmet yönetimi komutu dağıtımınıza göre değişir:

systemctl reload apache2
# veya
systemctl reload httpd

3. Nginx yapılandırmasını güncelleyin

Nginx’te ssl_certificate doğrudan sunucu sertifikasına değil, leaf sertifika ve ara sertifikaları içeren fullchain.pem dosyasına işaret etmelidir. Özel anahtar ayrı kalır.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/private-key.pem;
}

Önce sözdizimini ve referans verilen dosyaları kontrol edin; ardından yeniden yükleyin:

nginx -t
systemctl reload nginx

nginx -t başarısızsa yeniden yükleme yapmayın. Hata mesajındaki yapılandırma dosyası ve satırı inceleyerek önce dosya yolu, izinler ve PEM içeriğini düzeltin.

4. IIS, cPanel, Plesk ve yönetilen uç noktaları kontrol edin

IIS üzerinde sertifika zinciri, çoğunlukla sunucu sertifikasının bağlı olduğu sertifika deposundaki ara sertifikalara dayanır. Ara CA sertifikalarını Windows’un Local Computer kapsamındaki Intermediate Certification Authorities deposuna, sertifika otoritesinin sağladığı dosyadan içe aktarın. Ardından ilgili IIS binding’inin doğru sertifikaya bağlı olduğunu doğrulayın. Üretim sunucusunda sertifika deposu değişikliği öncesinde mevcut sertifikaları ve binding ayarlarını kaydedin.

cPanel veya Plesk gibi panellerde sertifika kurulumu ekranındaki CA Bundle/Certificate Authority Bundle alanı, sertifikanın yanında verilen ara sertifikaları içermelidir. Panel otomatik olarak zincir bulsa bile harici OpenSSL testiyle sonucu doğrulayın. CDN, WAF, reverse proxy veya bulut yük dengeleyici kullanılıyorsa, ziyaretçinin bağlandığı dış uç noktadaki sertifika ayrıca yönetilir; origin sunucuyu düzeltmek tek başına yeterli olmayabilir.

Çözümün doğrulanması

Değişiklikten sonra DNS önbelleği veya tarayıcı önbelleği yerine doğrudan TLS el sıkışmasını yeniden test edin:

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error < /dev/null
curl -Iv https://example.com/

Şunları kontrol edin:

• Sunulan ilk sertifikanın Subject alanı hedef alan adıyla uyumlu olmalıdır.
• Gerekli ara sertifikalar leaf sertifikadan sonra gönderilmelidir.
• Verify return code: 0 (ok) sonucu alınmalıdır.
• HTTPS uygulaması, yönlendirmeler ve API çağrıları normal çalışmalıdır.
• CDN varsa hem CDN alan adında hem gerekliyse origin bağlantısında ayrı test yapılmalıdır.

Önleme: Yenilemelerde SSL certificate chain incomplete hatasını engelleme

• Sertifika yenileme prosedüründe yalnızca cert dosyasını değil, fullchain/bundle referansını da kontrol edin.
• Yenileme sonrası otomatik bir openssl s_client veya güvenilir izleme kontrolü çalıştırın.
• Sertifika, özel anahtar ve web sunucusu yapılandırmasını erişimi sınırlı bir yedekleme planına dahil edin.
• CDN, load balancer ve origin için sertifika sahipliğini ve yenileme sorumluluğunu dokümante edin.
• CA değişikliği olduğunda önceki ara sertifika zincirinin uygun olduğunu varsaymayın.

Sonuç

SSL certificate chain incomplete hatası, çoğu zaman doğru ara CA sertifikalarının doğru sırada sunulmamasından kaynaklanır. Sorunu kalıcı biçimde çözmek için önce internete açık TLS uç noktasını SNI ile test edin, güncel CA zincirini doğrulayın, ardından Apache veya Nginx’te fullchain dosyasını; IIS ve panellerde ise uygun ara sertifika deposunu ya da CA bundle alanını güncelleyin. Son adım olarak bağımsız OpenSSL ve curl kontrolleriyle zincirin gerçekten istemcilere gönderildiğini doğrulayın.

Sık sorulan sorular

Root sertifikayı fullchain dosyasına eklemeli miyim?

Genellikle hayır. Sunucu sertifikası ve gerekli intermediate sertifikalar gönderilir; kök sertifika istemcinin güven deposunda bulunur.

Tarayıcıda site açılıyor; yine de zinciri düzeltmeli miyim?

Evet. Tarayıcı ara sertifikayı önbellekten tamamlayabilir. API istemcileri, mobil cihazlar ve eski sistemler aynı toleransı göstermeyebilir.

Let’s Encrypt sertifikasında hangi dosya kullanılmalıdır?

Kullandığınız istemcinin ve web sunucusunun ürettiği dosya adlarını doğrulayın. Nginx ve güncel Apache yapılandırmalarında genellikle leaf ile intermediate sertifikaları birlikte içeren fullchain dosyası sertifika direktifinde kullanılır.

Sunucuyu yeniden başlatmak zorunda mıyım?

Çoğu Apache ve Nginx kurulumunda başarılı yapılandırma testinden sonra kontrollü reload yeterlidir. Ancak hizmet yöneticinizin, panelinizin ve mimarinizin çalışma biçimini dikkate alın.

CDN kullanıyorum; origin sertifikası doğru olsa hata neden sürer?

Ziyaretçiler CDN’nin edge sertifikasına bağlanır. Bu nedenle CDN kontrol panelindeki sertifika zincirini, alan adı yönlendirmesini ve aktif edge yapılandırmasını ayrıca incelemelisiniz.