Bölüm 11: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 yönlendirici 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ını sertifikaya uyguluyor ve içindeki açık anahtar ortaya çıkıyor. Kazancı da tam 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 geri döndürülemez olmasını şart koşuyordu; sertifikada işe yarayan tam olarak o şart. 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.

Ortadaki adam saldırısında matematik doğru çalışıyordu; yanlış olan, açık anahtarın sahibiydi. Sertifikanın kapattığı boşluk tam olarak 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 demirleri 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 demirlerini kim koyuyor? Somut bir liste var. Mozilla’nın CCADB üstünden yayımladığı kök deposu raporunda 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. Tarayıcın senin adına kırk yedi kuruluşa güveniyor. 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 demiri 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.

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. Üç 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; ve cevabın kendi zaman damgası olduğu için bayatı da sürülemiyor. 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 — ve saldırgan da tam olarak bunu kullanabilirdi: zımbayı yutması yeterliydi. OCSP Must-Staple uzantısı bunu kapatıyor, sertifikaya “benim cevabım her zaman zımbalanmış gelecek” diye yazıyor ve gelmezse tarayıcı bağlantıyı reddediyor.

İ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.

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.

İptalin yavaş ve güvenilmez olduğu kabul edilmiş durumda; çözüm başka yerden geliyor. Sertifika ömrü hızla kısalıyor. 2026-03-15’ten önce azami ömür 398 gündü, bugün 200 gün. Takvim 2027-03-15’ten sonra 100 güne, 2029-03-15’ten 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.

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 dört satır bu bölümün tamamı: belge kime verildi, kim imzaladı, hangi tarihler arası geçerli, hangi adları taahhüt ediyor.

Özet

Peki, ne öğrendik?

• 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 demirlerini 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.
• İ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 tam olarak ne göndereceksin?