Bölüm 12: Sertifika Zinciri

Kilit kuruldu, anahtar iki uçta hazır. Oturum anahtarını üreten el sıkışmayı izlerken bir cümleyi kasten hızlı geçtim: sunucunun sertifikası doğrulandı.

Perdeyi kaldırıyorum. Karşı tarafın gerçekten o olduğunu söyleyen şey anahtar değil, bir imza zinciri. Peki o zincirin ucu nerede duruyor?

Bir imza neyi mühürlüyor?

Sertifika tek bir iş yapan bir belge. Bir açık anahtarı belirli bir varlığa bağlıyor. O varlık bir kişi olabilir, bir web sitesi olabilir, kenardaki bir router olabilir. Belgeyi üreten taraf anahtarın sahibi değildir; bağı kuran şey bir sertifika otoritesi. Sıra şöyle işliyor. Varlık açık anahtarını otoriteye kaydettirir ve kimliğinin kanıtını sunar. Otorite o kimliği anahtara bağlayan belgeyi üretir, sonra belgeyi kendi özel anahtarıyla imzalar.

Doğrulama ters yönde çalışıyor. Okuyan taraf otoritenin açık anahtarıyla sertifikanın imzasını doğruluyor; imza tutuyorsa belgede açıkça yazan açık anahtarın gerçekten o varlığa ait olduğuna güvenebiliyor. Kazancı burada görüyorsun. Hiç tanımadığın bir sunucunun anahtarına güvenmek için tek bir anahtara, otoritenin anahtarına güvenmen yetiyor. Kasa benzetmesi hâlâ iş görüyor ama tek başına yetmiyor. Sağlam bir kilit, arkasında kimin durduğunu söylemez.

İmza belgenin tamamına değil, sabit boyutlu özetine atılıyor ve sebebi maliyet: uzun bir metni doğrudan açık anahtarla şifrelemek pahalı. Sayısal imza, özet fonksiyonunun çakışmaya dayanıklı olmasını şart koşuyordu ve bu şartın sertifikada neden hayati olduğu 2008’de görüldü. Araştırmacılar aynı MD5 özetini veren iki belge üretti, zararsız olanını bir otoriteye imzalattı ve imzayı ötekine, kendi yazdıkları sahte bir ara otorite sertifikasına taşıdı. Bugünkü el sıkışma MD5 ile SHA-1’i bıraktı, SHA-256 kullanıyor.

Doğrulama tuttuğunda üç şeyi birden öğreniyorsun. Belgeyi sahibi imzaladı, başkası imzalamadı, imzalanan şey de elindeki metnin ta kendisi.

MITM saldırısında matematik doğru çalışıyordu; yanlış olan, açık anahtarın sahibiydi. Sertifikanın kapattığı boşluk bu. Aynı boşluk isim çözümlemesinde de vardı: yetkili sunucudan dönen kayıt, kim tarafından yazıldığına dair hiçbir kanıt taşımıyordu.

Sertifikayı göstermek bile yetmiyor. Sunucu onu telde açıkça yolluyor ve kopyalanması kimseyi zorlamaz. Bu yüzden sunucu bir mesaj daha gönderiyor: CertificateVerify. O mesajda el sıkışmanın o ana kadarki tamamını, sertifikanın özel anahtarıyla imzalıyor. Kopyalanmış sertifika bu adımı geçemez.

Bu kanıt tek yönlü isteniyor. Sunucunun sertifikası var, senin çoğunlukla yok. İnternette kimlik iki biçimde kuruluyor: ad ile parola ya da ad ile açık anahtar sertifikası. Sunucu ikincisini kullanıyor, sen birincisini.

Zincirin ucunu kim koyuyor?

Sunucunun gönderdiği şey tek bir sertifika değil; sıralı bir liste. Yaprak sertifika ilk sırada olmak zorunda. Sonraki her sertifika bir öncekini doğrudan imzalamış olmalı.

certificate_list
  [0] yaprak       subject = example.com      issuer = Ara Otorite A
  [1] ara otorite  subject = Ara Otorite A    issuer = Kök Otorite K
 ([2] kök          subject = Kök Otorite K    issuer = Kök Otorite K)

Parantez içindeki satır telde yok. Güven çıpaları zincirle taşınmıyor; işletim sisteminden ve tarayıcıdan geliyor. Tipik doğrulama zinciri bu yüzden 3 sertifikadan oluşuyor ama telde ikisi gidiyor. DNSSEC imzasında da aynı kural vardı: zincirin ucundaki anahtar dışarıdan gelir.

Yol doğrulamanın girdisi işte o güven çıpası. Zincirin dört koşulu birden tutması gerekiyor. Her sertifikanın öznesi bir sonrakinin ihraççısıdır, ilk halkayı güven çıpası vermiştir, sonuncusu doğrulanacak sertifikadır, hepsi ilgili anda geçerlidir. Bir sertifika aynı yolda iki kez görünemez; döngüyle güven üretmenin kapısı böyle kapanıyor.

Bir anahtarın sertifika imzalamaya yetkili olup olmadığını iki uzantı söylüyor. basicConstraints içindeki cA bayrağı, o anahtarla başka sertifikaların imzasının doğrulanıp doğrulanamayacağına karar veriyor. Uzantı yoksa ya da bayrak yoksa cevap hayır; yaprak sertifika kendini ara otorite ilan edemiyor. Aynı uzantıdaki pathLenConstraint, bu sertifikadan sonra zincire girebilecek azami ara otorite sayısı. Sıfır yazıyorsa hiç giremez.

İkinci uzantı keyUsage ve o bir bit dizisi. Her bitin numarası standartta sabit:

Beşinci bit açık değilse zincirin o halkası kurulamaz. İstemci ayrıca, desteklemediği kritik bir uzantı taşıyan sertifikayı reddetmek zorunda.

Zincirin ucundaki güven çıpalarını kim koyuyor? Somut bir liste var. Mozilla’nın CCADB üstünden yayımladığı kök deposu raporunda Ağustos 2026 itibarıyla 172 kök sertifika duruyor. Bunların 121’i “Websites” güven bitini taşıyor, yani TLS’te geçerli sayılıyor; deponun %70,3’ü. O 121 kök 47 ayrı kuruluşa ait. Firefox ve bu listeyi kullanan pek çok Linux dağıtımı, senin adına kırk yedi kuruluşa güveniyor. Chrome, Apple ve Microsoft kendi depolarını tutuyor ama listeler büyük ölçüde örtüşüyor. Anahtar dağılımı da aynı listede yazılı ve TLS’te geçerli o 121 kökün hepsini kapsıyor. 59’u RSA 4096 bit, 37’si secp384r1 eğrisi, 21’i RSA 2048 bit kullanıyor. Bu üçü 117 kök ediyor. Kalan dördü secp256r1 ve secp521r1 eğrilerinde.

Bu listenin asıl gücü, bir otorite kötü davrandığında ortaya çıkıyor. Yanlış verilmiş bir sertifikanın iki yaptırımı var ve ikisi aynı ağırlıkta değil. Dar olanı şu: otoriteyle çalışıp o tek sertifikayı iptal ettirirsin. Sorun çözülür, otorite yerinde kalır, aynı hata ertesi gün tekrarlanabilir. Geniş olanı otoriteyi kök deposundan düşürtmek. Bunun için güven çıpası listelerini tutanlarla konuşman gerekiyor. O otoritenin verdiği bütün sertifikalar aynı anda geçersizleşir; tek tek iptal edilmelerine gerek kalmaz, çünkü yol doğrulamanın ikinci koşulu artık tutmuyor. Zincirin ilk halkasını veren taraf bir güven çıpası değildir. Bedeli de o ölçüde ağır. Depodan düşen otoritenin müşterisi olan her site aynı anda tarayıcıda uyarı vermeye başlar. Kararı veren taraf da bunu bilir. Karar bu yüzden nadir, yavaş ve kanıt ister. Yine de verildiği oluyor: Hollandalı DigiNotar 2011’de sahte Google sertifikaları yüzünden depolardan düştü ve birkaç hafta içinde iflas etti. Symantec’in ve Entrust’ın sertifikaları da yıllar içinde aynı yoldan geçti.

Sertifika hangi adı taahhüt ediyor?

Belgenin kendisi üç üst alandan oluşuyor: imzalanacak gövde, imza algoritmasının adı ve imzanın kendisi. İmza, gövdenin baytlara dökülmüş hâlinin üstüne atılıyor; o dökümün kurallarına DER deniyor ve tek bir gövdenin tek bir bayt dizisine karşılık gelmesini garanti ediyor. Gövdenin içinde sırayla şunlar duruyor:

tbsCertificate
  version               v3  (INTEGER 2)
  serialNumber          pozitif tamsayı, en çok 20 bayt
  signature             imza algoritmasının adı
  issuer                ihraççının adı
  validity              notBefore / notAfter
  subject               öznenin adı
  subjectPublicKeyInfo  mühürlenen açık anahtar
  extensions            basicConstraints, keyUsage, subjectAltName, ...
signatureAlgorithm
signatureValue

Seri numarası otoritenin verdiği pozitif bir tamsayı ve tek başına anlam taşımıyor. Bir sertifikayı tekilleştiren şey ihraççı adı ile seri numarasının çifti. Uyumlu otoriteler 20 bayttan uzun seri numarası kullanamıyor, çünkü iptal listeleri sertifikayı bu numarayla anıyor.

Geçerlilik iki tarihle çiziliyor ve iki uç da dahil: notBefore ve notAfter. Kodlamada eski bir miras duruyor. 2049 ve öncesi UTCTime ile yazılıyor, 2050 ve sonrası GeneralizedTime ile. Bitiş tarihi tanımsız olan sertifika bile bir tarih taşıyor: 99991231235959Z.

Günlük hayatta çarptığın alan ise ad doğrulaması. Sertifikanın hangi ad için geçerli olduğunu subjectAltName uzantısı söylüyor. Alan adı orada dNSName içinde IA5String olarak duruyor. Karşılaştırma büyük-küçük harf ayrımı gözetmiyor. IP adresi de yazılabiliyor: iPAddress alanına ağ bayt sırasıyla, IPv4 için tam 4 bayt, IPv6 için tam 16 bayt. Uzantıdaki adlar açık anahtara kesin biçimde bağlı sayıldığı için otorite oradaki her adı tek tek doğrulamak zorunda. Her satır bir taahhüt.

Eşleşme iki kimlik arasında aranıyor. Sunucunun sertifikada gösterdiğine sunulan kimlik, istemcinin adres çubuğundaki addan kurduğuna referans kimlik deniyor. Karşılaştırma etiket etiket yapılıyor ve her etiket tutmak zorunda. Joker karakter de yalnız en soldaki etikette durabiliyor.

Son iki satır sezgiye ters. Joker tek bir etiketi karşılıyor; ne iki alt seviyeyi kapsıyor ne de çıplak alan adını. Eski bir alışkanlık da kapandı: sertifikada dNSName varsa istemci Common Name alanına bakarak eşleşme aramamalı. Ad doğrulamasının yeri artık uzantı.

Yanlış verilmiş sertifikayı kim fark ediyor?

Bir sertifika verildikten sonra da yanlış olabilir. Anahtar çalınır, otorite yanılır, ya da adı sertifikada geçen taraf o belgeyi hiç istememiştir. İlk cevap iptal listesi: otoritenin ya da yetkilendirdiği bir birimin yayımladığı imzalı bir liste. Tam bir liste, kapsamındaki süresi dolmamış bütün iptal edilmiş sertifikaları taşıyor; süresi dolan düşer, liste sonsuza kadar büyümez.

Sebepler numaralı ve adlı: 1 keyCompromise, yani anahtarın ele geçmesi; 2 cACompromise, otoritenin kendisinin ele geçmesi; 10 aACompromise. Aradaki 7 hiç kullanılmıyor.

Koca listeyi indirmeden tek bir sertifikanın durumu da sorulabiliyor. Yolun adı çevrimiçi durum sorgusu, kısaltmasıyla OCSP (Online Certificate Status Protocol). Üç kesin yanıt veriyor: good, revoked, unknown. İlkini yanlış okumak kolay: good yalnızca “iptal kaydı yok” demek; sertifikanın hiç verilmiş olduğunu bile garanti etmiyor. unknown ise çoğunlukla yanlış kapıyı çaldığını gösteriyor. Nereye soracağını da sertifikanın kendisi söylüyor. authorityInfoAccess uzantısı iki adres taşıyor: eksik ara sertifikayı nereden alacağın ve durumu kime soracağın.

OCSP’nin kendi tasarımında iki kusur var ve ikisi de tarayıcıyı zor durumda bırakıyor. Birincisi gecikme: her bağlantıda üçüncü bir sunucuya bir soru daha sormak, sayfa açılışına bir gidiş-dönüş daha ekliyor. İkincisi ve daha ağırı mahremiyet: o soruyu sorarken hangi siteye bağlandığını sertifika otoritesine söylemiş oluyorsun. Şifreli bağlantı kurmak için attığın adım, gezinme geçmişini üçüncü bir tarafa sızdırıyor.

Çözüm rolleri ters çeviriyor. OCSP stapling (zımbalama) denen yöntemde durumu tarayıcı değil sunucu soruyor: kendi sertifikasının OCSP cevabını önceden alıyor, imzalı hâliyle saklıyor ve el sıkışmanın içine iliştirip sana gönderiyor. Cevap otoritenin imzasını taşıdığı için sunucu onu uyduramıyor; geçerlilik süresi de cevabın içinde yazılı olduğu için eskisini sonsuza kadar süremiyor. Tarayıcı hiçbir yere soru sormuyor: ne gecikme var ne sızıntı.

Geriye bir açık kalıyor. Sunucu zımbayı hiç iliştirmezse tarayıcı ne yapacak? Cevap uzun süre “devam et” oldu, çünkü ağ arızalarında siteyi kırmak istemediler. Saldırgan da bunu kullanabilirdi: zımbayı yutması yeterliydi. OCSP Must-Staple uzantısı bu açığı kapatmak için sertifikaya “benim cevabım her zaman zımbalanmış gelecek” diye yazıyordu; cevap gelmezse tarayıcı bağlantıyı reddediyordu.

İptal, yanlış verilmiş bir sertifikayı ancak birileri fark ederse işe yarıyor. Fark etmeyi sağlayan mekanizmanın adı Certificate Transparency. Verilen sertifikalar yalnızca-ekleme günlüklerine yazılıyor. Günlük yanlış verilmeyi engellemiyor; adı sertifikada geçen tarafın bunu görmesini sağlıyor. Chrome 2018’den beri günlüğe yazıldığını kanıtlamayan bir sertifikayı hiç kabul etmiyor. Kendi alan adını crt.sh gibi bir arama sitesinde sorgularsan o ada verilmiş her sertifikayı listelenmiş görürsün.

Günlük, kabul ettiği zincire imzalı bir zaman damgası döndürüyor. O damga bir kayıt değil, bir söz: bu girdiyi ağaca ekleyeceğim. Söz, Maximum Merge Delay içinde tutulmak zorunda; tutulmazsa günlüğün kendisi suçüstü yakalanıyor. Yalnızca-ekleme özelliği Merkle ağacından geliyor, çünkü yaprak olmayan her düğüm çocuklarının hash’i. Bugünkü ağacın dünküyü kapsadığı bu sayede ucuza kanıtlanabiliyor; geçmişi sessizce silmek mümkün olmuyor. Günlüğe atılan her zincirin de günlüğün tanıdığı bir güven çıpasında bitmesi gerekiyor.

OCSP’nin hikâyesinin sonu beklenmedik oldu: emekliye ayrılıyor. Otoritelerin ortak kurallarını yazan CA/Browser Forum 2023’te kararı tersine çevirdi; Mart 2024’ten beri iptal listesi yayımlamak zorunlu, OCSP ise isteğe bağlı. En çok sertifika veren otorite olan Let’s Encrypt, zirvede ayda 340 milyar sorgu karşılayan OCSP hizmetini Ağustos 2025’te tamamen kapattı ve Must-Staple taşıyan sertifika vermeyi bıraktı. Gerekçe ikinci kusurdu: sorguyu kim işletirse işletsin, kimin hangi siteye girdiğini görüyor.

İptali tarayıcılar kendi üstüne aldı. Firefox, CT günlüklerindeki bütün sertifikaların iptal durumunu sıkıştırılmış tek bir yapıda (CRLite) kullanıcıya indiriyor; günde ortalama 300 kilobayt. Tarayıcı artık kimseye soru sormadan, kendi elindeki tabloya bakarak karar veriyor. Chrome da seçtiği iptalleri benzer bir listeyle (CRLSet) dağıtıyor.

İptalin yavaş ve güvenilmez olduğu kabul edilmiş durumda; asıl çözüm başka yerden geliyor. Sertifika ömrü hızla kısalıyor. 15 Mart 2026’dan önce azami ömür 398 gündü, bugün 200 gün. Takvim 15 Mart 2027’den sonra 100 güne, 15 Mart 2029’dan sonra 47 güne iniyor. İptal takvimi de sıkı: ağır durumlarda 24 saat, hafif durumlarda kesin üst sınır 5 gün, ara otorite sertifikasında 7 gün. Ömrü 7 günü aşmayan sertifikalar zaten iptal yükümlülüğünün dışında tutuluyor.

Bu takvim elle yenilenen sertifikayla yaşanamaz; onu mümkün kılan şey yenilemenin protokolleşmesi. ACME (RFC 8555) sertifika istemeyi, alan adının sahipliğini kanıtlamayı ve süresi dolmadan yenilemeyi bir istemcinin kendi başına yürüttüğü bir akışa çevirdi. Let’s Encrypt’in ücretsiz sertifikaları bu protokolle veriliyor ve web’in büyük bölümü bugün o zincirin altında; kısa ömür, insan eli değmeyen bir yenileme varsa sorun olmaktan çıkıyor.

Aynı openssl s_client çağrısı, sonuna -showcerts eklendiğinde sunucunun gönderdiği zinciri olduğu gibi basıyor:

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

Çıktıda yaprak sertifika en üstte, ara otorite hemen altında duruyor. Kök yok, çünkü zaten sende. Tek bir sertifikanın künyesini görmek istersen, çıktıdaki BEGIN/END bloğunu bir dosyaya kaydet:

openssl x509 -in yaprak.pem -noout -subject -issuer -dates -ext subjectAltName

Dönen birkaç satır bu bölümün özeti: belge kime verildi, kim imzaladı, hangi tarihler arası geçerli, hangi adları taahhüt ediyor.

Özet

• Sertifika bir açık anahtarı bir ada bağlar ve bağı otorite kurar; doğrulama ters yönde, otoritenin açık anahtarıyla yapılır.
• Zincirin ucu sertifikadan çıkmaz: güven çıpalarını işletim sistemi ve tarayıcı taşır, kök telde hiç gönderilmez.
• Ad eşleşmesi subjectAltName uzantısında aranır; joker yalnız en soldaki etiketi karşılar ve çıplak alan adını kapsamaz.
• Anlık iptal sorgusu emekliye ayrılıyor: OCSP’nin mahremiyet bedeli ağır bulundu; iptal bilgisini tarayıcılar toplu hâlde kendileri dağıtıyor.
• İptal yavaş olduğu için ömür kısalıyor: azami sertifika ömrü basamak basamak düşürülüyor, kısa ömürlüler iptal yükümlülüğünün dışında kalıyor.
• Certificate Transparency yanlış verilmeyi engellemez, görünür kılar; yaptırımı asıl kök deposu uygular.

Kanal kuruldu, kilit takıldı, karşı tarafın kim olduğu doğrulandı. Geriye tek bir iş kaldı ve bu bölüm boyunca ona hiç bakmadık: şimdi ne göndereceksin?