Eksik Ara Sertifika (Chain) Hatası Nasıl Çözülür?

Sitenizi kendi bilgisayarınızdan açıyorsunuz, tarayıcının adres çubuğunda kilit simgesi pırıl pırıl duruyor, hiçbir uyarı yok. Ama telefonundan giren bir müşteri "güvenli değil" hatası aldığını söylüyor, üstüne API entegrasyonunuz "unable to verify the first certificate" diye log basıyor. İlk tepki çoğu zaman "ama bende çalışıyor" olur ve sorun günlerce bu ikilemin içinde döner durur. Aslında hemen hemen her seferinde tek bir sebep vardır: sunucunuz istemciye sertifikanın kendisini gönderiyor ama araya girmesi gereken ara sertifikayı (intermediate certificate) göndermiyor.

Bu rehberde eksik ara sertifika kaynaklı zincir (chain) hatasının neden yalnızca bazı cihazlarda ortaya çıktığını, hatanın kaynağını openssl ve SSL Labs ile nasıl kesin şekilde tespit edeceğinizi, ardından fullchain.pem dosyasını doğru birleştirip Nginx, Apache ve cPanel üzerinde nasıl kalıcı olarak düzelteceğinizi adım adım göstereceğiz. Amacımız sadece "çalışır hale getirmek" değil; bir daha başınıza gelmemesi için altta yatan mantığı da oturtmak.

Sertifika Zinciri Nedir ve Neden Bir Halka Eksik Olabilir#

Bir SSL/TLS sertifikası tek başına havada durmaz; bir güven zincirinin en alt halkasıdır. Tarayıcının ya da işletim sisteminin gövdesinde yerleşik olarak gelen bir dizi kök sertifika (root CA) vardır. Sizin site sertifikanız (leaf) genellikle doğrudan bu köke değil, aradaki bir veya birden fazla ara sertifikaya (intermediate CA) bağlıdır. Zincir şöyle işler: site sertifikanız X ara sertifikası tarafından imzalanmıştır, X ara sertifikası da tarayıcıda zaten güvenilen bir kök tarafından imzalanmıştır. İstemci bu köprüyü kurabilirse sertifikaya güvenir.

Sorun şu ki, kök sertifikalar istemcide gömülüdür ama ara sertifikalar değildir. Bu yüzden zinciri tamamlama görevi sunucuya düşer: sunucu, el sıkışma (handshake) sırasında hem kendi leaf sertifikasını hem de araya giren intermediate sertifikaları istemciye göndermek zorundadır. Eğer sunucu yalnızca leaf sertifikayı gönderir, intermediate'i unutursa istemci köprünün orta ayağını bulamaz ve güven kurulamaz. İşte "incomplete chain", "chain issues", "unable to get local issuer certificate" gibi mesajların tamamı bu eksik halkayı anlatır. Sertifikanızın kendisi kusursuz olabilir; hata büyük ihtimalle sunucuya yüklerken zinciri eksik bırakmanızdan kaynaklanır. Bu ayrım önemlidir; sertifikayı yeniden satın almak sorunu çözmez, doğru dosyayı doğru yere koymak çözer.

Neden Bazı Cihazlarda Çalışıp Mobilde Patlıyor#

En kafa karıştırıcı kısım burasıdır ve mantığını anladığınızda hata sizin için sihir olmaktan çıkar. Modern masaüstü tarayıcılar, özellikle Firefox ve güncel Chrome sürümleri, eksik ara sertifikayı telafi etme yeteneğine sahiptir. AIA fetching (Authority Information Access) denilen bir mekanizma sayesinde tarayıcı, leaf sertifikanın içindeki "issuer" bilgisine bakıp eksik ara sertifikayı CA'nın sunucusundan kendisi indirir ve zinciri sessizce tamamlar. Sonuç: sizin masaüstünüzde her şey yolunda görünür, çünkü tarayıcı sizin sunucunuzun yapmadığı işi arka planda yapmıştır.

Mobil tarayıcılar, eski Android sürümleri, birçok API istemcisi (curl, wget, Java HttpsURLConnection, Python requests, ödeme ağ geçitleri, arama motoru botları) ise bu telafiyi genellikle yapmaz. Onlar sunucudan gelen zincire birebir güvenir; eksikse doğrudan reddederler. Bu yüzden aynı site masaüstü Chrome'da yeşil, iPhone Safari'de ya da PayTR gibi bir webhook çağrısında kırmızı olur. Yani "bende çalışıyor" ifadesi sizi yanıltır; siz eksik zincirli bir sunucuyu, boşluğu kendisi dolduran bir istemciyle test etmişsinizdir. Doğru test her zaman zincir toleransı olmayan bir araçla (openssl veya SSL Labs) yapılmalıdır. Aşağıdaki tablo hangi istemcinin nasıl davrandığını özetliyor.

Eksik Ara Sertifikayı Kesin Olarak Tespit Etmek#

Tahminle iş yürütmeyin; zinciri ölçün. En hızlı görsel yöntem SSL Labs'in ücretsiz test aracıdır (ssllabs.com/ssltest). Alan adınızı girip taramayı bekledikten sonra sonuç sayfasında Certification Paths ya da Additional Certificates (if supplied by server) bölümüne bakın. Eğer raporda "Chain issues: Incomplete" yazıyorsa teşhis nettir: sunucunuz ara sertifikayı göndermiyor. SSL Labs ayrıca not olarak genel puanınızı da düşürür, çünkü eksik zincir gerçek bir üretim hatasıdır.

Terminale erişiminiz varsa openssl çok daha kesin ve hızlıdır. Aşağıdaki komut sunucunun handshake sırasında gerçekten hangi sertifikaları gönderdiğini gösterir.

openssl s_client -connect orneksite.com:443 -servername orneksite.com

Çıktının başındaki Certificate chain bölümü kritik. Sağlıklı bir zincirde en az iki (çoğunlukla üç) girdi görürsünüz: 0 s: sizin leaf sertifikanız, 1 s: ara sertifika, bazen 2 s: bir ara/kök daha. Eğer sadece 0 numaralı satırı görüyorsanız zincir eksiktir. En kesin işaret ise çıktının alt tarafındaki doğrulama satırıdır.

Verify return code: 21 (unable to verify the first certificate)

Bu 21 kodunu gördüğünüzde tereddüt etmeyin; zincir kopuktur. Bir sistemin gerçekten -servername (SNI) ile test edilmesi önemlidir, aksi halde çok siteli sunucularda yanlış sertifikayı görebilirsiniz. Zinciri daha da net ayrıştırmak isterseniz gönderilen tüm sertifikaları dökün:

echo | openssl s_client -connect orneksite.com:443 -servername orneksite.com \
  -showcerts 2>/dev/null | openssl x509 -noout -issuer -subject

Burada subject ile issuer alanlarını karşılaştırın. Leaf sertifikanın issuer değeri, sunucunun göndermesi gereken ara sertifikanın subject değerine eşit olmalıdır. Bu ara sertifika handshake dökümünde yoksa, sunucuya eklemeniz gereken parça tam olarak odur. Bu tür teşhis komutlarını ve diğer yaygın SSL arızalarını topluca ele aldığımız SSL hatalarının çözümü rehberimize de göz atmanızı öneririm; oradaki teşhis akışı bu sorunla iç içe geçer.

fullchain.pem'i Doğru Birleştirmek#

Çözümün kalbi doğru sırayla oluşturulmuş bir zincir dosyasıdır. Bir CA'dan sertifika aldığınızda genellikle elinize birkaç dosya geçer: sizin site sertifikanız (certificate.crt veya sirket_com.crt) ve bir veya daha fazla ara sertifika (ca-bundle, intermediate.crt, chain.pem gibi isimlerle). Görev bunları doğru sırayla tek dosyada toplamaktır. Sıra kuralı basittir ve asla değişmez: önce leaf, sonra ara sertifika(lar), en altta (isteğe bağlı) kök. Aşağıdan yukarıya değil, yukarıdan aşağıya güven akışı gibi düşünün.

Let's Encrypt kullananlar için işiniz kolay: certbot zaten kutuya hazır bir fullchain.pem üretir; leaf ve ara sertifikayı doğru sırayla içinde barındırır. /etc/letsencrypt/live/alan-adiniz/fullchain.pem dosyasını olduğu gibi kullanabilirsiniz. Ticari bir CA'dan aldıysanız birleştirmeyi kendiniz yapmanız gerekebilir.

# Sıralama: leaf -> intermediate -> (kök). Kök çoğu zaman gerekmez.
cat sirket_com.crt intermediate.crt > fullchain.pem

Birden fazla ara sertifika varsa hepsini zincirdeki sıralarına göre ekleyin. Yanlış sıralama da tıpkı eksik zincir gibi hataya yol açar; bazı istemciler sırayı toleranslı karşılasa da bir kısmı reddeder, o yüzden sırayı hep koruyun.

cat sirket_com.crt intermediate_1.crt intermediate_2.crt > fullchain.pem

Birleştirdikten sonra dosyayı doğrulamadan sunucuya koymayın. Her -----BEGIN CERTIFICATE----- bloğunun ayrı bir sertifika olduğunu ve blokların arka arkaya, boşluk sorunu olmadan dizildiğini teyit edin.

# Dosyadaki sertifika sayısını say (en az 2 olmalı)
grep -c "BEGIN CERTIFICATE" fullchain.pem

# Zincirin kendi içinde tutarlı olup olmadığını doğrula
openssl verify -untrusted intermediate.crt sirket_com.crt

sirket_com.crt: OK çıktısını görüyorsanız zincir matematiksel olarak sağlamdır ve artık sunucuya güvenle yükleyebilirsiniz. Bir yaygın tuzak: leaf sertifikanın özel anahtarı (.key) ile bu zinciri karıştırmayın; özel anahtar hiçbir zaman fullchain içine girmez, ayrı SSLCertificateKeyFile / ssl_certificate_key olarak kalır.

Nginx'te Zincir Hatasını Düzeltmek#

Nginx'in en sık yaptığınız hatayı affetmeyen bir tarafı vardır: ssl_certificate yönergesine yalnızca leaf sertifikayı verirseniz, Nginx ara sertifikayı kendiliğinden bulup eklemez. Handshake'te sadece o tek sertifikayı gönderir ve zincir kopar. Çözüm, ssl_certificate yönergesine leaf değil, az önce oluşturduğunuz fullchain dosyasını göstermektir.

server {
    listen 443 ssl;
    server_name orneksite.com www.orneksite.com;

    # DOĞRU: leaf + ara sertifikaları içeren birleşik dosya
    ssl_certificate     /etc/ssl/orneksite/fullchain.pem;
    ssl_certificate_key /etc/ssl/orneksite/private.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root /var/www/orneksite;
    index index.php index.html;
}

Dosyayı güncelledikten sonra yapılandırmayı sınayıp servisi yeniden yükleyin. reload çalışan bağlantıları kesmeden yeni sertifikayı devreye alır.

nginx -t                # Söz dizimini ve dosya erişimini test et
systemctl reload nginx  # Kesintisiz yeniden yükle

Sonrasında mutlaka openssl s_client ile tekrar test edin; Certificate chain bölümünde artık 1 s: satırının belirmesi ve Verify return code: 0 (ok) görmeniz gerekir. Not: Let's Encrypt kullanıyorsanız ssl_certificate alanına doğrudan certbot'un ürettiği fullchain.pem'i vermek yeterlidir; ayrıca birleştirme yapmanıza gerek kalmaz. Nginx'te ayrıca OCSP stapling açmak istiyorsanız ssl_trusted_certificate yönergesine ara+kök zincirini vermeniz gerekir ama bu, chain hatasını çözmek için zorunlu değildir; asıl çözüm ssl_certificate'in fullchain olmasıdır.

Apache'de CA Bundle Yüklemek#

Apache'de mantık aynı, sadece yönerge isimleri farklı. Modern Apache sürümlerinde (2.4.8 ve üzeri) tek bir birleşik dosya kullanmanız önerilir. Eski yapılandırmalarda ara sertifikalar ayrı bir SSLCertificateChainFile ile verilirdi; bu yönerge artık kullanımdan kaldırılmıştır (deprecated). Yeni yöntemde ara sertifikaları da doğrudan SSLCertificateFile'a gösterdiğiniz fullchain dosyasının içine koyarsınız.

<VirtualHost *:443>
    ServerName orneksite.com
    DocumentRoot /var/www/orneksite

    SSLEngine on
    # Modern yöntem: fullchain tek dosyada
    SSLCertificateFile    /etc/ssl/orneksite/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/orneksite/private.key
</VirtualHost>

Eğer Apache sürümünüz eskiyse ya da hosting paneliniz hâlâ ayrı bundle bekliyorsa, ara sertifikaları ayrı dosyada SSLCertificateChainFile ile tanımlayabilirsiniz. Aşağıdaki iki yaklaşımdan birini seçin, ikisini birden karıştırmayın.

# Eski/uyumluluk yöntemi (2.4.8 öncesi)
SSLCertificateFile      /etc/ssl/orneksite/sirket_com.crt
SSLCertificateChainFile /etc/ssl/orneksite/ca-bundle.crt
SSLCertificateKeyFile   /etc/ssl/orneksite/private.key

Değişiklikten sonra yapılandırmayı test edip servisi yeniden başlatın. Dağıtımınıza göre servis adı apache2 veya httpd olabilir.

apachectl configtest        # "Syntax OK" görmelisiniz
systemctl reload apache2    # veya: systemctl reload httpd

Aşağıdaki tablo hangi sunucuda hangi yönergenin zinciri taşıdığını tek bakışta görebilmeniz için bir hatırlatma niteliğinde.

cPanel'de Zinciri Tamamlamak#

Sunucuya SSH ile değil de cPanel arayüzüyle erişiyorsanız süreç daha görseldir ama tuzak aynıdır: çoğu kişi CA Bundle kutusunu boş bırakıp yalnızca sertifika ve anahtarı yapıştırır, sonuç yine eksik zincir olur. cPanel'de doğru akış şöyledir. SSL/TLS bölümüne girin, Manage SSL sites (SSL Sitelerini Yönet) sayfasını açın ve ilgili alan adını seçin. Karşınıza üç kutu çıkar.

Birinci kutu Certificate (CRT) alanıdır; buraya leaf sertifikanızı (-----BEGIN CERTIFICATE----- ile başlayan tek blok) yapıştırın. İkinci kutu Private Key (KEY) alanıdır; özel anahtarınızı buraya koyun. Kritik olan üçüncüsüdür: Certificate Authority Bundle (CABUNDLE). İşte eksik ara sertifikanız tam olarak buraya girer. CA'nızın verdiği ca-bundle veya intermediate içeriğini bu kutuya yapıştırırsanız cPanel zinciri otomatik olarak doğru sırada birleştirip Apache'ye iletir. cPanel çoğu zaman CRT kutusuna leaf'i yapıştırdığınızda ilişkili bundle'ı tanıyıp otomatik doldurur; yine de üçüncü kutunun dolu olduğunu gözle teyit edin. "Install Certificate (Sertifikayı Kur)" düğmesine bastıktan sonra "SSL Certificate successfully updated" mesajını görmelisiniz.

Kurulumdan sonra cPanel'in "SSL Certificate is valid" özetine güvenip durmayın; her zaman dışarıdan, zincir toleransı olmayan bir araçla doğrulayın. Terminal erişiminiz yoksa SSL Labs testini tekrar çalıştırıp "Chain issues" satırının "None" olduğunu görün. AutoSSL (Let's Encrypt tabanlı ücretsiz cPanel sertifikaları) kullanıyorsanız zincir zaten otomatik tamamlanır; chain hatasını neredeyse her zaman elle yüklenen ticari sertifikalarda yaşarsınız. Sertifika kavramlarını en baştan tazelemek isterseniz SSL sertifikası nedir yazımız leaf, ara ve kök ayrımını daha da somutlaştırır.

Kalıcı Çözüm ve Yenileme Sırasında Tekrarını Önlemek#

Zinciri bir kez düzeltmek yetmez; sertifika her yenilendiğinde aynı hatayı yapmamak için sürecinizi sağlamlaştırmalısınız. En sık tekrar sebebi, yenileme sırasında CA'nın ara sertifikasını değiştirmesidir. CA'lar zaman zaman intermediate sertifikalarını yeniler; eski bundle'ı körü körüne tekrar kullanırsanız zincir yeni leaf ile uyuşmaz. Bu yüzden her yenilemede CA'nın o an verdiği güncel bundle'ı kullanın, elinizde yıllardır duran eski dosyayı değil.

Otomasyon en güvenli yoldur. Let's Encrypt ve certbot kullanıyorsanız fullchain.pem her yenilemede otomatik doğru üretildiği için chain sorunu pratikte ortadan kalkar; tek yapmanız gereken sunucu yapılandırmasının bu dosyayı göstermesidir. Yenileme sonrası servisin sertifikayı yeniden okuması için bir deploy hook eklemeyi unutmayın.

# Yenileme provası ve yenileme sonrası otomatik reload
certbot renew --dry-run
certbot renew --deploy-hook "systemctl reload nginx"

Kendi izleme akışınızı kurmak isterseniz basit bir kontrol bile büyük dertten kurtarır; aşağıdaki komutu bir cron işine koyup zincirin bozulduğu an haber alabilirsiniz.

# Zincir doğrulaması: return code 0 değilse alarm ver
echo | openssl s_client -connect orneksite.com:443 -servername orneksite.com \
  2>/dev/null | openssl verify 2>&1 | grep -q "OK" || echo "ZINCIR HATASI"

Yönetimini üstlenmek istemediğiniz bir yük ise, sertifika ve zincir kurulumunu bizim tarafımıza bırakabilirsiniz. Clou.TR SSL çözümlerinde zincir doğru sırayla kurulur, yenilemeler otomatikleşir; sunucu yönetimi hizmetimizde ise Nginx/Apache yapılandırması dahil tüm TLS katmanını biz devralırız. İşin özü tek cümlede toplanır: sunucu, leaf sertifikanın yanında ara sertifikayı da gönderdiği sürece hiçbir cihaz zincir hatası vermez.

Sıkça Sorulan Sorular#

Sitem masaüstünde açılıyor ama telefonda "güvenli değil" diyor, sertifikam bozuk mu?#

Hayır, sertifikanız büyük olasılıkla sağlamdır; sorun sunucunuzun ara sertifikayı göndermemesidir. Masaüstü tarayıcılar AIA fetching sayesinde eksik ara sertifikayı arka planda kendileri indirip zinciri tamamlar, bu yüzden sizde çalışır görünür. Mobil tarayıcılar ve API istemcileri bu telafiyi yapmadığı için handshake'i reddeder. openssl s_client ile test edip Verify return code: 21 görüyorsanız teşhis kesindir ve çözüm zinciri fullchain olarak sunucuya doğru yüklemektir.

fullchain.pem ile chain.pem arasındaki fark nedir?#

Aralarındaki fark içerdikleri sertifika kümesidir ve bunları karıştırmak yaygın bir hatadır. chain.pem yalnızca ara sertifikaları (ve kökü) içerir, sizin leaf sertifikanızı içermez. fullchain.pem ise leaf sertifika artı ara sertifikaların tamamını doğru sırada barındırır; yani sunucuya vereceğiniz dosya budur. Nginx'te ssl_certificate ve Apache 2.4.8+ SSLCertificateFile yönergelerine her zaman chain.pem'i değil fullchain.pem'i göstermelisiniz.

Ara sertifikayı fullchain'e yanlış sırada eklersem ne olur?#

Yanlış sıralama, eksik zincirle benzer şekilde doğrulama hatasına yol açabilir. Doğru sıra her zaman önce leaf sertifika, ardından ara sertifika(lar), en sonda isteğe bağlı kök şeklindedir. Bazı istemciler karışık sırayı toleransla düzeltir ama katı istemciler reddeder, dolayısıyla üretimde asla sıraya güvenmeyin. Birleştirmeden sonra openssl verify -untrusted intermediate.crt leaf.crt komutuyla OK çıktısı aldığınızdan emin olun.

Özel anahtarı (private key) fullchain dosyasının içine koymalı mıyım?#

Kesinlikle hayır, özel anahtar hiçbir zaman zincir dosyasına girmez. fullchain.pem yalnızca herkese açık sertifikaları (leaf ve ara) içerir; özel anahtar gizli kalmalı ve ayrı bir dosyada tutulmalıdır. Nginx'te ssl_certificate_key, Apache'de SSLCertificateKeyFile, cPanel'de ayrı Private Key kutusu bu iş içindir. Anahtarınızı yanlışlıkla zincire ya da halka açık bir yere koyduysanız o sertifikayı derhal iptal edip yeniden düzenlemeniz gerekir.

SSL Labs "Chain issues: Incomplete" diyor ama tarayıcıda kilit görünüyor, gerçekten sorun var mı?#

Evet, gerçek ve ciddi bir sorundur; tarayıcıdaki kilit sizi yanıltmaktadır. SSL Labs, tarayıcıların aksine eksik zinciri telafi etmeden ham gerçeği raporlar, yani "Incomplete" yazıyorsa sunucunuz ara sertifikayı göndermiyordur. Bu durum mobil kullanıcıların, ödeme ağ geçitlerinin ve arama motoru botlarının sitenize erişememesine yol açar. Kilit görünse bile fullchain'i doğru yükleyip testi tekrarlayarak "Chain issues: None" sonucuna ulaşmanız gerekir.

Let's Encrypt kullanıyorum, yine de zincir hatası alabilir miyim?#

Alabilirsiniz ama sebebi neredeyse her zaman yapılandırma hatasıdır, certbot değil. Certbot fullchain.pem'i doğru üretir; sorun genellikle sunucu yapılandırmasının fullchain.pem yerine yanlışlıkla cert.pem'i (yalnız leaf) göstermesidir. ssl_certificate ya da SSLCertificateFile yönergesinin fullchain.pem'e işaret ettiğini doğrulayın. Ayrıca yenileme sonrası servisi reload etmeyi unutursanız eski/eksik zincir bellekte kalabilir, bu yüzden bir deploy hook ile otomatik yeniden yükleme kurmak en sağlıklısıdır.

Kapanış#

Eksik ara sertifika hatası, ilk bakışta "sitem bazı cihazlarda açılmıyor" gibi belirsiz görünse de aslında tek ve net bir kök nedene dayanır: sunucu, leaf sertifikanın yanında ara sertifikayı göndermiyordur. Bu yazıda hatayı openssl ve SSL Labs ile kesin biçimde teşhis etmeyi, fullchain.pem'i doğru sırayla birleştirmeyi ve Nginx, Apache ile cPanel'de kalıcı olarak düzeltmeyi adım adım gördük. Mantığı bir kez oturttuğunuzda, "bende çalışıyor" tuzağına bir daha düşmez, her yenilemede zinciri güvenle tamamlarsınız.

Bu işi kendiniz üstlenmek istemiyorsanız Clou.TR yanınızda. Zincirin doğru kurulduğu ve yenilemelerin otomatikleştiği SSL çözümlerimize, TLS katmanını uçtan uca devraldığımız sunucu yönetimi hizmetimize ya da SSL'in hazır ve sorunsuz geldiği hosting paketlerimize göz atabilirsiniz. Doğru kurulmuş bir sertifika zinciri, her ziyaretçinizin hangi cihazdan gelirse gelsin kesintisiz ve güvenli bir bağlantı kurması demektir.