Hastanelerde sterilizasyon zinciri (asepsi zinciri), ameliyat aletlerinin otoklav cihazında sterilize edilmesinden ameliyathanede cerrahın eline ulaşana kadar kesintisiz bir halkalar bütünüdür. Alet otoklavdan çıkar, sızdırmaz ara steril taşıma konteynerine konur, steril asansörle transfer edilir ve ameliyathanede steril hemşire tarafından açılır. Eğer taşıma ekibi o "ara transfer konteynerini" atlar, aletleri koridordan çıplak tepsiyle taşırsa ne olur? Genç, 20 yaşında, bağışıklık sistemi son derece güçlü bir sporcuyu ameliyat ettiğinizde hastanın vücudu bu ufak kirlenmeyi tolere edebilir ve enfeksiyon kapmayabilir. Ancak aynı ihmalle bağışıklığı baskılanmış, 70 yaşında bir diyabet hastasını ameliyat ederseniz hasta 24 saat içinde masif sepsise girer. Sorumsuz bir cerrahın "Ama genç hastada sorun çıkmadı, demek ki aletler temiz, yaşlı hasta bahane üretiyor" demesi ne kadar vahim bir hezeyansa; web altyapılarında sertifika zincirini yarım bırakıp savunma yapmak da o kadar vahimdir.

SSL/TLS sertifikalarını web sunucusuna (Nginx, Apache, HAProxy) kurarken Ara Sertifika (Intermediate Certificate / CA Bundle) dosyasını unutan ekiplerin düştüğü o meşhur tuzak tam olarak budur:
Müşteri feryat eder: "Sitenize bilgisayardan girince 'Bağlantınız Gizli Değil - NET::ERR_CERT_AUTHORITY_INVALID' uyarısı çıkıyor!"
Geliştirici kendi iPhone'unu açar, siteye girer ve yeşil kilidi görür: "Bende açılıyor, sorun yok! Sizin bilgisayarınızın saati yanlıştır veya şirket ağınız engelliyordur!"

Oysa suç müşterinin bilgisayarında değil, sunucuda koparılmış olan güven zincirindedir.

Güven Zinciri (Chain of Trust) Nasıl Çalışır?

Dünyadaki hiçbir web tarayıcısı (Chrome, Firefox, Safari) veya işletim sistemi (Windows, macOS, Linux, Android, iOS) sizin sitenizin sertifikasını doğrudan tanımaz. Tanıması da beklenemez; dünyada yüz milyonlarca web sitesi vardır.

Güven hiyerarşik bir piramit olarak inşa edilir:

                  ┌────────────────────────────────────────┐
                  │          KÖK SERTİFİKA OTORİTESİ       │
                  │              (Root CA)                 │
                  │  (Örn: IdenTrust, DigiCert, Sectigo)   │
                  │  *İşletim sistemlerinin hafızasında gömülüdür*
                  └───────────────────┬────────────────────┘
                                      │ İmzalar 🔏
                                      ▼
                  ┌────────────────────────────────────────┐
                  │            ARA SERTİFİKA               │
                  │      (Intermediate CA / CA Bundle)     │
                  │  (Örn: Let's Encrypt R3, Sectigo RSA)  │
                  │  *Kök CA kendi anahtarını korumak için │
                  │   günlük imzaları bu aracıya devreder* │
                  └───────────────────┬────────────────────┘
                                      │ İmzalar 🔏
                                      ▼
                  ┌────────────────────────────────────────┐
                  │             SİZİN SERTİFİKANIZ         │
                  │          (Server / Leaf Certificate)   │
                  │             example.com                │
                  └────────────────────────────────────────┘

Tarayıcınız sitenize bağlandığında sunucudan bir kanıt zinciri sunmasını bekler:
"Sen bana kendi sertifikanı verdin (Leaf). Peki seni kim imzaladı? 'Let's Encrypt R3'. Peki R3'ü kim imzaladı? 'ISRG Root X1'. Tamam, ISRG Root X1 benim işletim sistemimin güvenilir kök listemde var; zincir tamamlandı, yeşil kilidi yakıyorum!"

Sertifikayı satın aldığınızda veya Let's Encrypt oluşturduğunda size iki temel dosya verilir:

  1. certificate.crt (Yalnızca sizin sunucu sertifikanız)
  2. ca-bundle.crt / intermediate.crt (Ara sertifika zinciri)

Acemi sistem yöneticisi Nginx yapılandırmasını açar:

# ÖLÜMCÜL HATA: Yalnızca sunucu sertifikasını göstermek!
ssl_certificate /etc/ssl/certs/certificate.crt;
ssl_certificate_key /etc/ssl/private/private.key;

Sunucu istemciyle el sıkışırken (TLS Handshake) yalnızca kendi sertifikasını uzatır. Ara sertifikayı istemciye sunmaz!

Neden Telefonda Açılır da Bilgisayarda Patlar?

İşte kafa karışıklığının koptuğu nokta burasıdır:

  1. Akıllı Telefonlar ve Modern Chrome (AIA Fetching):
    Mobil tarayıcılar (iOS Safari ve Android Chrome) son derece toleranslıdır. Sertifikada yer alan Authority Information Access (AIA) alanındaki URL'yi okur. Eksik olan ara sertifikayı arka planda internetten kendisi indirir veya yerel önbelleğinde (cache) daha önce başka bir siteden öğrendiği ara sertifikayı kullanarak zinciri kendisi tamamlar! Site sorunsuz açılır.
  2. Kurumsal Masaüstü Bilgisayarlar ve Eski Tarayıcılar:
    Windows üzerindeki Firefox, katı grup politikalarıyla yönetilen şirket bilgisayarları, Linux istemcileri, cURL kütüphaneleri ve mobil API istemcileri (mobil uygulamalar) bu toleransı göstermez! AIA fetching yapmazlar.
    Zincirde bir halka eksikse, tarayıcı kararını anında verir:
    NET::ERR_CERT_AUTHORITY_INVALID veya SEC_ERROR_UNKNOWN_ISSUER.
    Kullanıcının karşısına o kırmızı tehlike ekranı dikilir: "Saldırganlar şifrelerinizi çalmaya çalışıyor olabilir!"

Müşteri o siteden anında kaçar; şirket yöneticisi ise mobil telefonunda sitenin açıldığını iddia ederek teknik ekibi savunmaya devam eder.

Tanı ve Teşhis: Terminalde Dedektiflik

Bu hatayı anlamak için tarayıcıların toleranslı arayüzünden çıkıp openssl aracıyla doğrudan el sıkışma paketlerini incelemek gerekir:

# Sunucunun sunduğu sertifika zincirini test edin:
openssl s_client -connect example.com:443 -servername example.com
 
# EĞER ZİNCİR EKSİKSE ÇIKTI ŞÖYLEDİR:
# Certificate chain
#  0 s:CN = example.com
#    i:C = US, O = Let's Encrypt, CN = R3
# Verify return code: 21 (unable to verify the first certificate) ❌

Çıktıda yalnızca 0 numaralı sertifika vardır; 1 numaralı ara sertifika yoktur! Doğrulama kodu 21: "İlk sertifika doğrulanamadı!"

Aynı şekilde ücretsiz Qualys SSL Labs (ssllabs.com) testi çalıştırıldığında dev bir turuncu uyarı çıkar:
Chain issues: Incomplete. Grade capped to B!

Cerrahi Operasyon: fullchain.pem Oluşturmak

Bu patolojiyi düzeltmek Nginx veya Apache yapılandırmasında sertifika dosyalarını doğru hiyerarşiyle birleştirmekten ibarettir.

Nginx İçin Doğru Reçete:

Nginx, sunucu sertifikası ile ara sertifikaların tek bir dosya içinde ardışık olarak bulunmasını şart koşar. Bu birleşik dosyaya fullchain.pem veya bundle.crt denir.

Dosyaları doğru sırada birleştirin:

# SIRALAMA ÇOK ÖNEMLİDİR!
# Önce SİZİN sertifikanız, ardından ARA sertifika (CA Bundle) gelmelidir!
cat example_com.crt ca_bundle.crt > fullchain.crt

Ardından Nginx yapılandırmasına bu birleşik dosya verilir:

server {
    listen 443 ssl http2;
    server_name example.com;
 
    # YALNIZCA KENDİ SERTİFİKANIZI DEĞİL, BİRLEŞİK DOSYAYI VERİN!
    ssl_certificate /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
 
    # ...
}

Nginx'i yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Tekrar openssl s_client çalıştırdığınızda zincirin tamamlandığını görürsünüz:

Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
Verify return code: 0 (ok) ✅

Apache İçin Doğru Reçete:

Apache 2.4.8 öncesi sürümlerde ara sertifika ayrı bir direktifle tanımlanırdı:

SSLCertificateFile /etc/ssl/certs/example_com.crt
SSLCertificateKeyFile /etc/ssl/private/example_com.key
SSLCACertificateFile /etc/ssl/certs/ca_bundle.crt

Modern Apache sürümlerinde (2.4.8 ve sonrası) Nginx gibi doğrudan fullchain.crt dosyasını SSLCertificateFile satırına vermek en temiz yöntemdir.

API ve Mobil Uygulama Çöküşleri: Arka Planda Ölen İstekler

Bu hatanın en tehlikeli kurbanları web kullanıcıları değil, mobil uygulamalardır (iOS / Android Native App).

Web tarayıcıları eksik halkayı AIA ile bir şekilde yamamaya çalışırken; iOS ve Android'in yerel HTTP kütüphaneleri (URLSession, OkHttp), güvenlik gereği eksik zincirli bir TLS bağlantısını anında reddeder.

  • Kullanıcı web sitesini telefonun Safari tarayıcısında açar: Site çalışır.
  • Kullanıcı şirketin mobil uygulamasını açar: Ekranda sonsuz yükleme ikonu döner, "Ağ bağlantısı kurulamadı" hatası verir!
  • Geliştirici haftalarca mobil uygulamadaki Swift/Kotlin kodlarında bug arar; oysa tek suçlu Nginx'te eksik bırakılmış 1 kilobaytlık ara sertifika metnidir.

Sonuç

Sterilizasyon zincirinin tek bir halkasını koparırsanız, ameliyatınız artık steril değildir; bazı hastaların bağışıklığının bunu tolere edebilmesi sizin haklı olduğunuzu göstermez.

SSL/TLS bir his meselesi değil, matematiksel ve hiyerarşik bir güven zinciridir. Kendi telefonunuzda yeşil kilidi görmeniz işinizin bittiği anlamına gelmez. Sertifikanızı kurduktan sonra mutlaka openssl veya SSL Labs ile zincirin tamlığını doğrulayın. Eksik halkayı sunucunuza ekleyin; masaüstü müşterilerinizi ve mobil API servislerinizi kapıda şüpheli damgasıyla geri çevirmeyin.