Yazının ilk bölümünde CA’lerimizi kurmuştuk. Bu bölümde de bir takım özelleştirmeler ve terimsel açıklamalar yaparak bir gerçek ortam uygulamasını örneklemeye çalışacağız. Öncelik ile bir takım kavramları açıklayalım;
CRL: Yürürlükten kaldırılan sertifikaların, seri numaralarının imzalı bir listesidir. Yürürlükten kaldırılan bir sertifika, derhal CRL’e eklenir. İstemcilerin, bir sertifikayı kullanmadan önce CRL’i kontrol etmesi gerekir; sertifika CRL’de görünüyorsa, istemciler bunu kullanamaz.
AIA: Authority Information Access. Sertifika Otoritesine erişimin adresini belirtir.
Gerekli kurulumlar sonrası root sunucu kapatılacağından Enterprise olan CA sunucusuna gerekli yetkiler taşınmalıdır.
Kurulum sonrasında, Root’un kendi sertifikasında, CRL ve AIA satırlarının olmaması gerekmektedir. Aşağıdaki gibi kontrol edilir.
Start>Administrative Tools>Certification Authority konsoluna ulaşılır.
Ekrandan Root CA üzerinde mouse ile sağ tuş tıklamasıyla gelen ekrandan Properties seçilir.
Gelen menülerden General – View Certificate – Details seçilir.
Daha sonra
Revoked Certificates için gerekli düzenleme yapılır.
Revoked Certificates – Properties – interval 20 years yapılır.
Root CA’den daha sonra gönderecek olduğumuz, subordinate sertifikasında, görüntülenecek olan CRL (Certificate Revocation List) ve AIA (Authority Information Access) için default path’ler(locations) değiştirilecek.
CRL için CRL – HTTP ve CRL – LDAP değerleri ile
AIA için AIA – HTTP değeri değiştirilecektir. Bu işlemlerin yapılacağı yer aşağıdadır:
Hem CRL hem de AIA için http ve Ldap satırları remove edilip aşağıdaki değerler Add butonu ile eklenir, ilgili satırlar etkinleştirilir.
Not: CRL ve AIA için tüm ayarlar ve etkinleştirmeler tamamlanmadan –arada- Apply ya da OK butonlarına basılmaz.
CRL – HTTP
CERT2.MOSTAR.LOCAL/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
CRL – LDAP
Ldap:///CN=MOSTARROOT,CN=CERT1,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=MOSTAR,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint
AIA – HTTP
CERT2.MOSTAR.LOCAL/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
OK denildikten sonra servisler otomatik restart edilmektedir.
Daha sonra Root CA’den dağıtılacak olan sertifikalar için(biz sadece subordinate sertifikası dağıtacağız) süre belirlenir.
Default süre 1 yıldır. Biz bu süreyi 15’e çıkaracağız. Bunun için komut satırı’ndan aşağıdaki iki komut çalıştırılır ve servisler stop start edilir:
certutil -setreg caValidityPeriodUnits 15
certutil -setreg caValidityPeriod “Years”
net stop certsvc
net start certsvc
Enterprise CA kuracağımız makineye gidilir ve makine domaine alınır.
Domain Enterprise kullanıcı hesabı ile açılıp önce IIS kurulur sonra da Server Manager – Add Roles ile ENTERPRISE CA’in kurulumuna başlanır.
Active Directory Certificates Services rolü seçilir.
Rol seçiminden sonra gelen ekranda alt bileşenler yukarıda belirtildiği bırakılır.
Kurulumun bu aşamasında Enterprise seçilerek devam edilir.
Kurduğumuz CA’in ortamdaki StandAlone CA’ye subordinate olacağını hatırlayalım. Subordinate seçilerek ilerlenir.
Root kurulumunda da yaptığımız gibi Key için uzunluk belirtilir.
Yeni CA için bir isim belirlenir.
Subordinate olması sebebiyle kurduğumuz CA muhakkak suretle bir Root CA tarafından yetkilendirilmelidir. Yetki istenmesi için kullanılacak bir istek dosyası bu ekranda oluşturulabilir.
NOT: YAPIMIZ DAHA YÜKSEK GÜVENLİK SAĞLANABİLMESİ İÇİN ÖNERİLEN YAPILANDIRMAYI KULLANMAKTADIR. BU SEBEPLE ORTAMDAN İŞİ BİTTİĞİNDE İZOLE EDİLECEK BİR ROOT STANDALONE CA KURULUMU YAPILDI. YAPIMIZDA HİZMET VERMEYE DEVAM EDECEK CA İSE BU KURULUMUNU YAPTIĞIMIZ SUBORDINATE CA OLACAKTIR. BÖYLECE ROOT CA BİR ANAHTAR KAYBI RİSKİ TAŞIMAYACAK SUBORDINATE CA SON KULLANICILAR İLE TEMAS EDECEKTİR. BU KATMANLI YAPI SAYESİNDE PKI YAPISININ GÜVENLİĞİ ARTIRILMIŞ OLACAKTIR. GEREKTİĞİNDE TEK KATMANLI YAPILARIN DA KURULABİLECEĞİ UNUTULMAMALIDIR.
Kurulum log dosyalarına lokasyon belirtilmesi ve gerekli IIS bileşenlerinin yüklenmesiyle devam edecektir.
Kurulum sonrasında, kurulumda subordinate sertifikası almak için oluşturulan reg dosyası, Root CA’ye kopyalanır.
Root CA’de, bu istek submit edilir ve oluşturulan subordinate sertifikası Root CA’de yapılacak sertifika export işleminde aşağıdaki satırlar seçilir.
Subordinate CA’de oluşturulan istek dosyası Root CA tarafında işlenerek bir Subordinate sertifikası oluşturulur.
İssue edilen sertifika root ca’in c: bölümüne export edilir:
Daha sonra bu sertifika enterprise ca’e kopyalanır ve orada install edilir:
Oluşturulan Subordinate sertifikası Subordinate CA’ye yüklenir.
Sertifika, Enterprise CA’e install edildikten sonra sorun oluşur.
Enterprise CA’de servis start edilmeye çalışılmadan, Root CA’e gidilir ve Revoked Certificates – All Tasks – Publish edilir.
Daha sonra Root CA’deki CRL and CRT uzantılı iki dosya, Ênterprise CA’de aynı yere taşınır.
(Enterprise CA’de C:WindowsSystem32certsrvCertEnroll adresine kopyalanır.)
Kopyalama sonrasında aşağıdaki komutlar ilgili adreste çalıştırılır:
certutil -dspublish MOSTARROOT.crl
certutil -dspublish -f cert1_MOSTARROOT.crt RootCA
Sonrasında Enterprise CA için servis start edilebilir.
Enterprise CA’in dağıtacağı sertifikalar için süre tanımlanır.
certutil -setreg caValidityPeriodUnits 15
certutil -setreg caValidityPeriod “Years”
net stop certsvc
net start certsvc
Enterprise ca’in kendi sertifika ömrü, root ca’den aldığı subordinate sertifikasının ömrüdür.
Kontrol ettiğimizde 15 yıl olarak görürüz.
Daha sonra DC makinesine gidilir. AD Sites and Services altında iki CA’i de görmeliyiz.
Son olarak 2 ca’in de AD’de client’lara trust ca olarak tanıtımı kaldı. Bunun için 2 ca’den alınan ca sertifikaları AD’de gpo’da tanımlanır. GPO’da tanımlanacak sertifikalarr ca’lerde mmc console – personel altında görülen sertifikaların private key’siz export edilen halleridir.
Bu şekilde export edilen sertifikalar DC makinesine kopyalanıp GPO – Trust Root Certification Authorities içerisine import edilir.
Böylelikle biri StandAlone Root CA diğeri Enterprise CA olan iki katmanlı bir PKI yapısı kurmuş olduk. Bir başka makalede görüşmek üzere.
