Certificate Authority Nedir? İç CA ile Public CA Farkı

Bir sürücü belgesini geçerli kılan şey üzerindeki fotoğraf değildir. Kartın üstündeki bilgilerin doğru olduğunu söyleyen bir kurumdur: Nüfus Müdürlüğü sizi tanımış, ehliyet sınavınızı görmüş ve belgeyi kendi adına basmıştır. Polis yolda sizi durdurduğunda aslında sizi tanımaz, belgeyi tanır; belgeyi tanımasının sebebi de onu basan kurumu zaten tanıyor olmasıdır.

Dijital sertifika tam olarak böyle çalışır. Bir sunucunun “ben glpi.ad.sercebilisim.com sunucusuyum” demesi tek başına hiçbir şey ifade etmez, çünkü aynı cümleyi kuran sahte bir sunucu da aynı kolaylıkla söyleyebilir. Bu iddiayı bağlayıcı yapan şey, iddianın altına imza atan üçüncü bir taraftır. O tarafa sertifika otoritesi (Certificate Authority, kısaca CA) denir.

Bu makale sertifikanın nasıl üretildiğini değil, kimin üreteceğine nasıl karar verdiğinizi anlatıyor. Kurumsal ağda üç seçenek var: kendi iç sertifika otoritenizi kurmak, dışarıdan bir public CA’dan almak, ya da hiç kimseye sormadan kendi kendinize imzalamak. Üçü de doğru cevap olabilir; hangisinin ne zaman doğru olduğu bu yazının konusu. Kararı hemen görmek isterseniz doğrudan iç CA ile public CA karşılaştırmasına geçebilirsiniz. Bu makale Siber Güvenlik ana hizmetimizin kimlik ve şifreleme koluna odaklanır.

Sertifika Otoritesi Nedir ve Hangi Sorunu Çözer?

Sertifika otoritesi, bir açık anahtarın gerçekten iddia edilen kişiye veya sunucuya ait olduğunu onaylayan ve bu onayı kendi imzasıyla mühürleyen kurumdur. Ürettiği belgeye sertifika, belgenin içindeki “bu isim bu anahtara aittir” iddiasına da bağlama (binding) denir.

Çözdüğü sorun şifreleme değil, kimlik. Bu ayrım en sık atlanan yerdir, o yüzden üstünde duralım. İki taraf arasında şifreli bir kanal kurmak için sertifikaya gerek yoktur; iki bilgisayar birbiriyle anahtar değiş tokuşu yapıp kimseye okutmadan konuşabilir. Ama şifreli konuşmanın kiminle yapıldığını bilmiyorsanız, şifrelemenin kendisi sizi korumaz. Araya giren biri de sizinle mükemmel şifreli bir kanal kurabilir.

Sertifika Otoritesi Olmasaydı Ne Kırılırdı?

Sertifika otoritesi olmayan bir ortamda güven, tek tek elle kurulmak zorundadır ve maliyeti makine sayısıyla çarpılarak büyür.

Somutlaştıralım. Kurumunuzda iç servislerin sayısı mütevazı olsun: bir dosya sunucusu, bir envanter sistemi, bir dizin sunucusu, bir yedekleme arayüzü, bir kamera kayıt sistemi, bir de yazıcı yönetim paneli. Altı servis. İstemci sayısı da 40 olsun.

Sertifika otoritesi yoksa her servis kendi sertifikasını kendi imzalar ve o sertifikanın her istemcide ayrı ayrı tanıtılması gerekir:

• 6 servis × 40 istemci = 240 ayrı güven kaydı, hepsi elle.
• Bir servisin sertifikası yenilendiğinde o servise ait 40 kayıt yeniden gidilip güncellenir.
• Yeni bir bilgisayar kurulduğunda altı sertifikanın altısı da o makineye tek tek tanıtılır, biri unutulursa o servis o makinede kırık görünür.
• Ve en kötüsü: bir gün gerçekten sahte bir sunucu belirdiğinde, kullanıcılarınız zaten aylardır sertifika uyarısını tıklayıp geçmeye alıştıkları için fark etmezler.

Sertifika otoritesi bu 240 kaydı tek bir kayda indirir. İstemcilere yalnız CA’nın kök sertifikası tanıtılır; o kurumun bastığı bütün belgeler otomatik olarak geçerli sayılır. Polisin her sürücüyü ayrı ayrı tanımak yerine belgeyi basan Nüfus Müdürlüğü’nü bir kez tanıması gibi.

İmza Neden Taklit Edilemiyor? Anahtar Çifti

Sertifikanın üstündeki imza, CA’nın yalnız kendisinde bulunan bir anahtarla üretilir ve herkeste bulunan başka bir anahtarla doğrulanır. Taklit edilememesinin sebebi budur: doğrulamayı herkes yapabilir, üretmeyi yalnız CA yapabilir.

Buraya kadar okurken bir şey eksik kaldıysa haklısınız. “Üçüncü bir taraf altına imza atar” cümlesini şimdiye kadar gerekçesiz kabul etmenizi istedik. Sahte bir sunucu o imzayı neden kopyalayıp kendi sertifikasına yapıştıramıyor sorusunun cevabını şimdi koyuyoruz, çünkü geri kalan her şey bunun üstünde duruyor.

CA’nın iki anahtarı vardır ve bunlar matematiksel olarak birbirine bağlıdır:

• Özel anahtar (private key): yalnız CA sunucusunda durur, hiçbir zaman hiçbir yere gönderilmez. Sertifikayı imzalayan budur.
• Açık anahtar (public key): CA’nın kök sertifikasının içindedir, yani zaten sizin bilgisayarınızda kayıtlıdır. İmzayı doğrulayan budur.

İkisi arasındaki ilişki tek yönlüdür. Açık anahtarla bir imzanın doğru olup olmadığını hesaplayabilirsiniz, ama aynı açık anahtarla yeni bir imza üretemezsiniz. Sahte sunucunun elindeki de yalnız açık anahtardır; imzayı görebilir, kopyalayabilir, ama kendi sertifikasının içeriğine uyan yeni bir imza hesaplayamaz. Kopyaladığı imza başka bir belgeye ait olduğu için doğrulama anında tutmaz.

Bunu kendi lab ortamımızda görelim. Bir domain controller’ı taklit eden sahte bir sertifika ürettik: adını da, verenini de gerçeğiyle birebir yazdık. Windows’ta ikisini yan yana açtığınızda, Issued to ve Issued by satırları harfi harfine aynıdır. Tek fark güven durumundadır: gerçek sertifika bir güven köküne kadar doğrulanır, sahtesi doğrulanamaz. Çünkü isim kopyalanabilir, imza kopyalanamaz.

Kısacası, imzayı doğrulayan anahtar kamuya açıktır; imzayı üreten anahtar yalnızca CA’nın içindedir. Sahtekâr birincisiyle ismi kopyalar, ama ikincisi olmadan o ismin altına geçerli imzayı atamaz.

Belge Kendi Kanıtını Taşır

Benzetmenin en sağlam durduğu yer de burasıdır: sürücü ehliyetini cebinde taşır ve bir polis onu kendi başına, elindekiyle doğrulayabilir. Belgenin gerçekliği belgenin üstündedir, kimseye sormaya gerek yoktur. Sertifika da tam böyle çalışır: kanıt belgenin içinde gezer, onu gören ve CA’nın açık anahtarını zaten elinde tutan herkes gerçekliğini yerinde hesaplar.

Benzetmenin inceldiği tek yer de dürüstçe söylenmeli, ama o incelme bilgisayarın lehinedir: iyi bir sahteci holografik bir mührü yeterli emekle taklit edebilir, kriptografik imzayı edemez. Polisin gözü aldanabilir, imzanın matematiği aldanmaz. Belgenin dijital hali, fizikselinden daha da sağlamdır.

Sonuç: İstemci CA’ya Hiç Sormaz

Buradan çıkan sonuç, sertifika mimarisinin en çok yanlış bilinen tarafıdır. Bir istemci sertifikayı doğrularken sertifika otoritesiyle hiç konuşmaz. CA’nın açık anahtarı zaten kendisindedir, doğrulamayı kendi işlemcisinde yapar, ağa tek bir paket çıkmaz.

Bu yüzden CA sunucusunun sürekli ayakta olması gerekmez. Kapalı olabilir, bakımda olabilir, hatta yıllar önce emekliye ayrılmış olabilir; bastığı sertifikalar doğrulanmaya devam eder. Sistemin milyarlarca bağlantıya ölçeklenebilmesinin sebebi de budur: hiç kimse merkeze sormuyor.

CA’nın adresi yalnız yeni sertifika isterken gerekir, doğrularken değil. O ayrımı aklınızda tutun, bir sonraki bölümdeki zincir mantığı ona dayanıyor.

Güven Zinciri: Kök CA, Ara CA ve Sunucu Sertifikası

Güven zinciri, bir sertifikanın geçerliliğinin tek tek imzalar üzerinden en tepedeki kuruma kadar takip edilebilmesidir. Zincir üç halkadan oluşur ve her halka bir üstündekini imzalar.

Sürücü belgesi dünyasında karşılığı doğrudan kurulabilir, üstelik uydurmaya da gerek yok: Türkiye’de sürücü belgesini İçişleri Bakanlığı adına İl veya İlçe Nüfus Müdürlüğü basar. En tepede yetkiyi elinde tutan bakanlık vardır, altında belgeyi fiilen basan nüfus müdürlükleri, en altta da cebinizdeki kart. Polis kartı kontrol ederken Tire Nüfus Müdürlüğü’nü ayrıca tanımak zorunda değildir; o müdürlüğün bağlı olduğu bakanlığı tanır, gerisi kendiliğinden gelir.

Zincirin mantığı şu: istemci, sunucudan gelen belgeye bakar, “bunu kim imzalamış” diye sorar, bir üst halkaya çıkar, oradan bir üste çıkar ve kendi güvendiği listede kayıtlı bir kuruma ulaşırsa belgeyi kabul eder. Ulaşamazsa reddeder. Kabul veya ret, tek bir sorunun cevabıdır: zincir bende kayıtlı birine çıkıyor mu?

Kök Sertifika İstemcilere Nasıl Ulaşır?

Zincirin çalışması için kök sertifikanın her istemcide önceden kayıtlı olması gerekir; bu kayda güven deposu (trust store) denir ve işletim sisteminin güvendiği kurumların listesidir. Yukarıdaki 240 kayıt yerine 1 kayıt hesabını mümkün kılan şey tam olarak budur, o yüzden bu tek kaydın oraya nasıl gittiği önemlidir.

Kök sertifikanın o listeye girmesinin üç yolu var ve hangisinin geçerli olduğunu cihazın kim tarafından yönetildiği belirler:

1. Domain üyesi makineler: otomatik. Active Directory ortamında Enterprise CA kurulduğunda kök sertifika dizine yazılır ve domain üyesi bilgisayarlar onu Group Policy üzerinden kendiliğinden güven deposuna alır. Yönetici tarafında ek iş yoktur; bu, iç CA’nın en büyük pratik kazancıdır. Sertifika otoritesinin diğer sunucu rolleri arasında nereye oturduğunu Windows Server rehberimizin AD CS bölümünde özetledik.
2. Domain dışı yönetilen cihazlar: merkezi dağıtım. Mobil cihazlar ve domaine katılmayan makineler kök sertifikayı bir cihaz yönetim aracıyla alır.
3. Yönetilmeyen cihazlar: elle. Misafir bilgisayarı, taşeron dizüstüsü, kişisel telefon. Sertifika tek tek yüklenir.

Kök Sertifikanın Neden Ayrı Tutulması Gerekir?

Kök sertifika, zincirin tamamının değerini taşıdığı için ele geçirilirse kurumun bütün sertifika altyapısı bir anda geçersizleşir. Kök çalınan bir yapıda saldırgan istediği isme istediği belgeyi basabilir ve istemcileriniz hepsini kabul eder.

Bu yüzden ciddi kurulumlarda kök CA ile günlük sertifikaları basan ara CA ayrı makinelerdir; kök makine çoğunlukla kapalı tutulur, yalnız ara CA’nın belgesini yenilerken açılır. Küçük ve orta ölçekli kurumlarda tek katmanlı bir yapı (kök CA’nın doğrudan sertifika basması) yaygındır ve çalışır, ama bunun bilinçli bir taviz olduğunu bilerek yapmak gerekir.

Sertifikalar Yalnız HTTPS İçin Değildir

Sertifika deyince akla önce tarayıcıdaki kilit gelir, ama HTTPS buzdağının yalnız görünen ucudur. Aynı mekanizma bir kurumun içinde çok daha fazla yerde sessizce çalışır, ve nerelerde olduğunu bilmek kararı vermeden önce işe yarar: sertifikaya dayanan iç servis sayısı arttıkça, hepsini tek elden karşılayacak bir iç CA’nın değeri artar. Kilidin arkasındaki protokolün kendisi, yani şifresiz bir bağlantıda tam olarak neyin sızdığı ve TLS el sıkışmasının nasıl işlediği, HTTP ve HTTPS nedir rehberinin konusudur.

Şifreli kanallar. Bir sunucuya bağlanırken hem karşınızdakinin doğru sunucu olduğunu doğrulamak hem trafiği şifrelemek için sertifika kullanılır. Web’de HTTPS, dizin sorgularında LDAPS, mail trafiğinde SMTPS ve IMAPS, uzak masaüstünde RDP, veritabanı bağlantılarında TLS hep aynı kapıdan geçer. Şifreli dizin bağlantısının neden sertifika istediğini ve açık portun neden yetmediğini LDAP rehberimizde ayrıca ele alıyoruz.

Ağa giriş. Sertifika yalnız trafiği değil, ağa kimin gireceğini de denetler. 802.1X ile EAP-TLS, bir cihazı ya da kullanıcıyı kablosuz veya kablolu ağa almadan önce onu parolayla değil sertifikayla doğrular; çalınan bir parola işe yaramaz, çünkü ağ sertifikayı sorar. Aynı mantık VPN’de de geçerlidir (IKEv2/IPsec ve istemci sertifikası). Bu tarafın nasıl kurulduğunu RADIUS rehberimizde, sertifikanın oturduğu bütünü ise kurumsal ağ kurulumu hizmetimizde anlatıyoruz.

Kimlik doğrulama. Bir kullanıcı parola yerine akıllı kartla oturum açtığında (Kerberos PKINIT), kimliğini karttaki sertifika kanıtlar. Servisler birbirine bağlanırken karşılıklı TLS (mTLS) ile iki taraf da sertifikayla tanışır; ne istemci ne sunucu parola bilir.

İmzalama. Buradaki iş şifreleme değil, kimlik ve bütünlük kanıtıdır (yukarıdaki imzalamak ile şifrelemek ayrımı). Kod imzalama bir yazılımın gerçekten üreticisinden geldiğini ve indirildikten sonra değişmediğini kanıtlar; belge imzalama aynı şeyi bir sözleşme ya da PDF için yapar; S/MIME ise e-postayı hem imzalar hem şifreler.

Bu listeye bakınca kararın neden önemli olduğu netleşir. Bir kurumda bu işlerin çoğu içeride dönüyorsa, her birine ayrı ayrı public sertifika almak yerine domain’in zaten güvendiği tek bir iç CA hepsini karşılar. Hangi sertifikanın bu işlerden hangisine yetkili olduğunu ise sertifikanın içindeki kullanım amacı alanı belirler, ona aşağıda geliyoruz.

İç CA mı Public CA mı? Hangisi Ne Zaman Doğru?

Karar tek soruyla verilir: bu sertifikayı kimin tanıması gerekiyor? Cevap “yalnız bizim makinelerimiz” ise iç CA, “tanımadığım herkes” ise public CA.

Benzetmeyi buradan kurmak en net yolu. Bir fabrikada forklift kullanan operatörün, tesis içinde geçerli bir yetki belgesi vardır. O belgeyi Nüfus Müdürlüğü basmaz, fabrikanın kendisi basar, ve bu bir eksiklik değildir: belgeyi soracak olan tek merci zaten fabrikadır. Aynı operatör tesisten çıkıp yola çıktığında bu belge hiçbir işe yaramaz, çünkü yoldaki polis fabrikanın imzasını tanımak zorunda değildir. Orada resmi ehliyet gerekir.

İç CA ile public CA arasındaki fark tam olarak budur. Teknik olarak ikisi de aynı işi yapar, aynı standarda uyar, aynı gücü taşır. Fark kimin tanıdığındadır.

İç CA Kurmanın Asıl Sebebi Maliyet Değildir

İç CA’nın en çok tekrarlanan gerekçesi tasarruftur ve bu gerekçe zayıftır, çünkü bugün public sertifika almanın ücretsiz ve otomatik yolları var. Asıl sebep başka: public CA iç isimlerinizi basamaz.

Public bir sertifika otoritesi, yalnız sahipliğini ispatlayabildiğiniz gerçek alan adları için belge basar. dc01.ad.sercebilisim.com gibi yalnız iç ağınızda var olan bir isim için dışarıdan sertifika alamazsınız, çünkü o ismin dünya üzerinde bir karşılığı yok. Bu isimleri gerçek bir alan adına taşıyıp public CA’dan sertifika almak da yanlış çözümdür: iç sunucu adlarınızı ve topolojinizi dışarıya bildirmiş olursunuz.

İkinci sebep hız. 802.1X ile ağa giren her dizüstü bilgisayara, her yeni sunucuya, her test makinesine sertifika lazım olduğunda dış bir sürece bağlı kalmak işi durdurur. İç CA’da bu iş otomatik kayıt (autoenrollment) ile makinenin kendi işine dönüşür.

Self-Signed Sertifika Ne Zaman Yeter, Ne Zaman Yetmez?

Self-signed sertifika, hiçbir otoriteye sorulmadan sunucunun kendi kendine imzaladığı belgedir. Kriptografik olarak bir CA sertifikasından zayıf değildir: aynı algoritmalar, aynı anahtar uzunlukları, aynı şifreleme gücü. Eksik olan tek şey, imzayı atanın tanınıyor olmasıdır.

Evde kendi bastığınız bir ehliyet gibi. Kartın üstündeki bilgiler doğru olabilir, laminasyonu düzgün olabilir, hatta fotoğrafınız da yerinde olabilir. Sorun belgenin niteliğinde değil, kimsenin onu basan makamı tanımıyor olmasında.

Yeterli olduğu yer dardır ama gerçektir: tek bir sunucuyla tek bir istemcinin konuştuğu, sertifikayı elle tanıtmanın zahmet olmadığı, ve o güvenin kalıcı olarak tek bir yerde durduğu durumlar. Test ortamları, tek makinelik iç araçlar, kendi kendine konuşan iki servis.

Yetmediği yer ise self-signed’ın klasik tuzağıdır: sertifika birden fazla istemciye dağıtılmaya başlandığı an. O noktadan sonra her yeni makine ayrı bir elle tanıtma işidir ve yukarıdaki 6 × 40 hesabı yeniden devreye girer. İç CA, tam olarak bu eşiği geçtiğinizde gereklidir.

Lab’dan Bir Ölçüm: Self-Signed Çalışıyor, Ama Neye Mal Oluyor

Kendi lab ortamımızda bunun iki ucunu da yaşadık ve ikisi de kayıt altında.

OpenLDAP sunucumuzda (ldap01) LDAPS’i self-signed bir sertifikayla ayağa kaldırdık: /etc/ldap/certs/ altında kendi ürettiğimiz belge, on yıllık geçerlilik, CN=openldap.lab.sercebilisim.com. Çalıştı, hem de tam çalıştı; bağlantı TLS 1.3 ve AES-256 ile kuruldu, şifreleme tarafında hiçbir taviz yok. Aynı şekilde FreeRADIUS sunucusunda 802.1X için gereken sunucu sertifikasını da kendi ürettiğimiz mini bir CA ile bastık.

İkisi de amacına ulaştı, çünkü ikisinde de istemci sayısı birdi. Ama şu soruyu sorduğumuz an tablo değişti: bu RADIUS sunucusuna gerçek dizüstü bilgisayarlarla bağlanacak olsak? PEAP ile ağa giren her istemcinin, sunucunun sertifikasını doğrulaması gerekir; doğrulayabilmesi için de o sertifikayı basan makamı tanıması gerekir. Kırk makineye elle kök sertifika dağıtmak, iç CA kurmaktan uzun sürer. Sertifikaların 802.1X akışında tam olarak nerede devreye girdiğini RADIUS sunucusu nedir rehberimizde, üretim adımlarını ise FreeRADIUS kurulum rehberimizde ele alıyoruz.

Sertifikanın Ömrü: Süre Dolması, Yenileme ve İptal

Sertifika kalıcı bir belge değildir; üzerinde bir başlangıç ve bir bitiş tarihi taşır ve bitiş tarihinden sonra onu kullanan servis çalışmayı bırakır. Bu, sertifika altyapısının en çok arıza üreten yanıdır, çünkü arıza kurulumdan aylar veya yıllar sonra, kimsenin o sistemle ilgilenmediği bir sabah ortaya çıkar.

Ehliyetin yenileme tarihi gibi. Belgeyi aldığınız gün kimse size sorun çıkarmaz; sorun tam olarak unuttuğunuz gün başlar.

Süre Dolmasının Belirtisi Neden Kafa Karıştırır?

Süresi dolan bir sertifikanın belirtisi, sertifikayı işaret etmez. Kullanıcı size “sisteme giremiyorum” der, uygulama “bağlantı kurulamadı” der, log dosyasında el sıkışma hatası görürsünüz. Sunucu ayaktadır, servis çalışıyordur, ağ sorunsuzdur. Değişen tek şey takvimdir.

Bu yüzden yenileme bir hatırlama işi olarak bırakılamaz. İki sağlam yol var:

1. Otomatik kayıt (autoenrollment): İç CA ortamında makineler sertifikalarını kendileri yeniler. Kurulumda bir kez ayarlanır, sonrasında insan müdahalesi gerekmez. İç CA’nın en somut faydalarından biri budur.
2. Envanter ve takvim: Otomatiğin mümkün olmadığı yerlerde (dış servisler, ağ cihazları, elle kurulmuş sistemler) sertifikaların bitiş tarihleri bir listede tutulur ve takvime bağlanır. Liste yoksa yenileme yoktur; hatırlamak bir yöntem değildir. Sunucu ve ağ cihazlarında bu listenin nereye oturduğunu güvenlik sıkılaştırma rehberimizde ele alıyoruz.

İptal: Belge Süresi Dolmadan Geçersiz Kılınabilir

Sertifika iptali, bir belgenin bitiş tarihi gelmeden geçerliliğinin kaldırılmasıdır. Sunucu ele geçirildiğinde, özel anahtar sızdığında veya cihaz kurumdan çıktığında gerekir.

Ehliyete el konması gibi çalışır: kart hâlâ cebinizdedir, üstündeki tarih hâlâ geçerlidir, ama sistemde artık geçersiz olarak işaretlenmiştir. Polisin bunu görebilmesi için bir listeye bakması gerekir.

Dijital tarafta o listenin iki biçimi var: CA’nın düzenli olarak yayınladığı iptal listesi (CRL, Certificate Revocation List) ve tek bir sertifikayı anlık sorgulayan servis (OCSP, Online Certificate Status Protocol). İkisinin de ortak bir zayıflığı vardır ve iç CA kurarken en çok bu ısırır: istemci listeye ulaşamazsa ne yapacağını bilemez. İç CA’da iptal listesinin yayınlandığı adres çoğu zaman iç ağdaki bir sunucudur; dışarıda çalışan bir dizüstü bilgisayar o adrese erişemez ve doğrulama takılır.

Bu yüzden iptal listesinin adresi, CA kurulduktan sonra düzeltilecek bir ayrıntı değil, ilk sertifika basılmadan önce verilmesi gereken bir karardır. Adres her sertifikanın içine basıldığı an gömülür; sonradan değiştirmek yalnız yeni sertifikaları etkiler, önceden basılmış olanlar eski adresi taşımaya devam eder. Yani yanlış adresle çıkan bir sertifika partisini geri almanın yolu, hepsini yeniden basmaktır.

Her Sertifika Her İşe Yaramaz: Kullanım Amacı (EKU)

Bir sertifika yalnız kime ait olduğunu değil, ne için kullanılabileceğini de taşır. Bu alana kullanım amacı (Extended Key Usage, kısaca EKU) denir ve içinde Server Authentication, Client Authentication, kod imzalama gibi değerler bulunur. Amaç dışı kullanım teknik olarak engellenir: doğru CA’nın bastığı, süresi geçerli bir sertifika bile, yanlış EKU taşıyorsa o iş için reddedilir.

B sınıfı ehliyetiniz gerçektir, Nüfus Müdürlüğü basmıştır, süresi de dolmamıştır. Ama onunla TIR süremezsiniz. Belge sahte değildir; o iş için düzenlenmemiştir.

Pratikte bu, teşhisi en zor sertifika arızalarından birini üretir. Servis “sertifika geçersiz” der, siz sertifikaya bakarsınız, her şey yerindedir: doğru isim, doğru zincir, geçerli tarih. Eksik olan tek şey kullanım amacıdır ve o, sertifikanın göze çarpan alanlarında durmaz. Web sunucusu ve 802.1X kimlik doğrulaması yapan bir RADIUS sunucusu Server Authentication ister; kullanıcıyı sertifikayla tanıyan sistemler Client Authentication ister.

Sertifika Arızalarını Teşhis Etmek

Sertifika arızalarının ortak özelliği, kendilerini sertifika arızası olarak göstermemeleridir. Belirti neredeyse her zaman ağ katmanını işaret eder: bağlantı kurulmuyor, port cevap vermiyor, uygulama zaman aşımına düşüyor. Teşhis, katmanları doğru sırayla ayırmakla başlar.

Açık Port, Çalışmayan Servis

Kendi lab ortamımızda bunun ders niteliğinde bir örneğini ölçtük. Domain controller’ımızda (dc01) LDAPS’in dinlediği 636 portunu kontrol ettiğimde port açık görünüyordu:

Test-NetConnection -ComputerName 192.168.1.10 -Port 636

TcpTestSucceeded : True

Buraya kadar her şey normal. Port açık, sunucu dinliyor, ağ yolunda engel yok. Ama LDAPS bağlantısı kurmayı denediğimde el sıkışma sunucu tarafından resetleniyordu. Dört ayrı TLS sürümüyle (1.0, 1.1, 1.2 ve 1.3) tek tek denedim ve dördünde de bağlantı aynı noktada koptu. Bir el sıkışmanın neden bir uyarı yerine sessiz bir reset’le koptuğunu ve porttan bakınca neden görünmediğini ayrı bir yazıda ölçtük.

Bu ayrıntı teşhisin kilit noktasıydı. Eğer sorun protokol uyumsuzluğu olsaydı, dört sürümden en az birinin farklı davranması gerekirdi: biri bağlanır, biri farklı hata verirdi. Dördünün de aynı yerde kopması, sorunun sürüm görüşmesinde değil daha öncesinde olduğunu söylüyordu. Sunucunun sunacak bir sertifikası yoktu.

Sebep basitti ve makinede değil mimaride duruyordu: o ortamda henüz bir sertifika otoritesi kurulmamıştı. Domain controller LDAPS için gereken sunucu sertifikasını alabileceği bir makam olmadığından, portu açıyor ama el sıkışmayı tamamlayamıyordu.

Teşhisin Doğrulanması: CA Kurulunca Ne Oldu?

Bu teşhisi sınamanın tek yolu vardı: bir sertifika otoritesi kurup aynı ölçümü tekrarlamak. Kurduk, ve LDAPS tarafında hiçbir ayar değiştirmedik. Domain controller’a dokunmadık, 636 ile ilgili tek bir yapılandırma yapmadık.

Sonuç, aynı komutla:

Tls12 : BAŞARILI  (AES-256)
Tls13 : BAŞARILI  (AES-256)
    Subject : CN=dc01.ad.sercebilisim.com
    Issuer  : CN=SerceBilisim-Lab-Root-CA

Aradaki tek fark, domain controller’ın artık sunabileceği bir sertifikasının olmasıydı. Sertifikayı da kendisi aldı: Active Directory ortamında domain controller’lar uygun bir şablon yayına girdiği anda otomatik kayıtla sertifikalarını kendileri talep eder.

Buradan iki şey çıkıyor. Birincisi, “port açık ama servis çalışmıyor” tablosunun sebebi gerçekten sertifikanın yokluğuydu; tahmin doğrulandı. İkincisi ve daha önemlisi: bir sertifika otoritesi kurmak, ondan haberi olmayan servisleri bile çalışır hale getirebilir. LDAPS yıllardır o portu dinliyordu, eksik olan tek parça bir imzaydı.

Çıkarılacak Üç Ders

Bu vaka, sertifika teşhisinde tekrar eden bir kalıbı gösteriyor:

1. Açık port, çalışan servis demek değildir. Port taraması yalnız TCP katmanını söyler; üstünde konuşulan protokolün sağlıklı olduğunu söylemez. Test-NetConnection başarılıyken servis tamamen ölü olabilir.
2. Aynı noktada tekrarlanan hata, görüşme değil eksiklik işaretidir. Farklı ayarlarla denediğinizde davranış hiç değişmiyorsa, sorun ayarlarda değil ortada olmayan bir bileşendedir.
3. Sertifika arızalarını uygulama loguna bakmadan çözemezsiniz. İstemci tarafındaki mesaj neredeyse her zaman yanıltıcıdır; gerçek sebep sunucunun kendi kayıtlarındadır.

Dizin servisinin şifreli ve şifresiz portları arasındaki farkı, hangi hatanın hangi katmandan geldiğini LDAP nedir rehberimizde paket düzeyinde ele aldık.

Sonuç: Kararı Sertifika Bazında Verin

Sertifika otoritesi, teknik bir bileşen olmadan önce bir güven kararıdır. Sorduğunuz soru “hangi ürünü kuralım” değil, “bu belgeyi kimin tanıması gerekiyor” olduğunda cevap kendiliğinden gelir: yalnız kendi makineleriniz tanıyacaksa iç CA, tanımadığınız insanlar tanıyacaksa public CA, ve tek bir makine tanıyacaksa self-signed da yeterlidir.

Kurumların bu konuda düştüğü asıl hata yanlış seçenek seçmek değil, seçimi hiç yapmamaktır. Sertifikalar tek tek, ihtiyaç doğdukça, her seferinde o günün en kısa yolu seçilerek birikir. Üç yıl sonra ortaya kimin bastığı belirsiz, ne zaman biteceği bilinmeyen, hiçbir yerde listelenmemiş bir sertifika yığını çıkar. O yığının maliyeti bir sabah, hiç beklenmedik bir servisin durmasıyla ödenir.

Bir denetimden geçiyorsanız bu yığın ayrıca sizi zorlar: denetçi “şifreleme kullanıyoruz” beyanını değil, hangi sertifikanın nerede olduğunu ve kim tarafından yenilendiğini gösteren kaydı sorar. ISO 27001 belgelendirme sürecini anlattığımız rehberde bu ayrımı ayrıntılı ele alıyoruz: istenen şey beyan değil kanıttır.

Kararın sahadaki karşılığını merak ediyorsanız: on üç lokasyonlu bir kurumda switch ve kablosuz ağ erişimini kişisel hesaplara bağlarken, 802.1X’in ihtiyaç duyduğu sertifikaları basmak için bir iç sertifika sunucusu kurmuştuk. Ayrıntısı ağ erişim kontrolü projemizde.

Bu makale kararın kendisini anlattı. Kararı verdikten sonraki adım, seçtiğiniz yolu fiilen kurmaktır. Windows tarafında bunun karşılığı Active Directory Certificate Services rolüdür: sihirbazdaki geri alınamayan kararları, iptal listesi adresinin neden ilk sertifikadan önce verilmesi gerektiğini ve kurulumun gerçekten çalıştığının nasıl doğrulanacağını AD CS kurulum rehberimizde adım adım ele aldık. Linux tarafındaki kendi CA yapınızı kurmayı ise ayrı bir rehberde göstereceğiz.

Sertifika altyapısının kimlik tarafıyla nasıl birleştiğini görmek isterseniz Active Directory rehberimiz iyi bir başlangıç noktası.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.