AD CS Enterprise Root CA Kurulumu ve Sertifika Doğrulama

PKI altyapısı, kurumsal bir Network içinde kimlik doğrulama, veri bütünlüğü, şifreleme ve güven ilişkisini yöneten kriptografik yapıdır. Sertifikaların üretilmesi, imzalanması, yenilenmesi, yayımlanması ve gerektiğinde iptal edilmesi Certification Authority tarafından sağlanır. Microsoft tarafında bu görev, Windows Server üzerinde Active Directory Certificate Services (AD CS) rolüyle yerine getirilir. AD CS ile oluşturulan sertifikalar SSL/TLS, S/MIME, IPsec, EFS, Smart Card Logon, 802.1X tabanlı Network erişim kontrolü, VPN kimlik doğrulaması ve kod imzalama gibi senaryolarda kullanılabilir.

Bir sertifikanın güvenilir kabul edilmesi, sertifikayı imzalayan CA'ya duyulan güvenle başlar. Bu güven ilişkisi Root CA'dan başlayıp Subordinate CA üzerinden kullanıcı, cihaz ya da servis sertifikasına uzanan bir Certificate Chain ile kurulur. İstemci tarafında sertifikanın geçerlilik süresi, Subject ve SAN bilgileri, imza algoritması, Key Usage, Enhanced Key Usage, CRL ya da OCSP iptal durumu ve zincirin güvenilir bir Root CA'ya bağlanıp bağlanmadığı kontrol edilir.

CA kurulumu, sıradan bir Server Manager rol kurulumu gibi düşünülmemelidir. CA'nın Enterprise ya da Standalone çalışması, Root ya da Subordinate konumda yer alması, Private Key'in korunma şekli, Cryptographic Provider, Key Length, Hash Algorithm, CA sertifikasının geçerlilik süresi, CRL Distribution Point (CDP) ve Authority Information Access (AIA) konumları PKI yapısının sağlıklı çalışmasını doğrudan etkiler. Hatalı tasarlanan bir CA yapısında sertifikalar üretilse bile istemciler sertifika zincirini doğrulayamayabilir veya CRL erişimi başarısız olabilir.

Enterprise CA senaryolarında Certificate Template'ler, Enrollment izinleri, Autoenrollment ayarları, Public Key Services Container'ı, AIA ve CDP yayım noktaları, Group Policy ayarları ve CA'nın Domain'e Join edilmiş olması birlikte değerlendirilir. Sertifika dağıtımının sorunsuz çalışması için istemcilerin CA sertifikasına güvenmesi, CRL dosyalarına erişebilmesi ve Template izinlerinin doğru hesaplara verilmesi gerekir.

Bu makalede Enterprise Root CA kurulumu ve yapılandırması ele alınmaktadır. Uygulamalı kurulum ve ekran görüntüleri Windows Server 2022 üzerinde hazırlanmıştır. Bu yapı laboratuvar ve test ortamlarında AD CS davranışını, Certificate Template mantığını ve PKI bileşenlerinin Active Directory ile bütünleşmesini incelemek için uygundur. Üretim ortamlarında CA sayısı ve hiyerarşi, kurumun güvenlik ve erişilebilirlik gereksinimlerine göre planlanır. Offline Root CA ile Online Enterprise Subordinate CA ayrımı bu planlamada sık tercih edilen bir modeldir.

Makale; ön kontrollerden rol kurulumuna, Configuration Wizard'dan kurulum sonrası sıkılaştırma adımlarına ve CA sertifikasının certutil ile PowerShell üzerinden doğrulanmasına kadar olan süreci kapsar. AIA ve CDP yayım noktalarının HTTP üzerinden yapılandırılması bu makalede uygulanmadığı için kurulum laboratuvar ve test kapsamıyla sınırlıdır. Bu CA ile üretim sertifikası verilmeden önce AIA ve CDP tasarımının tamamlanması gerekir. Certificate Template yapılandırması, Autoenrollment'ın Group Policy ile dağıtımı ve Two-Tier PKI hiyerarşisinin kurulması da bu makalenin kapsamı dışındadır.

1- Certification Authority Türleri

Windows Server üzerinde AD CS rolü dört farklı CA tipini destekler. Bu tipler iki ayrı sınıflandırma ekseninde belirlenir.

Birinci eksen, CA'nın Active Directory ile entegre çalışıp çalışmadığını belirler. Bu eksende Enterprise CA ve Standalone CA seçenekleri yer alır. İkinci eksen ise CA'nın PKI hiyerarşisindeki konumunu belirler ve Root CA ile Subordinate CA seçeneklerinden oluşur.

Bu iki eksen birleştiğinde Enterprise Root CA, Enterprise Subordinate CA, Standalone Root CA ve Standalone Subordinate CA olmak üzere dört CA tipi ortaya çıkar.

2- Kullanılan Ortam ve Parametreler

Bu makaledeki laboratuvar kurulumu, abc.local Active Directory Domain'i üzerinde TRISTSRVCER01 isimli Windows Server 2022 Standard sunucusunda gerçekleştirilmiştir. CA için seçilen Common Name değeri ABC-Corporate-Root-CA olarak belirlenmiştir. Bu isimde sunucu Hostname'i bilinçli olarak yer almaz. Hostname; donanım yenilemesi, taşıma ve yeniden adlandırma gibi operasyonlarda değişebilir. CA ismi ise CA sertifikası oluşturulduğu andan itibaren kalıcıdır. Hostname'e bağlı bir CA ismi, sunucu değiştiğinde kurumsal anlamını yitirir. Kurumsal kimliği temsil eden bir Common Name ise sertifikaların ömrü boyunca tutarlı kalır.

Common Name içinde kelime ayrımı için boşluk yerine tire karakteri kullanılmıştır. Boşluk içeren CA isimleri certutil -config ve PowerShell parametrelerinde tırnak içinde yazılmak zorundadır. AIA ve CDP URL'lerinde ise boşluklar %20 olarak kodlanır ve URL'lerin okunması zorlaşır. Tire ile birleşik yazılan kelimeler bu sorunu ortadan kaldırır.

3- Ön Kontrol Listesi

Kurulum başlamadan önce aşağıdaki maddeler doğrulanır. Komutların tamamı TRISTSRVCER01 üzerinde, yönetici olarak açılmış bir PowerShell oturumunda çalıştırılır.

Domain Üyeliği ve Sunucu Rolü

Enterprise CA, Certificate Template'leri, AD izinlerini ve Public Key Services Container'ını kullanabilmek için Domain üyeliğine ihtiyaç duyar. CA rolünün Domain Controller üzerinde değil, ayrı bir üye sunucuda konumlandırılması da bu kontrolle doğrulanır.

Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain, DomainRole

Çıktıda PartOfDomain değerinin True, Domain değerinin abc.local ve DomainRole değerinin 3 olması beklenir. 3 değeri sunucunun Domain üyesi bir Member Server olduğunu gösterir. Değer 2 ise sunucu Domain'e Join edilmemiştir ve kuruluma geçmeden önce Join işlemi tamamlanır. Değer 4 veya 5 ise sunucu bir Domain Controller'dır ve CA için ayrı bir üye sunucu kullanılması gerekir.

Statik IP Adresi

İstemciler CA'ya, AIA ve CDP yayım noktalarına DNS adı üzerinden ulaşır. Sunucunun IP adresinin sabit olması, DNS kaydının tutarlı kalmasını ve CA erişiminin kesintisiz sürmesini sağlar.

Get-NetIPInterface -AddressFamily IPv4 -ConnectionState Connected | Select-Object InterfaceAlias, Dhcp
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress

Kullanılan ağ arabiriminde Dhcp değerinin Disabled, IPAddress değerinin 10.10.10.210 olması beklenir. Dhcp değeri Enabled görünüyorsa arabirime statik IP adresi tanımlanır ve DNS sunucusu olarak Domain Controller adresleri girilir.

DNS Çözümlemesi

Sertifika doğrulama, LDAP yayımı, Group Policy uygulanması ve CA erişimi DNS'e bağımlıdır. Sunucunun kendi FQDN kaydının ve Domain Controller'ları bulmak için kullanılan SRV kayıtlarının çözülebilmesi gerekir.

Resolve-DnsName -Name TRISTSRVCER01.abc.local
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.abc.local -Type SRV

İlk komutun 10.10.10.210 adresini, ikinci komutun ise Domain Controller'ların SRV kayıtlarını döndürmesi beklenir. FQDN çözülmüyorsa sunucunun DNS kaydı ipconfig /registerdns ile yeniden kaydettirilir. SRV kayıtları gelmiyorsa ağ arabirimindeki DNS sunucusu ayarı kontrol edilir.

Zaman Senkronizasyonu

Sertifikalardaki NotBefore ve NotAfter alanları zamana bağlı çalışır. CA ile istemciler arasındaki saat farkı, yeni verilen bir sertifikanın henüz geçerli değilmiş gibi görünmesine neden olabilir.

w32tm /query /source

Çıktıda bir Domain Controller adının görünmesi beklenir. Local CMOS Clock veya Free-running System Clock görünüyorsa sunucu zamanını Domain hiyerarşisinden almıyordur. Bu durumda w32tm /config /syncfromflags:domhier /update komutu çalıştırılır, ardından Restart-Service w32time ve w32tm /resync ile senkronizasyon yenilenir.

Yetki Kontrolü

Enterprise CA kurulumu Forest düzeyinde Public Key Services Container'ına yazar, NTAuthCertificates nesnesini günceller ve CA bilgisini Active Directory'de yayımlar. Bu nedenle kurulumu yapan hesabın Enterprise Admins grubuna üye olması ve CA sunucusunda yerel Administrators yetkisine sahip olması gerekir.

whoami /groups | findstr /i /c:"Enterprise Admins" /c:"BUILTIN\Administrators"

Çıktıda ABC\Enterprise Admins ve BUILTIN\Administrators satırlarının Enabled group olarak görünmesi beklenir. BUILTIN\Administrators satırında Group used for deny only ifadesi görünüyorsa PowerShell oturumu yönetici olarak açılmamıştır. Enterprise Admins satırı hiç görünmüyorsa hesap gruba eklenir. Grup üyeliğinin oturuma yansıması için oturum kapatılıp yeniden açılır.

Forest'ta Mevcut Enterprise CA Kontrolü

Aynı Forest'ta planlanmamış başka bir Enterprise CA bulunması, Certificate Template'lerin ve Autoenrollment davranışının beklenmedik bir CA üzerinden işlemesine yol açabilir. Kurulumdan önce Forest'ta kayıtlı Enterprise CA'lar listelenir.

certutil -TCAInfo

Komut, Active Directory'de kayıtlı Enterprise CA'ları listeler. Yeni bir PKI kurulurken listede CA görünmemesi ya da yalnızca bilinen CA'ların görünmesi beklenir. Bilinmeyen bir CA listeleniyorsa, kuruluma geçmeden önce bu CA'nın PKI tasarımındaki yeri netleştirilir.

Çalışma Dizininin Hazırlanması

Export ve dump işlemlerinde kullanılan C:\Temp dizini mevcut değilse Export-Certificate komutu hata verir. Dizin önceden oluşturulur.

New-Item -Path C:\Temp -ItemType Directory -Force

4- Karar Tablosu

Rol kurulumu ve Configuration Wizard birden fazla karar noktası içerir. Bu kararların planlama aşamasında verilmesi, Wizard ekranlarında karar verme ihtiyacını ortadan kaldırır. Aşağıdaki tablo, bu kurulumda verilen kararları adım numaralarıyla birlikte özetler.

5- AD CS Rolünün Kurulumu

Adım 1 - Add Roles and Features Wizard'ının Başlatılması

Sunucuya Yetki Kontrolü bölümünde doğrulanan hesapla giriş yapılır. Server Manager'da sağ üst köşedeki Manage menüsünden Add Roles and Features seçeneği tıklanır.

Before You Begin sayfası atlanır. Installation Type sayfasında varsayılan olarak seçili gelen Role-based or feature-based installation seçeneği işaretli bırakılır. Server Selection sayfasında rolün kurulacağı TRISTSRVCER01.abc.local sunucusu seçili olarak gelir.

Adım 2 - Server Roles ve Features

Server Roles sayfasında Active Directory Certificate Services seçeneği işaretlenir. İşaretleme yapıldığında, rolün yönetimi için gereken Certification Authority Management Tools bileşeninin de eklenmesi gerektiğini bildiren bir pencere açılır. Add Features butonuna tıklanarak yönetim araçları kurulum kapsamına dahil edilir.

Features sayfasında ek bir Feature seçimi gerekmez ve varsayılan değerlerle devam edilir.

Kontrol Noktası
Server Roles listesinde Active Directory Certificate Services seçeneği işaretli görünür ve yönetim araçları kurulum kapsamına eklenmiştir.

Adım 3 - AD CS Bilgilendirme Ekranı

AD CS bilgilendirme sayfasında, Certification Authority kurulduktan sonra sunucunun adının ve Domain üyeliğinin değiştirilemeyeceği belirtilir. Bunun nedeni CA yapılandırmasının sunucu adına bağlanmasıdır. CA'nın kayıt defteri yapılandırması, Active Directory'deki Enrollment Services nesnesi ve %1 (ServerDNSName) değişkeniyle oluşturulan AIA ve CDP URL'leri sunucunun mevcut FQDN'ini kullanır. CA Common Name ise bundan bağımsızdır ve bu kurulumda Hostname içermez.

Adım 4 - Role Services

Role Services sayfasında AD CS altındaki rol servisleri listelenir. Bu kurulumda Certification Authority ve Certification Authority Web Enrollment servisleri seçilir. Certification Authority, sertifika veren ana bileşendir. Certification Authority Web Enrollment ise tarayıcı tabanlı bir arayüz üzerinden sertifika talebi yapılmasını sağlar.

Adım 5 - IIS Bileşenleri ve Confirmation

Web Enrollment seçildiği için Web Server Role (IIS) bilgilendirme sayfası ve ardından IIS Role Services sayfası gelir. Web Enrollment için gereken IIS bileşenleri varsayılan olarak seçili gelir ve değişiklik yapılmadan ilerlenir.

Confirmation sayfasında kurulacak rol ve servislerin özeti yer alır. Active Directory Certificate Services altında Certification Authority ve Certification Authority Web Enrollment, Remote Server Administration Tools altında Certification Authority Management Tools, Web Server (IIS) altında ise gerekli IIS bileşenleri listelenir. Install butonuna tıklanarak kurulum başlatılır.

Adım 6 - Kurulum Sonucu ve Configuration Öncesi Durum

Kurulum, Installation progress sayfasından izlenir ve bu süre boyunca kullanıcı etkileşimi gerekmez. Kurulum tamamlandığında üst kısımda Configuration required. Installation succeeded on TRISTSRVCER01.abc.local ifadesi görüntülenir. Bu ifade rolün kurulduğunu, ancak CA yapılandırmasının henüz yapılmadığını gösterir. Aynı ekranda Configure Active Directory Certificate Services on the destination server bağlantısı da yer alır.

Bu aşamada CA servisi henüz oluşturulmamıştır. Bu laboratuvarda certsrv.msc konsolu açılmak istendiğinde Cannot manage Active Directory Certificate Services. The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) hatası alınmıştır. Hata bir bozulma veya eksik kurulum belirtisi değildir. Yönetim konsolu, bağlanabileceği yapılandırılmış bir CA bulamadığı için bu uyarıyı verir.

Kontrol Noktası
Server Manager'da Configuration required mesajı görünür. Bu aşamada certsrv.msc konsolunun CA'ya bağlanamaması, yapılandırma henüz yapılmadığı için beklenen durumdur.

6- AD CS Configuration Wizard

Adım 7 - Wizard'ın Başlatılması ve Credentials

Server Manager üst tarafındaki sarı uyarı bayrağına tıklanır. Açılan Post-deployment Configuration bildirimindeki Configure Active Directory Certificate Services on the destination server bağlantısı seçilerek Wizard başlatılır.



Wizard'ın ilk sayfası olan Credentials ekranında, rol servislerini yapılandıracak hesap ve her rol servisi için gereken yetki seviyesi gösterilir. Enterprise Certification Authority yapılandırması için hesabın Enterprise Admins grubuna üye olması gerekir. Bu kurulumda ABC\Administrator hesabı kullanılmıştır.

Adım 8 - Role Services

Role Services sayfasında bu yapılandırmada ayarlanacak servisler işaretlenir. Rol kurulumunda Certification Authority ve Certification Authority Web Enrollment seçildiği için ikisi de listelenir ve işaretlenir.

Adım 9 - Setup Type

Setup Type sayfasında CA'nın Active Directory ile entegre çalışan bir Enterprise CA olarak mı, yoksa Standalone CA olarak mı kurulacağı belirlenir. Sunucu Domain'e Join edilmiş olduğu ve sertifika dağıtımında AD entegrasyonundan faydalanılacağı için Enterprise CA seçeneği işaretlenir.

Adım 10 - CA Type

CA Type sayfasında CA'nın hiyerarşideki konumu belirlenir. Kurulacak CA hiyerarşinin en üstünde yer alan Self-Signed bir CA olacağı için Root CA seçeneği işaretlenir. Hiyerarşide üst seviyede başka bir CA bulunsaydı Subordinate CA seçilir ve CA sertifikası üst CA'dan talep edilirdi.

Adım 11 - Private Key

Private Key sayfasında CA'nın kimliğini oluşturan Private Key'in nasıl elde edileceği belirlenir. Yeni bir CA kurulduğu için Create a new private key seçeneği işaretlenir. Use existing private key seçenekleri ise mevcut bir CA'nın yeniden kurulması veya başka bir sunucuya taşınması gibi senaryolarda, daha önce yedeklenmiş bir Private Key ile kullanılır.

Adım 12 - Cryptography for CA

Cryptography for CA sayfasında Private Key'in hangi Cryptographic Provider ile saklanacağı, anahtar uzunluğu ve imzalama için kullanılacak Hash Algorithm seçilir. Yazılım tabanlı varsayılan Provider olan RSA#Microsoft Software Key Storage Provider seçili bırakılır. Key Length 2048, Hash Algorithm SHA256 olarak belirlenir.

Bu ekranda listelenen Hash Algorithm ve Key Length seçenekleri benzer görünse de her biri farklı güvenlik, uyumluluk ve performans etkisine sahiptir. Aşağıdaki tablolar bu seçenekleri ayrı ayrı değerlendirir.

ECDSA P-256 gibi eliptik eğri tabanlı seçenekler de Provider listesinde yer alır. Ancak bu seçeneklerde tüm istemci, uygulama ve Network cihazlarının ECDSA imzalı sertifikaları desteklediğinin önceden doğrulanması gerekir.

Adım 13 - CA Name

CA Name sayfasında Wizard, Domain ve Hostname bilgisinden türetilmiş bir Common Name önerir. Önerilen abc-TRISTSRVCER01-CA ismi yerine, kurumsal anlam taşıyan ve Hostname'den bağımsız ABC-Corporate-Root-CA adı girilir.

Distinguished name suffix alanında DC=abc,DC=local değeri otomatik olarak yer alır. Bu değer, Domain bilgisinin DN formatına dönüştürülmüş hâlidir. Preview of distinguished name alanında ise CA'nın tam DN değeri görüntülenir.

Kontrol Noktası
Preview of distinguished name alanında CN=ABC-Corporate-Root-CA,DC=abc,DC=local değeri görünür.

Adım 14 - Validity Period

Validity Period sayfasında CA sertifikasının geçerlilik süresi belirlenir. Bu kurulumda süre 5 yıl olarak bırakılmıştır.

CA, kendi sertifikasının kalan ömründen daha uzun süreli bir sertifika veremez. Bir şablon daha uzun bir süre tanımlasa bile verilen sertifikanın bitiş tarihi CA sertifikasının bitiş tarihiyle sınırlanır. Bu nedenle CA sertifikasının ömrü, verilecek sertifikaların ömründen belirgin şekilde uzun planlanır. 5 yıl laboratuvar ortamı için yeterlidir. Üretimde Root CA sertifikası için daha uzun süreler, CA sertifikasının yenileme takvimiyle birlikte planlanır.

Adım 15 - CA Database

CA Database sayfasında sertifika veritabanının ve Log dosyalarının saklanacağı dizinler belirlenir. Varsayılan olarak C:\Windows\system32\CertLog dizini önerilir ve bu kurulumda varsayılan değer kullanılmıştır. Üretim ortamında veritabanı ve Log dizininin ayrı bir veri diskinde tutulması, yönetim ve yedekleme açısından daha doğru olur.

Adım 16 - Confirmation ve Results

Confirmation sayfasında önceki adımlarda yapılan seçimlerin özeti yer alır. CA Type olarak Enterprise Root, Cryptographic Provider olarak RSA Microsoft Software Key Storage Provider, Hash Algorithm olarak SHA256, Key Length olarak 2048 ve Distinguished Name olarak CN=ABC-Corporate-Root-CA,DC=abc,DC=local görüntülenir. Configure butonuna tıklanarak yapılandırma başlatılır.

Kontrol Noktası
Results sayfasında Certification Authority ve Certification Authority Web Enrollment için Configuration succeeded mesajı görünür.

7- PowerShell ile AD CS Kurulumu

Adım 1 ile Adım 16 arasında yapılan kurulum, PowerShell üzerinden de gerçekleştirilebilir. Bu yöntem Server Core ortamları, otomasyon ve tekrarlanabilir kurulumlar için tercih edilir. Komutlar grafik arayüzle yapılan kurulumun alternatifidir. Wizard ile yapılandırılmış bir sunucuda yeniden çalıştırılmaz.

İlk komut AD CS rolünü ve yönetim araçlarını sunucuya yükler. Bu adım Adım 1 ile Adım 6 arasındaki rol kurulumunun karşılığıdır.

Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

İkinci komut, Configuration Wizard'da verilen kararları parametre olarak alır ve Enterprise Root CA yapılandırmasını tamamlar. Parametreler Karar Tablosu'ndaki seçimlerle birebir eşleşir.

$params = @{
    CAType              = "EnterpriseRootCA"
    CACommonName        = "ABC-Corporate-Root-CA"
    CryptoProviderName  = "RSA#Microsoft Software Key Storage Provider"
    KeyLength           = 2048
    HashAlgorithmName   = "SHA256"
    ValidityPeriod      = "Years"
    ValidityPeriodUnits = 5
}
Install-AdcsCertificationAuthority @params -Force

Web Enrollment servisi de kurulacaksa aşağıdaki komutlar çalıştırılır. İlk komut Web Enrollment rol servisini ve gerekli IIS bileşenlerini yükler, ikinci komut servisi yapılandırır.

Install-WindowsFeature -Name ADCS-Web-Enrollment -IncludeManagementTools
Install-AdcsWebEnrollment -Force

Install-AdcsCertificationAuthority, Wizard ile aynı yetkileri ister. PowerShell yönetici olarak açılmış olmalı ve Enterprise CA kurulumu için komut Enterprise Admins üyesi bir hesapla çalıştırılmalıdır. Oturum açan hesap bu gruba üye değilse yetkili hesap -Credential parametresiyle verilir.

8- Kurulum Sonrası İşlemler

Configuration Wizard tamamlandığında CA çalışır durumdadır. Ancak Web Enrollment'ın güvenli hale getirilmesi, yayımlanan şablonların gözden geçirilmesi, denetimin açılması ve CA'nın yedeklenmesi kurulumun parçası olarak ele alınır. Bu adımlar TRISTSRVCER01 üzerinde, yönetici olarak açılmış bir PowerShell oturumunda yapılır. Her adımın gerektirdiği yetki adımın içinde belirtilir ve her işlem bu yetkiyle sınırlı bir hesapla yapılır.

Adım 17 - Web Enrollment'ın Güvenli Hale Getirilmesi

Web Enrollment, kurulumdan sonra IIS üzerinde HTTP ile yayın yapar. AD CS'in HTTP uç noktaları, NTLM Relay saldırılarında hedef olarak kullanılabilir. Microsoft KB5005413, bu uç noktalarda HTTPS zorunluluğunu ve Extended Protection for Authentication (EPA) kullanılmasını önerir. Bu adımdaki işlemler CA sunucusunda yerel Administrators yetkisi gerektirir.

Web Enrollment kullanılmayacaksa servis kaldırılır. Sertifika talepleri Autoenrollment ve certlm.msc üzerinden yapılacaksa tarayıcı arayüzüne ihtiyaç yoktur. Aşağıdaki komutlar Web Enrollment yapılandırmasını ve rol servisini kaldırır. IIS rolü sunucuda kalır, başka bir amaçla kullanılmıyorsa ayrıca kaldırılabilir.

Uninstall-AdcsWebEnrollment -Force
Uninstall-WindowsFeature -Name ADCS-Web-Enrollment

Web Enrollment kullanılacaksa HTTPS ve EPA yapılandırılır. Önce sunucunun FQDN'ini (TRISTSRVCER01.abc.local) SAN olarak içeren bir Web Server sertifikası alınır. Bu sertifikanın hangi şablondan ve hangi izinlerle alınacağı Certificate Template yapılandırmasına bağlıdır ve bu makalenin kapsamı dışındadır. Sertifika alındıktan sonra IIS Manager'da şu ayarlar yapılır.

Sites altında Default Web Site seçilir ve 443/TCP için HTTPS Binding'i, alınan sunucu sertifikasıyla yapılandırılır. CertSrv sanal dizininde SSL Settings açılır ve Require SSL etkinleştirilir. Aynı dizinde Authentication altındaki Windows Authentication için Advanced Settings açılır ve Extended Protection değeri Required olarak ayarlanır.

KB5005413'e göre bu değişikliklerin devreye girmesi için IIS yeniden başlatılır. Komut yönetici olarak açılmış Command Prompt veya PowerShell oturumunda çalıştırılır.

iisreset /restart

Kontrol Noktası
https://TRISTSRVCER01.abc.local/certsrv adresi Domain üyesi bir istemciden sertifika uyarısı olmadan açılır, HTTP üzerinden erişim ise reddedilir.

Adım 18 - Yayımlanan Certificate Template'lerin Gözden Geçirilmesi

Enterprise CA, kurulum sırasında bir grup varsayılan Certificate Template'i otomatik olarak yayımlar. Bu şablonların bir kısmı Domain Controller, bilgisayar ve kullanıcı sertifikaları içindir ve izinleri uygun olan nesneler bu şablonlardan sertifika alabilir. Kullanılmayacak şablonların yayımdan kaldırılması, CA'nın vereceği sertifika türlerini planlanan kapsamla sınırlar.

certutil -CATemplates

Komut, CA'nın şu anda yayımladığı şablonları listeler. Kullanılmayacağı netleşen bir şablon aşağıdaki komutla yayımdan kaldırılır. {Şablon Adı} yerine certutil -CATemplates çıktısındaki şablon adı yazılır.

Remove-CATemplate -Name "{Şablon Adı}" -Force

Remove-CATemplate şablonu Active Directory'den silmez, yalnızca CA'nın sertifika verdiği şablonlar listesinden çıkarır. Bu liste Active Directory'deki Enrollment Services nesnesinde tutulduğu için işlem, bu nesne üzerinde yazma yetkisi olan bir hesapla yapılır. Aynı işlem certsrv.msc içinde Certificate Templates klasöründe şablona sağ tıklanıp Delete seçilerek de yapılabilir.

Adım 19 - Audit Ayarlarının Açılması

CA'nın sertifika talebi, onay, iptal ve yapılandırma değişikliklerini kaydetmesi için iki ayarın birlikte yapılması gerekir. İlki CA'nın hangi olay türlerini denetleyeceğini belirleyen AuditFilter değeridir. İkincisi Windows'un bu olayları Security Log'a yazmasını sağlayan Certification Services denetim alt kategorisidir. AuditFilter değişikliği CA üzerinde Manage CA (CA Administrator) yetkisi, auditpol ve servis yeniden başlatma ise yerel Administrators yetkisi gerektirir.

certutil -setreg CA\AuditFilter 127
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
Restart-Service -Name CertSvc

127 değeri, AD CS'in denetleyebildiği tüm olay gruplarını açar. certutil -getreg CA\AuditFilter komutuyla değerin 127 (0x7f) olarak kaydedildiği doğrulanır. Domain'de Advanced Audit Policy bir GPO ile yönetiliyorsa auditpol ile yapılan yerel ayar GPO tarafından ezilebilir. Bu durumda Certification Services alt kategorisi ilgili GPO'da açılır.

Adım 20 - CA Yedeğinin Alınması

CA'nın Private Key'i ve sertifikası, sertifika veritabanı ve kayıt defterindeki yapılandırması CA'nın kimliğini oluşturur. Sunucu kaybedildiğinde aynı CA'nın yeniden kurulabilmesi için bu üç bileşenin yedeği gerekir. Yedek, Adım 11 - Private Key ekranındaki Use existing private key seçeneğiyle yapılan geri yüklemelerde kullanılır. Yedekleme işlemi CA sunucusunda yerel Administrators yetkisiyle yapılır.

New-Item -Path C:\CABackup -ItemType Directory -Force
Backup-CARoleService -Path C:\CABackup -Password (Read-Host -Prompt "Yedek parolası" -AsSecureString)
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" C:\CABackup\CAConfig.reg

Backup-CARoleService, CA sertifikasını Private Key ile birlikte parola korumalı bir dosyaya ve sertifika veritabanını ayrı bir klasöre yedekler. reg export komutu ise CA yapılandırmasını, yani yayım noktalarını, Audit ayarlarını ve CRL sürelerini içeren kayıt defteri anahtarını dışa aktarır. Yedek için boş bir klasör kullanılır.

Adım 21 - Root CA Sertifikasının Dışa Aktarılması

Domain üyesi makineler Root CA sertifikasını Active Directory üzerinden otomatik olarak alır. Domain'e üye olmayan cihazlar, Network cihazları veya Intune ile yönetilen cihazlar için ise Root CA sertifikasının bir dosya olarak dağıtılması gerekir. Sertifika, klasik yöntemde certutil ile, bu kurulumda ise PowerShell Export-Certificate cmdlet'iyle dışa aktarılır. İşlem CA sunucusunda yerel Administrators yetkisiyle yapılır.

Sertifikanın filtrelenmesi. Yerel makinenin Root mağazasında Subject ve Issuer alanı eşit olan, yani Self-Signed olan sertifikalar listelenir.

Get-ChildItem -Path Cert:\LocalMachine\Root |
    Where-Object { $_.Subject -eq $_.Issuer -and $_.Subject -like "*$env:USERDOMAIN*" } |
    Format-List Subject, Issuer, Thumbprint, NotBefore, NotAfter

$_.Subject -eq $_.Issuer ifadesi Self-Signed sertifikaları yakalar. $env:USERDOMAIN değişkeni Domain'in NetBIOS adını (ABC) döndürür ve filtreyi Microsoft'un Root sertifikalarından ayırır. Format-List ise çıktının kesilmesini önler ve her alanı alt alta gösterir.

Komut çalıştırıldığında çıktıda iki kayıt yer alır. Her ikisinin Thumbprint değeri B8328E38954DC0E0CBF3D67B86296D7CD3C74B73, Subject değeri ise CN=ABC-Corporate-Root-CA, DC=abc, DC=local olarak birebir aynıdır. İki kaydın aynı sertifika olduğu Thumbprint eşitliğinden anlaşılır. Bu tekrarın nedeni Trusted Root Certification Authorities Mağazası başlığında açıklanır.

-like "*$env:USERDOMAIN*" filtresi, Subject'inde ABC geçen başka bir Root sertifikasını da yakalayabilir. Birden fazla iç Root CA bulunan ortamlarda tam Subject eşleşmesi kullanmak daha güvenlidir.

Get-ChildItem -Path Cert:\LocalMachine\Root |
    Where-Object { $_.Subject -eq "CN=ABC-Corporate-Root-CA, DC=abc, DC=local" } |
    Format-List Subject, Issuer, Thumbprint, NotBefore, NotAfter

System.Object[] hatası. Export-Certificate cmdlet'i tek bir sertifika nesnesi bekler. Filtre aynı sertifikanın iki kaydını döndürdüğü için sonuç doğrudan Export-Certificate'a verildiğinde aşağıdaki hata alınır.

Cannot convert 'System.Object[]' to the type
'Microsoft.CertificateServices.Commands.Certificate'

Çözüm için filtreye Select-Object -First 1 eklenir. İki kaydın Thumbprint değeri aynı olduğu için hangisinin seçildiği sonucu değiştirmez.

Export-Certificate ile dışa aktarma. Aşağıdaki komut sertifikayı tek nesneye indirger ve C:\Temp\RootCA.cer dosyasına dışa aktarır.

$cert = Get-ChildItem -Path Cert:\LocalMachine\Root |
        Where-Object { $_.Subject -eq $_.Issuer -and $_.Subject -like "*$env:USERDOMAIN*" } |
        Select-Object -First 1

Export-Certificate -Cert $cert -FilePath C:\Temp\RootCA.cer

Komut başarıyla çalıştığında PowerShell çıktısında oluşturulan dosya listelenir. Mode sütunundaki -a---- değeri dosyanın arşiv özniteliğiyle oluşturulduğunu, Length sütunundaki 887 bayt değeri ise sertifikanın DER kodlu binary boyutunu gösterir. C:\Temp dizini açıldığında RootCA.cer dosyası Security Certificate türünde görünür.

Aynı işlem klasik yöntemle certutil üzerinden de yapılabilir. Bu komut, CA sunucusunda çalıştırıldığında CA'nın kendi sertifikasını doğrudan dosyaya yazar.

certutil -ca.cert C:\Temp\RootCA.cer

Kontrol Noktası
C:\Temp\RootCA.cer dosyası oluşmuştur ve açıldığında Issued to ile Issued by alanlarında ABC-Corporate-Root-CA görünür.

9- Doğrulama

Kurulum tek bir komut veya tek bir ekran üzerinden değil, birden fazla katmanda doğrulanır. Yönetim konsolları CA servisinin çalıştığını, pkiview.msc ve certutil AD entegrasyonunu ve yapılandırmayı, certutil -dump ise sertifikanın kriptografik yapısını gösterir. Konsollar ve komutlar TRISTSRVCER01 üzerinde çalıştırılır.

certsrv.msc ile CA Servisinin Kontrolü

Run penceresinde certsrv.msc komutu çalıştırılır. Konsol açıldığında sol panelde ABC-Corporate-Root-CA nesnesi yeşil tik ile yer alır. Altında Revoked Certificates, Issued Certificates, Pending Requests, Failed Requests ve Certificate Templates klasörleri görünür. Adım 6'da CA'ya bağlanamayan konsolun artık bağlanması, CertSvc servisinin oluşturulduğunu gösterir.

pkiview.msc ile PKI Sağlık Kontrolü

pkiview.msc, AD CS dağıtımının sağlığını kontrol etmek için kullanılan Enterprise PKI aracıdır. Araç, hiyerarşideki CA sertifikalarını ve AIA, CDP ile DeltaCRL yayım noktalarını tarar ve her birinin erişilebilirlik durumunu raporlar.

Araç açıldığında sol panelde Enterprise PKI altında ABC-Corporate-Root-CA (V0.0) görüntülenir. Sağ panelde CA Certificate, AIA Location #1, CDP Location #1 ve DeltaCRL Location #1 satırlarının Status sütununda OK yer alır. Location sütunundaki ldap:///CN=ABC-Corporate-Root-CA,... biçimindeki URL'ler, CA sertifikasının ve CRL'nin Active Directory'de LDAP üzerinden yayımlandığını gösterir.

Yayım Noktalarının Kontrolü

pkiview.msc mevcut erişim durumunu gösterir. CA'nın sertifikaları ve CRL'leri hangi konumlara yayımlayacağı ise CA yapılandırmasında tanımlıdır ve aşağıdaki komutlarla görüntülenir.

certutil -getreg CA\CACertPublicationURLs
certutil -getreg CA\CRLPublicationURLs

Çıktıdaki her satırın başındaki sayı, o konumun yayım için mi, sertifikalara eklenmek için mi kullanılacağını belirleyen bayraklardır. ldap:/// ile başlayan satırlar Active Directory yayımını, http:// ile başlayan satırlar ise IIS altındaki CertEnroll dizinini gösterir. URL'lerdeki %1, %3 gibi değişkenler sunucu adı ve CA adı gibi değerlerle doldurulur.

Domain'e üye olmayan cihazlar LDAP yayım noktalarına erişemez. Bu cihazların sertifika zincirini ve iptal durumunu doğrulayabilmesi için AIA ve CDP konumlarının HTTP üzerinden erişilebilir olması gerekir. Bu makalede HTTP yayım yapılandırması uygulanmadığı için kurulum laboratuvar ve test kapsamındadır.

certutil -cainfo ile Komut Satırı Doğrulaması

certutil -cainfo komutu CA'nın temel yapılandırma bilgilerini listeler.

certutil -cainfo

Komut çıktısında öne çıkan alanlar ve anlamları aşağıdaki tabloda özetlenmiştir.

CA Properties Üzerinden Cryptographic Settings Kontrolü

certsrv.msc konsolunda ABC-Corporate-Root-CA üzerine sağ tıklanıp Properties seçilir. General sekmesindeki Cryptographic settings bölümünde Provider: Microsoft Software Key Storage Provider ve Hash Algorithm: SHA256 bilgileri görüntülenir. Bu değerler Adım 12 - Cryptography for CA ekranında yapılan seçimlerin CA tarafından kullanıldığını doğrular.

Root CA Sertifikasının General ve Certification Path Sekmeleri

CA Properties penceresinde View Certificate butonuna tıklandığında Root CA sertifikasının ayrıntıları açılır.

General sekmesinde Issued to: ABC-Corporate-Root-CA ve Issued by: ABC-Corporate-Root-CA satırlarının aynı olması, sertifikanın Self-Signed bir Root sertifikası olduğunu gösterir. Aynı değerin hem Subject hem Issuer alanında yer alması, sertifikanın kendi Private Key'iyle imzalandığı anlamına gelir. Valid from 5/17/2026 to 5/17/2031 satırı, Adım 14 - Validity Period ekranında seçilen 5 yıllık sürenin uygulandığını gösterir.



Certification Path sekmesinde sertifika zinciri görüntülenir. Root sertifikası söz konusu olduğu için zincirde tek bir öğe vardır ve bu öğe ABC-Corporate-Root-CA'nın kendisidir. Alt kısımdaki This certificate is OK. mesajı, sertifikanın güvenilir Root mağazasında bulunduğunu ve zincirin doğrulandığını gösterir.

Trusted Root Certification Authorities Mağazası

Root CA sertifikasının yerel makine mağazasındaki konumu Run penceresinden certlm.msc komutuyla kontrol edilir. Trusted Root Certification Authorities altındaki Certificates klasörü açıldığında ABC-Corporate-Root-CA sertifikasının iki kez listelendiği görülür.

Bu görünüm bir tekrar kaydı değildir. certlm.msc'deki Trusted Root Certification Authorities mantıksal bir mağazadır ve birden fazla fiziksel mağazanın içeriğini birlikte gösterir. Sertifikanın ilk kopyası, CA kurulumu sırasında sunucunun yerel Registry mağazasına yazılır. İkinci kopya ise Active Directory'deki Public Key Services Container'ı altında bulunan Certification Authorities nesnesinden çekilen Enterprise mağazasından gelir. Domain üyesi diğer makineler de Root CA sertifikasını bu Enterprise mağazası üzerinden alır.

Enterprise mağazasının içeriği aşağıdaki komutla ayrıca görüntülenebilir.

certutil -enterprise -store Root

certutil -dump ile Sertifika Analizi

Sertifika dosyasının iç yapısı certutil -dump komutuyla incelenir. Bu komut sertifikanın X.509 alanlarını, Extension'larını ve hash değerlerini metin olarak yazdırır. Çıktıyı ekranda incelemek yerine UTF-8 kodlamasıyla bir dosyaya aktarmak hem kalıcılık hem okunabilirlik sağlar. Komut, Adım 21 - Root CA Sertifikasının Dışa Aktarılması başlığında oluşturulan RootCA.cer dosyasını kullanır.

certutil -dump C:\Temp\RootCA.cer | Out-File -FilePath C:\Temp\RootCA-Dump.txt -Encoding UTF8

Oluşan dosya yaklaşık 5 KB boyutundadır. Dosyada sertifikanın temel bilgileri, Extension'ları ve hash ile imza doğrulama satırları yer alır. Bu bölümde temel bilgiler ile hash ve imza satırları incelenir.

Sertifika temel bilgileri. Dump dosyasının ilk bölümü sertifikanın X.509 sürümünü, seri numarasını, imzalama algoritmasını, Issuer ve Subject bilgisini, geçerlilik aralığını ve Public Key bilgisini gösterir.

Bu laboratuvarda NotBefore ile NotAfter arasında 10 dakikalık bir fark görülür ve bu bir hata değildir. AD CS, CA ile istemciler arasındaki olası saat farklarını tolere etmek için NotBefore değerini oluşturma anından biraz geriye çeker. Bu sürenin uzunluğu ClockSkewMinutes ayarıyla belirlenir ve CAPolicy.inf dosyası üzerinden yapılandırılabilir.

Bu bilgiler birlikte değerlendirildiğinde sertifikanın X.509 Version 3 formatında, sha256RSA algoritmasıyla imzalanmış, 2048 bit RSA Public Key kullanan ve Issuer ile Subject alanları aynı olan Self-Signed bir Root CA sertifikası olduğu doğrulanır.

Hash ve imza doğrulama satırları. Dump dosyasının son bölümünde imzanın bayt dökümü ve doğrulama satırları yer alır.

Signature matches Public Key satırı, sertifikadaki imzanın aynı sertifikadaki Public Key ile doğrulandığını ifade eder. Self-Signed sertifikalarda bu, sertifikanın kendi Private Key'iyle imzalandığının kriptografik teyididir.

Root Certificate: Subject matches Issuer satırı, Subject ve Issuer alanlarının birebir eşleştiğini ve sertifikanın bir Root sertifikası olduğunu gösterir.

Cert Hash(sha1) ve Cert Hash(sha256) satırları sertifikanın SHA-1 ve SHA-256 hash değerlerini verir. Windows arayüzünde ve PowerShell'de Thumbprint olarak gösterilen değer SHA-1 hash'tir. SHA-256 hash ise sertifikayı daha güçlü bir özetle tanımlamak için kullanılır. İşlem CertUtil: -dump command completed successfully. satırıyla sona erer.

Özet Kontrol Tablosu

Aşağıdaki tablo doğrulama sırasında kontrol edilen alanları ve beklenen değerleri bir arada gösterir. CA tipi değerleri Adım 9 - Setup Type ve Adım 10 - CA Type, kriptografi değerleri Adım 12 - Cryptography for CA, isim değerleri ise Adım 13 - CA Name ekranında verilen kararlarla eşleşir.

10- Yeniden Çalıştırma, Geri Alma ve Sorun Giderme

Configuration Wizard, CA yapılandırılmışken yeniden çalıştırılamaz. Yapılandırma farklı parametrelerle tekrarlanacaksa önce mevcut CA yapılandırması kaldırılır. Wizard yarıda kesilmiş veya hata vermişse de aynı yol izlenir. Hatanın nedeni giderildikten sonra kısmi yapılandırma kaldırılır ve Wizard yeniden çalıştırılır.

Kurulum hatalarında PowerShell ile yapılan kurulumlar -Verbose parametresiyle yeniden çalıştırılarak ayrıntılı çıktı alınır. AD CS kurulumu, ilerleyişini %windir% dizinindeki bir kurulum Log'una yazar. Bu Log dosyası aşağıdaki komutla bulunur ve en son değişen dosya incelenir.

Get-ChildItem -Path $env:windir -Filter *ocm.log | Sort-Object LastWriteTime -Descending

CA servisi çalışırken oluşan hatalar ise Event Viewer'da Application Log altında CertificationAuthority kaynaklı olaylar olarak görünür.

CA yapılandırması ve rolü aşağıdaki komutlarla kaldırılır. Komutlar CA sunucusunda yönetici olarak açılmış PowerShell oturumunda, Enterprise CA için Enterprise Admins üyesi bir hesapla çalıştırılır.

Uninstall-AdcsCertificationAuthority -Force
Uninstall-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

Bu komutlar sunucudaki CA servisini kaldırır, ancak Active Directory'de oluşturulan PKI nesnelerine dokunmaz. CA'nın sertifikası Certification Authorities, AIA ve NTAuthCertificates nesnelerinde, CRL'leri CDP altında, kayıt bilgisi ise Enrollment Services altında kalır. Bu nesneler temizlenmezse Domain üyesi makineler kaldırılmış CA'ya güvenmeye devam eder.

Kalan nesneler pkiview.msc içinde Enterprise PKI üzerine sağ tıklanıp Manage AD Containers seçilerek açılan pencereden kaldırılır. Bu nesneler Forest'ın Configuration bölümünde bulunduğu için işlem Enterprise Admins yetkisi gerektirir. Kalıcı bir CA kaldırılacaksa, temizlikten önce CA'nın verdiği sertifikalar iptal edilir ve son CRL yayımlanır.

11- Kapanış ve Sonraki Adımlar

Kurulumun tamamlandığı Özet Kontrol Tablosu üzerinden değerlendirilir. Tablodaki tüm alanların beklenen değerleri vermesi, Web Enrollment'ın HTTPS ve EPA ile yapılandırılmış ya da kaldırılmış olması ve CA yedeğinin sunucu dışında güvenli bir ortamda saklanması, Enterprise Root CA'nın laboratuvar ve test kullanımına hazır olduğunu gösterir.

Tek katmanlı Enterprise Root CA, laboratuvar ve test ortamları için hızlı bir başlangıç noktasıdır. Üretim ortamında CA sayısı ve hiyerarşi kurumun gereksinimlerine göre planlanır. Offline Root CA ve Online Subordinate CA içeren iki katmanlı yapı bu planlamada güçlü ve yaygın bir seçenektir. CA'nın Domain Controller üzerine kurulmaması, Private Key'in HSM ile korunması ve CA sunucusunun Tier 0 asset olarak sıkılaştırılması da bu tasarımın parçalarıdır.

Bu CA ile üretim sertifikası verilmeden önce ilk yapılacak iş, AIA ve CDP yayım noktalarının HTTP üzerinden erişilebilir şekilde planlanıp yapılandırılmasıdır. Ardından Certificate Template'lerin yapılandırılması, Autoenrollment'ın Group Policy ile dağıtılması ve Two-Tier PKI hiyerarşisinin kurulması ayrı makalelerde ele alınacaktır.

Faydalı olması dileğiyle...