İki Katmanlı PKI Mimarisi (Two Tier PKI Hierarchy)

Merhaba,

Bu yazımda Active Directory Sertificate Services hizmetini ve bu hizmet ile iki katmanlı PKI mimarisi nasıl kuruluru anlatmak istiyorum. Hatta belki ilerleyen günlerde de bu yazı referans alınarak bir SubCA sunucusunun adı nasıl değiştirilir, nasıl göç ettirilir, nelere dikkat edilmelidir, CA üzerinde Role Seperation nedir, nasıl yapılır gibi konulara da değinebiliriz. Seri kıvamında bir yazı olabilecek gibi görünse de seri olabilmesi için önce şu anda okuduğunuz yazının bitmesi gerek 🙂 Haydi başlayalım.

Active Directory Sertifika Hizmetleri Nedir?

Microsoft’ un sayfasında da belirttiği gibi;  Active Directory Sertifika Hizmetleri (AD CS), güvenli iletişim ve kimlik doğrulama protokollerinde kullanılan ortak anahtar altyapısı (PKI) sertifikalarını verme ve yönetmeye yönelik bir Windows Server rolüdür. Kurumsal ortamlarda güvenilir dijital kimlik yönetimi, uzun vadeli sürdürülebilirlik ve esneklik için Two-Tier PKI mimarisi en doğru yaklaşımlardan biridir. Bu mimaride Root CA tamamen izole ve offline çalışır, Subordinate CA (Sub CA / Issuing CA) ise domain içinde aktif olarak sertifikaları üretir, yönetir ve yayar. Böylece hem güvenlik hem de operasyonel yönetilebilirlik en üst seviyeye çıkar.

Kurulum adımlarına başlamadan önce yapımın aşağıdaki gibi olduğunu belirtmek isterim.

Virtual Machine	Role(s)	OS Type	IP Address	Subnet Mask	Preferred DNS Server
DC01.m3g.loc	DC & DNS – LDAP	Windows Server 2019	172.15.10.11	255.255.255.0	172.15.10.11
OffCA	Standalone Offline Root CA	Windows Server 2019	–	–	–
SubCA01.m3g.loc	Enterprise Issuing CA	Windows Server 2019	172.15.10.21	255.255.255.0	172.15.10.11
APP01.m3g.loc	Web Server	Windows Server 2019	172.15.10.51	255.255.255.0	172.15.10.11
CL01.m3g.loc	Windows Client Computer	Windows 10	172.15.10.101	255.255.255.0	1172.15.10.11

 

Kurulum adımlarını özetlemek gerekirse;

1. Offline Root CA sunucu kurulumu.
   1. Offline Root CA konfigürasyonu.
2. Subordinate CA sunucu kurulumu.
   1. Subordinate CA sunucu konfigürasyonu (.req dosyasının oluşturulması)
   2. İsteğin Root CA tarafından imzalanması
3. Subordinate CA sunucusunun yetkilendirilmesi.
   1. İmzalanan Sub CA sertifikanın import edilmesi.
   2. Root CA sertifikasının dağıtılması.

Bu kurulum adımlarını uygularken revocation check gibi alınabilecek hatalar üzerinde de duruyor olacağız. Kurulum adımlarına geçebiliriz.

 

1. Root CA Kurulumu

Öncelikle offline durumda olacak olan ve RootCA görevini üstlenecek sunucumda kurulumlara başlıyorum.

Not: Gereksiz ekran görüntülerini paylaşarak kalabalık yapmamak adına sadece değişiklik yapılan ekran görüntülerini paylaşacağım.

Kurulumumuz başarıyla tamamlandı. Artık konfigürasyon seçeneğine geçebiliriz.

Domainde olmadığımız bir ortamda Enterprise CA kuramayacağımızdan dolayı Standalone CA seçeneğini seçerek devam ediyoruz.

Biz ROOT CA kurmak istediğimizden dolayı bu adımda Root CA seçeneğini seçerek devam ediyoruz.

Bu alanda Create a new private key seçeneği ile devam ediyoruz. Ortamımızdaki ilk CA sunucusunu kuracağımızdan dolayı bu seçenek zaten akla gelen ilk seçenek fakat diğer seçeneklerin ne olduğuna ilerleyen bölümlerdeki SubCA sunucusunun isim değişikliği ve SubCA sunucusunun göç ettirilmesi adımlarında değineceğimizden dolayı şu anda üzerinde çok durmuyorum.

Gizli (Özel) anahtar uzunluğunu 4096 olarak seçmeyi tercih ediyorum. Bu adımda alt taraftaki checkbox kutucuğunun ne anlama geldiğinden biraz bahsetmek istiyorum. Bu onay kutusu, CA hizmetinin özel anahtarını kullanmak için ek bir manuel güvenlik adımı gerektirip gerektirmediğini kontrol eder.

Peki CA gizli anahtarı ne demek?

CA’nın yayınladığı tüm sertifikaları imzalamak için kullandığı en kritik ve gizli anahtardır. Bu anahtarın güvenliği, tüm PKI (Ortak Anahtar Altyapısı) sisteminizin temelidir.

E peki cümlede de söylediği gibi (Allow administrator interaction) yönetici etkileşimini seçersek ne olur?

Eğer bu seçenek işaretlenirse, CA özel anahtarını kullanarak bir işlemi gerçekleştirmeye çalıştığında (örneğin, yeni bir sertifika yayınlarken veya CRL (Sertifika İptal Listesi) yayımlarken), sistem sizden manuel onay veya kimlik doğrulama (örneğin, şifre, akıllı kart PIN’i) isteyecektir.

Tıklarsam ne olur? Tıklamazsam ne olur?

Eğer bu kutuyu işaretlerseniz:

1. Gelişmiş Güvenlik: CA özel anahtarı, yetkisiz veya otomatik kullanıma karşı daha sıkı bir şekilde korunur. Özel anahtar her kullanıldığında, CA hizmetinin çalıştığı sunucuda yöneticinin müdahale etmesi ve genellikle bir şifre girmesi veya bir işlemi onaylaması gerekir.

2. Manuel İşlem Gerekir: Bu, CA’nın otomatik işlemleri (örneğin, arka planda otomatik olarak CRL yayımlaması veya web kayıt taleplerini işlemesi) gerçekleştirmesini engelleyebilir veya bu işlemlerin düzgün çalışması için sürekli manuel müdahale gerektirebilir.

3. Kullanım Senaryosu: Genellikle, çevrimdışı kök CA’lar (yani, çok nadiren ve sadece bir sonraki seviye CA’ları imzalamak için kullanılan, genellikle kapalı tutulan kök CA’lar) için tercih edilir. Çevrimiçi (online) çalışan Subordinate (Alt) CA’lar için tavsiye edilmez, çünkü otomatik işlemleri durdurur.

Eğer bu kutuyu işaretlemezseniz (önerilen varsayılan ayar):

1. Otomatik Erişim: CA hizmeti, özel anahtara yönetici müdahalesi olmadan erişebilir ve kullanabilir.

2. Otomasyon: Bu, CA’nın sertifika verme, CRL yayımlama gibi tüm görevleri otomatik ve sorunsuz bir şekilde gerçekleştirmesini sağlar. Bu, çevrimiçi (online) Alt CA’lar ve pratik olarak çoğu kurumsal CA için zorunludur.

3. Risk: Eğer CA sunucusunun güvenliği ihlal edilirse, saldırganlar özel anahtarı otomatik olarak kullanabilirler. Bu nedenle, CA sunucusunun fiziksel ve ağ güvenliği çok önemlidir.

Sonuç?

Eğer kurduğunuz CA bir çevrimiçi (online) Sertifika Yetkilisi ise (yani, sürekli çalışıp kullanıcılara ve cihazlara sertifika verecekse), bu kutuyu işaretlememeniz gerekir. Bu, standart bir uygulamadır ve PKI’ınızın düzgün çalışması için otomasyonu sağlar.

Eğer bu bir Kök CA olacaksa ve onu kurulumdan hemen sonra kapatıp sadece Alt (Sub) CA imzalamak için saklayacaksanız, işaretlemek ek bir güvenlik katmanı sağlar. Ben lab ortamımda olduğumdan dolayı işaretleyip işaretlememem çok bir fark teşkil etmeyecektir.

Default olarak gelen OFFCA-CA olan CA ismini kolaylık olması ve okunabilmesi açısından ROOTCA-CA şeklinde değiştiriyorum.

Lab ortamında olduğumdan dolayı 15 yıllık sertifika seçerek devam ediyorum ve diğer değerleri default bırakarak konfigürasyonu tamamlıyorum.

1. 1. Offline Root CA Konfigürasyonu

Offline Root CA sunucumuzu başarıyla kurduk. Şimdi ayarlarımızı yapalım.

Certification Authority konsolumuzda sunucumuzu seçerek “Properties” seçeneğini seçiyoruz.

Gelen pencerede Extensions sekmesine giderek. CDP ve AIA ayarlarını yapmamız gerekmetkedir. Bu ayarların ne olduğu hakkında ufak bir bilgi verelim.

CDP (CRL Distribution Point) – CRL Dağıtım Noktası

Nedir? : CDP, Sertifika İptal Listelerinin (Certificate Revocation List – CRL) nerede bulunduğunu belirten bir konumdur.

Ne için lullanılır? : Bir istemci bir sertifikayı kullanmadan önce, sertifikanın iptal edilip edilmediğini kontrol etmek için bu konuma gider ve güncel CRL dosyasını indirir. Eğer sertifikanın Seri Numarası bu listede varsa, sertifika geçersiz sayılır.

AIA (Authority Information Access) – Yetkili Bilgi Erişimi

Nedir? : AIA, sertifikayı yayınlayan CA Sertifikasının nerede bulunduğunu belirten bir konumdur.

Ne İçin Kullanılır? : İstemciler, bir sertifikanın gerçekten güvenilir bir CA tarafından yayınlanıp yayınlanmadığını kontrol ederken (sertifika zinciri oluşturulurken), sertifika zincirindeki bir üst seviyedeki CA’nın sertifikasını bu konumdan bulup indirir.

Artık ne olduğunu bildiğimize göre bilgileri kendi yapımıza uyarlayabiliriz. Bizim ortamımızda AD ortamında görev yapacak sertifika otoritesi SubCA olacağından, ve CRL listesini SubCA sunucusu yayınlayacağından, hem de domain ortamında verilen sertifikanın (örneğin user certificate) bir üst CA sertifikasını yine SubCA sunucusundan indirebileceği için, sunucumuzun adını ve adresini yazabiliriz.

http://SubCA01.m3g.loc/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

• Fakat sonraki adımları da düşünerek, bu adımda bir dns name kullanabiliriz. http://pki.m3g.loc/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl  şeklinde bir adres kullanırsak, daha sonra yapmayı planladığım SubCA isim değişikliği ya da SubCA göç işlemlerinden etkilenmeyeceğim.

Bu ayarlardan sonra SubCA kurulumuna geçebiliriz.

 

2. Sub CA Kurulumu

• Varsayılan olarak Enterprise Root ve/veya Enterprise Subordinate CA kurulumlarında Enterprise Admin ve ya Domain Admin olmanız gerektiğinden ben CA sunucuma domain admin kullanıcımla bağlanıyorum. Ki zaten Tier yapısında da CA sunucuları Tier 0 katmanında olan sunuculardır.

SubCA01 sunucuma logon olarak kurulum adımlarına başlıyorum.

Web Enrollment zorunlu değil fakat daha sonra lazım oalcağından dolayı ben o seçeneği de seçerek devam ediyorum. O role service olmadan da kurabilirsiniz.

Kurulum tamamlandı. Artık .req dosyasını oluşturabiliriz. Bunun için “Configure Active Directory Certificate Services on the destination server” yazan yere tıklıyoruz.

2.1. CSR isteğinin oluşturulması

Sub CA sunucumuzu yapılandırma adımlarını tmamlıyor olmamız gerekiyor ki hem Root CA tarafından tanınsın, hem de chain yapımızda herhangi bir sorun oluşmasın.

Certification Authority Role Service yapılandırmasını seçiyorum. Web Enrollment ‘ı daha sonra yapılandıracağım. Ki zaten biliyorsunuz ki zorunlu bir adım değildi. Fakat değinmek gerekirse, bu hizmet, CA sunucusuna kurulan bir Internet Information Services (IIS) tabanlı web sitesidir. Kullanıcılar bu web sitesine bir tarayıcı aracılığıyla erişir ve CA sunucudan sertifika talebinde bulunabilir.

Sunucumuzun, bir Enterprise CA ve sonraki adımda ise Subordinate CA olduğunu belirten seçenekleri işaretliyoruz.

Domain ortamına dahil olacak ilk CA sunucusu olduğudan (herhangi bir CA göçü ya da bilgisayar isim değişikliği olmadığından) yeni bir gizli anahtar oluşturarak devam ediyoruz.

Yukarıda daha önce anlattıklarımızdan dolayı “Allow administrator interaction when the private key is accessed by the CA.” kutucuğunu işaretlemiyoruz.

Ben common name seçeneğini değiştirmeyi tercih ettim.

Domainimizde herhangi bir CA sunucu olmadığından otomatik olarak request dosyasını kaydedeceği yeri söylemektedir. Dilerseniz değiştirebilirsiniz. Ben aynı lokasyonda bırakarak geçeceğim. Diğer adımları da varsayılan olarak bırakarak kurulumu tamamlıyorum.

Görüldüğü üzere kurulumun tamamlandığını ama başarılı bir kurulum olabilmesi için gerekli aksiyonun alınması gerektiğini söylüyor. Yapman gereken eylemin, .req dosyası ile elde edeceğin sertifikanın install edilmesi gerektiğini söylemekte. Artık .req dosyasını Offline Root CA sunucusuna kopyalayıp, Sub CA sunusunun sertifikasını onaylayabiliriz.

• Role Service kurulumu tamamlandığında diğer role service (Web Enrollment) yapılandırmak isteyip istemediğinizi soracaktır. Yes seçeneği ile Next, Next, Finish şeklinde yapılandırabilirsiniz.

2.1. İsteğin Root CA tarafından imzalanması

Az önce SubCA sunucumuzun C:\ dizini altında oluşan .req istek dosyasını, Offline Root CA makinesine kopyaladıktan sonra istek dosyamızı onaylayarak SubCA sertifikasını üretmemiz gerekmektedir.

Certification Authority konsolunda “Submit new request” öğesi ile manuel oluşturulmuş sertifika isteklerini onaylayabilirsiniz. SubCA sunucumuzdan kopyaladığım dosyayı seçiyorum ve devam ediyorum. Bu işlem sonrası “Pending Request” klasöründe bekleyen sertifika olarak gözükecektir.

Sertifikayı issue etmek için sağa tıklıyor ve “issue” seçeneğini seçiyoruz. Sertifika onayından sonra “Issued Certificates” klasöründe seritifkayı bulabilirsiniz.

SubCA Sertifikasını export işlemi için sertifikayı açtıktan sonra ekrandaki gibi Export ediyoruz.

Ben C:\Windows\System32\CertSrv\CertEnroll dizinine kaydettim. Buradaki tüm dosyaları SubCA sunucusu üzerindeki aynı yere kopyalıyorum. Farkettiyseniz RootCA sertifilkam da bu dizinde. Eğer dizinde göremez ya da bulamazsanız Root CA sunucusu üzerinde “Properties” seçeneği ile açılan pencerede “View Certificate” butonuna tıklayabilirisniz.  Sertfiikanın details sekmesinden sertifikayı export edebilirsiniz.

 

3. Subordinate Sunucusunun Yetkilendirilmesi

Dosyaları SubCA sunucusuna kopyaladıktan sonra sıra geldi SubCA sunucumuzun yetkili kılmaya.

Certification Authority konsolunda servisimizin Stop olduğunu göreceğiz. Çünkü bu sunucuda en son .req dosyası oluşturmuştuk ve henüz onaylanmış bir CA sertifikası yüklemedik. Bu sebeple servis stop durumdadır.

Sunucumuza CA seritifkasını yüklemek istediğimizi belirtiyor ve CertEnroll diznindeki SubCA-CA.p7p dosyasını gösteriyoruz.

Bu işlemden sonra karşımıza bir onay penceresi gelecek. Burada Sertifika zincirini doğrulayamadığını, çünkü revocation yapması gereken CDP adreslerine erişemedğini belirtiyor. “OK” tuşu ile devam ediyoruz. Daha sonra servisimizi başlatöaya çalışıyoruz.

Bu sefer bir uyarı değil hata alıyoruz ve servisi start etmiyor. Sebebi, Root CA sunucusuna ait sertifikanın doğrulanamadığı ile ilgilidir. Bu hata, kaynağı CertificationAuthority olan ve Event ID :100 olan bir event düşürecektir.

Çözüm?

SubCA sunucusunun komut satırında;

certutil -v -getreg CA\CRLFlags

komutu çalıştırılır.

Pasif olan özellikler parantez içinde gösteriliyor. CRL Revocation Check işlemindeki doğrulamayı ignore etmek için;

certutil -setreg CA\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

komutunu çalıştırıyorum.

Servisi tekrar başlattığımızda herhangi bir sorun olmadığı gözükmektedir.

Eğer yukarıdaki certutil -v -getreg CA\CRLFlags komutunu tekrar çalıştırırsanız CRLF_REVCHECK_IGNORE_OFFLINE özelliğinin parantez içinde olmadığını ve aktif olduğunu görebilirisniz. Servisi başlattıktan sonra tekrar eski -haline getirmek için aşağıdaki komutu girmeniz önerilir.

certutil -setreg CA\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

Hatırlarsanız CDP ve AIA adreslerine pki.m3g.loc adresini girmiştik. Bu adreslere DNS üzerinde adres tanımlaması yapmamız gerektiğini de unutmayalım.

Böylelikle SubCA sunucu ismi değişikliği ve göç işlemlerinde herhangi bir sıkıntı ile karşılaşmazsınız.

Son işlemler ile birlikte artık Two Tier PKI Hierarchy (İki katmanlı PKI Mimari) yapısına sahip çalışan bir ADCS ortamınız bulunmaktadır.

• Yazının devamının geleceğini (yani yakın zamanda yazacağımı) düşündüğümden seritifka üretmeyi, doğrulandığını göstermeyi ve karşılaşılan hataları düzeltmeyi sonraki yazılarak bırakıyorum..

Faydalı olamsı dileğiyle.