Active Directory Certificate Services (AD CS) Kurulumu

Kendi sertifika otoritenizi kurmaya karar verdiyseniz, Windows tarafındaki karşılığı Active Directory Certificate Services (AD CS) rolüdür. Kurulumun kendisi yarım günlük bir iştir; asıl zorluk, sihirbazın birkaç ekranında verilen ve sonradan geri alınamayan kararlarda saklıdır.

Bu rehber o kararların hangileri olduğunu ve nerede karşınıza çıkacağını sırayla gösteriyor. Kendi iç CA’nızı kurmanın ne zaman doğru olduğunu, public CA ile farkını ve self-signed sertifikanın nerede yettiğini sertifika otoritesi rehberimizde ele aldık; burada kararı çoktan vermiş olduğunuzu varsayıyoruz.

AD CS, Windows Server rehberimizde tanıttığımız sunucu rollerinden biridir ve kurulumu diğer rollerden bir yönüyle ayrılır: verdiğiniz kararların çoğu geri alınamaz. Bu makale BT Sistem Yönetimi ana hizmetimizin sunucu kurulum ve yapılandırma koluna odaklanır.

Ön koşulları biliyor ve doğrudan kuruluma geçmek istiyorsanız rol kurulumu bölümüne atlayabilirsiniz.

AD CS Kurulumundan Önce: Ön Koşullar ve Yetki

Bu rehber, üzerine rol kuracağınız Windows Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk yapılandırma ayrı bir konudur ve Windows Server kurulum rehberimizde ele alınmaktadır. Buradan itibaren elinizde çalışan, ağa bağlı bir sunucu olduğunu kabul ediyoruz.

AD CS kurulumuna başlamadan önce üç şeyin kesinleşmiş olması gerekir, çünkü üçü de kurulumdan sonra değiştirilemez ya da değiştirilmesi çok pahalıdır.

Makine Adı ve IP Kurulumdan Önce Kesinleşir

Sunucunun adı, statik IP’si ve domain üyeliği AD CS kurulmadan önce tamamlanmış olmalıdır. Bunun sebebi kozmetik değil: CA kurulduktan sonra sunucunun adı değiştirilirse, o CA’nın bastığı bütün sertifikalar geçersizleşir. Adı değiştirmek isterseniz CA’yı kaldırmanız, makineyi yeniden adlandırmanız, CA’yı aynı anahtarlarla yeniden kurmanız ve kayıt defterini elle düzeltmeniz gerekir.

Aynı sebep, CA’yı bir domain controller üzerine kurmamanın da gerekçesidir: adı ve rolü zaman içinde değişme ihtimali en yüksek makine odur.

Enterprise CA İçin Domain Admin Yetmiyor

Bu, kurulumda en çok vakit kaybettiren yerdir ve sihirbaz size sebebini söylemez. Enterprise CA kurabilmek için Enterprise Admins grubuna üye olmanız gerekir; Domain Admins üyeliği yeterli değildir.

Sebebi mimari: Enterprise CA kendini ormanın Configuration bölümüne yazar, o alan tek bir domainin değil bütün ormanın ortak alanıdır ve oraya yazma yetkisi orman düzeyindedir.

Yetki eksikse sihirbaz hata vermez, sadece Enterprise CA seçeneğini soluk gösterir ve size yalnız Standalone CA bırakır. Standalone CA da kurulur, ama Active Directory’ye hiçbir şey yazmaz: şablon olmaz, otomatik kayıt olmaz, istemciler CA’yı bulamaz. Yani sessizce yanlış yapıya kurulmuş olursunuz.

Yetkinizi kurulumdan önce doğrulayın. Kuracağınız sunucuda, kurulumu yapacağınız hesapla oturum açmışken:

whoami /groups

Çıktıda Enterprise Admins satırını arayın. Bu kontrolü dizin sorgusuyla değil oturum açmış hesabın kendisiyle yapın: Get-ADUser -Properties MemberOf yalnız doğrudan üyelikleri döndürür, oysa yetki çoğu kurumda bir yönetici grubunun içine gömülü ikinci bir grup üzerinden gelir. whoami /groups oturum jetonunun gerçekte taşıdığını gösterir, yani sihirbazın göreceğini.

Satır yoksa ya o gruba üye bir hesapla oturum açın ya da kurulum süresince hesabınızı geçici olarak ekleyip iş bitince çıkarın. Enterprise Admins ormanın en yüksek yetkisidir ve günlük kullanılan bir hesapta kalıcı olarak durmamalıdır. Gruba yeni eklendiyseniz oturumu kapatıp yeniden açın; jeton oturum açarken üretilir, sonradan güncellenmez.

CA Adı Kurallarını Önceden Belirleyin

CA adı sertifikaların içine gömülür ve kurulumdan sonra değiştirilemez. Üç kural var:

• Sunucunun tam alan adını (FQDN) kullanmayın. Sertifikayı ele geçiren biri CA’nın FQDN’ini öğrenmiş olur.
• Bilgisayar adıyla aynı olmasın.
• Alt çizgi gibi özel karakterlerden kaçının. Bazı ağ cihazları, CA adında özel karakter varsa sertifika kaydı yapamaz.

AD CS Rolü Kurulumu: Süreç İki Aşamalıdır

AD CS’in en çok kafa karıştıran yanı, kurulumun tek bir sihirbazda bitmemesidir. İki ayrı aşama vardır ve aradıklarınızın çoğu ikincisindedir.

Birinci aşama, Add Roles and Features: yalnızca dosyaları diske kurar. Burada size CA adı, tip veya geçerlilik süresi sorulmaz. Rol servisleri ekranında yalnız Certification Authority işaretlenir; Web Enrollment, NDES ve Online Responder sonradan, CA’yı yeniden kurmadan eklenebilir.

İkinci aşama, Configure Active Directory Certificate Services: asıl kararların verildiği yer. Birinci aşama bitince Server Manager’da sarı bir uyarı bayrağı belirir ve bu sihirbaza oradan girilir. Geri alınamayan her şey buradadır.

Bu ayrımın ne kadar sinsi olduğunu bu makaleyi hazırlarken bir kez daha gördüm. Kurulumu adım adım not alarak ilerliyordum ve elimde hangi ekranda ne seçeceğimin listesi vardı: Setup Type, CA Type, CA Name, Validity Period. Sihirbazı açtım, sol taraftaki adım listesine baktım ve orada yalnız beş satır vardı: Credentials, Role Services, Confirmation, Progress, Results. Aradığım ekranların hiçbiri yoktu.

Bir süre “yanlış yerden mi girdim” diye düşündüm. Yanlış bir şey yapmamıştım. O ekranlar listede yoktu çünkü Role Services adımında kutuyu işaretlemeden listeye eklenmiyorlar. Kutuyu işaretleyip ilerlediğim an sol taraf uzadı ve aradığım yedi ekran belirdi.

On beş yıldır bu tür konsollarla çalışıyorum ve yine de bir an durup düşündürdü. Sizin de duraksamanız muhtemel, o yüzden yazıyorum: liste kısa görünüyorsa bir şeyi kaçırmış değilsiniz, henüz kutuyu işaretlememişsinizdir.

CA Yapılandırma Sihirbazı: Ekran Ekran

İkinci aşama on ekrandan oluşur ve dördü geri alınamayan karar taşır. Sırayla gidiyoruz.

1. Credentials. Yapılandırmayı hangi hesabın yürüteceğini gösterir. Buradaki hesap Enterprise Admins üyesi olmalıdır; değilse Change... ile üye olan bir hesaba geçin. Bu ekranı hızlı geçmek, üç ekran sonra soluk gelen bir seçenekle geri dönmek demektir.
2. Role Services. Certification Authority kutusunu işaretleyin. Listedeki diğer beş servis (Web Enrollment, Online Responder, NDES ve iki Enrollment Web Service) kurulu olmadıkları için soluk görünür; sonradan rol olarak eklenip yine buradan yapılandırılabilirler.
3. Setup Type. Enterprise CA seçin. Bu seçenek CA’yı Active Directory’ye bağlar: kök sertifika dizine yazılır, şablonlar kullanılabilir hale gelir, domain üyesi makineler CA’yı kendiliğinden bulur. Standalone CA Active Directory’siz ortamlar içindir; domain varken onu seçmek kurduğunuz yapının yarısını kapatmaktır. Enterprise CA soluksa 1. adımdaki hesap Enterprise Admins üyesi değildir.
4. CA Type. İlk CA’nız için Root CA seçin. Subordinate CA, zaten var olan bir kökün altına ikinci katman kurarken kullanılır.
5. Private Key. Create a new private key seçin. Diğer seçenek (Use existing private key), çöken bir CA’yı aynı anahtarlarla geri getirirken kullanılır.
6. Cryptography for CA. Varsayılanları bırakın: sağlayıcı RSA#Microsoft Software Key Storage Provider, anahtar uzunluğu 2048, özet algoritması SHA256. Anahtarı uzatmak güvenliği artırır ama eski cihaz ve uygulamalarla uyumu bozabilir. Ekranın altındaki Allow administrator interaction when the private key is accessed by the CA kutusunu işaretlemeyin; sebebi aşağıda.
7. CA Name. Belirlediğiniz adı yazın. Sihirbazın önerdiği ad genellikle bilgisayar adını içerir; yukarıdaki adlandırma kurallarına uymuyorsa değiştirin. Bu ad sonradan değiştirilemez.
8. Validity Period. Varsayılan 5 yıl gelir. Bu, kök sertifikanın kendi ömrüdür ve iki sonucu vardır: CA kendi ömründen uzun süreli sertifika basamaz, ve yaygın uygulamaya göre kök sertifika ömrünün yarısında yenilenir. Yani 5 yıllık bir kökte yenileme takvimi 2,5. yıla düşer. Lab ve KOBİ ölçeğinde 10 yıl makul bir orta yoldur. Sihirbaz, yazdığınız sayıya göre bitiş tarihini kendisi hesaplayıp ekranda gösterir (CA expiration Date satırı); takvime yazacağınız tarih orada zaten duruyor. Değeri değiştirdiğinizde tarihin de güncellendiğini görürsünüz, bu iyi bir kontrol noktasıdır.
9. CA Database. Veritabanı ve günlük dosyalarının konumu. Varsayılan C:\Windows\System32\CertLog yeterlidir. Başka bir konum verirseniz o klasörlerin yetkilerini elle sınırlandırın.
10. Confirmation. Özet ekranı. Configure ile yapılandırma uygulanır, ardından Progress ve Results ekranları gelir. Results ekranında Certification Authority satırının karşısında Configuration succeeded yazmalıdır.

Configure’a Basmadan Önce: Özeti Karşılaştırın

Confirmation ekranı verdiğiniz bütün kararları tek listede toplar ve geri dönülmez adımdan önceki son kontrol noktasıdır. Bizim lab kurulumumuzda ekran şunu gösteriyordu:

Active Directory Certificate Services
  Certification Authority
    CA Type:                            Enterprise Root
    Cryptographic provider:             RSA#Microsoft Software Key Storage Provider
    Hash Algorithm:                     SHA256
    Key Length:                         2048
    Allow Administrator Interaction:    Disabled
    Certificate Validity Period:        10.08.2036 01:55:00
    Distinguished Name:                 CN=SerceBilisim-Lab-Root-CA,DC=ad,DC=sercebilisim,DC=com
    Certificate Database Location:      C:\WINDOWS\system32\CertLog
    Certificate Database Log Location:  C:\WINDOWS\system32\CertLog

Kendi ekranınızda dört satırı tek tek doğrulayın, çünkü dördü de sonradan düzeltilemez:

1. CA Type: Enterprise Root olmalı. Standalone yazıyorsa geri dönün; Active Directory’ye hiçbir şey yazılmayacak demektir.
2. Allow Administrator Interaction: Disabled olmalı. Enabled ise otomatik kayıt çalışmaz.
3. Distinguished Name içindeki ortak ad, adlandırma kurallarına uyuyor mu; sunucunun tam alan adı değil, bilgisayar adının aynısı değil.
4. Certificate Validity Period tarihi beklediğiniz yıl mı? Bu tarih hesaplanmış haliyle ekranda duruyor, takvime yazacağınız tarih de budur.

”Allow administrator interaction” Kutusu Ne Yapar?

Cryptography ekranındaki bu kutu, CA her imza atacağı zaman bir insanın onay vermesini şart koşar. CA’nın özel anahtarı yalnız sertifika ve iptal listesi imzalarken kullanılır; kutu işaretliyse bu erişimlerin her birinde kriptografi sağlayıcısı kullanıcıya bir kimlik doğrulama istemi gösterir.

Asıl kullanım yeri donanım güvenlik modülü (HSM) bulunan kurulumlardır: anahtar donanımda durur ve her işlemde PIN ister.

Çevrimiçi bir kurumsal CA’da işaretlenmez. Sebebi otomatik kaydın çalışma biçimidir: bir sunucu sertifika istediğinde CA’nın onu insan müdahalesi olmadan imzalaması gerekir. Kutu işaretliyse her istek, birinin CA konsoluna gidip onaylamasını bekler; otomatik kayıt fiilen durur ve iptal listesinin yenilenmesi de takılır.

Anlamlı olduğu tek senaryo çevrimdışı kök CA’dır: yılda yalnız birkaç kez, ara CA sertifikası ve CRL imzalamak için açılan, imzalarken de bilinçli olarak bir insan kapısı istenen kurulum.

Geri Alınamayan Dört Karar

Bir mühür bir kez kazınır. Üstündeki isim, ondan sonra basılan her belgeye o kazımayla geçer; beğenmezseniz mührü yeniden kazımaz, atıp yenisini yaptırırsınız. AD CS’in aşağıdaki dört kararı da kurulum anında kazınır: sonradan “düzeltmek” demek, ayarı değiştirmek değil, CA’yı kaldırıp yeniden kurmak demektir.

Yukarıdaki listede dikkat edilmesi gerekenler şunlar; kurulumdan sonra değiştirilmek istendiğinde CA’nın kaldırılıp yeniden kurulmasını gerektirirler:

Son ikisinin ekranda nasıl göründüğü, neden dikkatli geçilmesi gerektiğini de anlatıyor.

AIA ve CDP: İlk Sertifikadan Önce Ayarlanır

Kurulum biter bitmez sertifika basmaya başlamayın. Önce iki adres ayarı yapılmalıdır ve bunun zamanlaması kritiktir.

AIA (Authority Information Access) CA’nın kendi sertifikasının nereden indirileceğini, CDP (CRL Distribution Point) ise iptal listesinin nerede yayınlandığını söyler. İkisi de basılan her sertifikanın içine gömülür.

Kritik olan şu: bu adresleri sonradan değiştirmek yalnız yeni sertifikaları etkiler. Önceden basılmış sertifikalar eski adresi taşımaya devam eder ve düzeltmenin tek yolu hepsini yeniden basmaktır. Yanlış yapılandırmayla çıkan bir sertifika partisi, aylar sonra “iptal kontrolü takılıyor” arızası olarak geri döner.

İç CA’da en sık yapılan hata, iptal listesini yalnız iç ağdaki bir adreste yayınlamaktır: ofis dışında çalışan bir dizüstü bilgisayar o adrese erişemez ve doğrulama takılır.

AIA ve CDP Nereden Ayarlanır?

Ayar CA’nın kendi özelliklerindedir: certsrv.msc açın, sol ağaçta CA adına sağ tıklayıp Properties deyin ve Extensions sekmesine geçin. Üstteki açılır listeden hangi uzantıyı düzenlediğinizi seçersiniz.

• CRL Distribution Point (CDP) seçiliyken, listedeki her adres için altta kutucuklar çıkar. Sertifikaların içine gömülen adresi belirleyen kutu Include in the CDP extension of issued certificates’tir. İşaretli olmayan bir adres yayına girer ama sertifikalara yazılmaz.
• Authority Information Access (AIA) seçiliyken karşılığı Include in the AIA extension of issued certificates’tir.

Varsayılan olarak hem ldap:// hem http:// adresleri tanımlı gelir. ldap:// yalnız domain üyesi ve dizine erişebilen istemciler için çalışır; ofis dışındaki cihazları da düşünüyorsanız erişilebilir bir http:// adresi gerekir.

Kurulum Doğrulama: CA Ayakta mı, AD’ye Yazıldı mı?

Kurulum bitti demek çalışıyor demek değildir. İki taraftan da doğrulanır.

Sunucu Tarafı: Servis ve Konsol

CA servisinin durumunu kontrol edin:

Get-Service CertSvc

Status   Name      DisplayName
------   ----      -----------
Running  CertSvc   Active Directory Certificate Services

Ardından Certification Authority konsolunu açın. CA adının yanında yeşil bir işaret görünmelidir; kırmızı bir durak işareti servisin durduğunu gösterir.

Dizin Tarafı: CA Kendini AD’ye Yazdı mı?

Asıl doğrulama budur, çünkü Enterprise CA’nın Standalone’dan farkı tam olarak burada görünür. Domain üyesi istemcilerin CA’yı bulmasını sağlayan kayıt Active Directory’de durur:

CN=Enrollment Services,CN=Public Key Services,CN=Services,
CN=Configuration,DC=ad,DC=sercebilisim,DC=com

Bu konteynerin içinde CA’nızı temsil eden bir nesne olmalıdır. Boşsa CA ya Standalone kurulmuştur ya da AD’ye yazma yetkisi olmayan bir hesapla yapılandırılmıştır; ikisinde de otomatik kayıt çalışmaz.

Konsol açmadan, domain controller üzerinden aynı konteyneri PowerShell ile de sorgulayabilirsiniz:

$konfig = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$konfig" `
  -Filter 'objectClass -eq "pKIEnrollmentService"' -Properties dNSHostName |
  Select-Object Name, dNSHostName

Dönen satır CA’nın adını ve üzerinde çalıştığı sunucuyu gösterir. Hiç satır dönmüyorsa konteyner boş demektir; CA ayakta olsa bile domain üyeleri onu bulamaz.

Hangi Konsol Hangi Komutla Açılır?

Sertifika tarafında birden fazla konsol var ve yanlış olanı açmak, var olan bir sertifikayı yok sanmanıza yol açar.

Uçtan Uca Doğrulama: Bir İstemci Gerçekten Sertifika Aldı mı?

CA’nın ayakta olması, ondan sertifika alınabildiği anlamına gelmez. Bunun en hızlı kanıtı domain controller’ın kendisidir: uygun bir şablon yayındaysa, domain controller’lar sertifikalarını otomatik kayıtla kendileri talep eder ve bunun için hiçbir şey yapmanız gerekmez.

Domain controller üzerinde certlm.msc açıp Personal → Certificates dalına bakın.

Üç sütun kontrol edilir: Issued To sunucunun tam alan adı olmalı, Issued By yeni kurduğunuz CA’nın adını göstermeli, Certificate Template ise hangi şablondan geldiğini söylemeli. Bu üçü yerindeyse CA uçtan uca çalışıyor demektir.

Liste boşsa CA bozuk değildir; otomatik kayıt henüz tetiklenmemiştir. Grup ilkesi yenilemesi kendiliğinden olana kadar beklemek yerine sunucuda elle tetikleyin:

gpupdate /force
certutil -pulse

Doğrulamanın üç adımından biri başarısız olursa aşağıdaki hata listesine bakın.

CA’yı Yedekleyin: Üç Parça, Üç Ayrı Yer

CA ayakta ve çalışıyor. Sıradaki iş onu kaybetmeye karşı korumaktır, çünkü bu makinenin kaybı tek bir sunucunun kaybı değildir: CA giderse onun bastığı bütün sertifikaların arkasındaki imza dayanağı da gider. Yedeklenecek şey tek dosya değil, üç ayrı parça ve üçü farklı yerde durur.

Sertifika şablonları bu üçüne dahil değildir. Onlar CA’da değil, Active Directory’nin Configuration bölümünde, yani domain controller’ın system state yedeğindedir. En sık atlanan yer budur: CA’yı yedekleyip şablonları yedeklemediğini fark etmek çoğu zaman geri yükleme gününe kalır.

Anahtar, Sertifika ve Veritabanı

Üçü tek komutla, CA’nın kendi konsolunda alınır. Hedef klasör boş olmalıdır, dolu ise komut reddeder:

certutil -backup C:\ca-yedek

Komut ortada bir parola sorar: bu, özel anahtarı saran .p12 dosyasının parolasıdır. Bizim lab kurulumumuzda çıktı şuydu:

Backed up keys and certificates for ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA to C:\ca-yedek\SerceBilisim-Lab-Root-CA.p12.
Full database backup for ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA.
Backing up Database files: 100%
Backing up Log files: 100%
Truncating Logs: 100%
Backed up database to C:\ca-yedek.
Database logs successfully truncated.
CertUtil: -backup command completed successfully.

Truncating Logs satırı normaldir: -backup tam bir yedek aldığı için işlenmiş günlükleri kırpar. Kayıt defteri yapılandırması bu komuta dahil değildir, onu ayrı almak gerekir:

reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\ca-yedek\ca-config.reg

Bu dosya AIA ve CDP adreslerini, CRL yayın aralıklarını ve geçerlilik ayarlarını taşır; geri yükleme sonrası bunlar olmadan CA yanlış adresleri basmaya başlar.

İki Farklı Ritim

CA’nın iki parçası farklı hızlarda değişir ve yedekleme takvimi bunu izlemelidir.

Özel anahtar hiç değişmez. Kurulumda üretilir ve CA yenilenene kadar aynı kalır. Bir kez yedeklenir, çevrimdışı güvenli bir yere konur, bir daha dokunulmaz. Onu her gece yedeklemek anlamsızdır; asıl mesele nerede durduğudur.

Veritabanı her verilen sertifikada değişir. Düzenli yedek isteyen kısım budur ve tek başına, özel anahtarı tekrar dışa aktarmadan alınabilir:

certutil -backupDB C:\ca-yedek-db

Anahtarı bir kez güvene aldıktan sonra doğru düzen, -backupDB’yi zamanlanmış bir görevle günlük çalıştırmaktır.

AD CS Kurulumunda Sık Yapılan Hatalar

Bu bölümdeki arızaların ortak özelliği, belirtilerinin sebebi göstermemesidir. Hiçbiri hata mesajı vermez; ya bir seçenek soluk gelir, ya bir liste boş görünür, ya da her şey çalışıyormuş gibi durur.

Enterprise CA Seçeneği Soluk Geliyor

Belirti: Setup Type ekranında yalnız Standalone CA seçilebiliyor, Enterprise CA tıklanamıyor. Sihirbaz sebebini yazmaz.

Sebep: Oturum açan hesap Enterprise Admins üyesi değil. Domain Admins yetkisi bu iş için yetmez, çünkü Enterprise CA kendini ormanın Configuration bölümüne yazar ve orası domain değil orman düzeyinde bir alandır.

Çözüm: Yapılandırmayı Enterprise Admins üyesi bir hesapla yürütün. Bu kurulum boyunca gereken geçici bir yetkidir; Enterprise Admins günlük kullanılan bir hesapta kalıcı olarak durmamalıdır.

Ama asıl tavsiyem şu: bunu sihirbaza girmeden önce kontrol edin. Kendi kurulumumuzda öyle yaptık ve iyi ki yapmışız, çünkü günlük kullandığımız yönetici hesabı yalnız Domain Admins üyesiydi. Bu, ilk bakışta yeterli görünen ama yetmeyen bir yetkidir; sihirbaz da size bunu söylemez, sadece seçeneği soluk gösterir. Üyeliği önceden bilseydiniz otuz saniyelik bir hesap değişikliği olan şey, bilmezseniz sihirbazı iptal edip geri dönmeye ve “acaba neyi yanlış yaptım” diye aramaya dönüşür.

CA Kuruldu Ama Hiçbir Makine Sertifika Almıyor

Belirti: CA konsolu yeşil, servis çalışıyor, ama Issued Certificates klasörü boş kalıyor ve sunucular sertifikasız.

Sebep: Otomatik kayıt henüz tetiklenmemiş. CA’nın var olması ile istemcilerin ondan sertifika alması iki ayrı iştir; arasındaki köprü grup ilkesi yenilemesidir ve kendiliğinden gerçekleşmesi bir buçuk saati bulabilir.

Çözüm: İlgili sunucuda gpupdate /force ve ardından certutil -pulse çalıştırıp beklemeyi kısaltın. Sertifika yine gelmiyorsa şablon yetkilerine bakın: ilgili bilgisayar hesabının ya da grubun şablon üzerinde kayıt yetkisi olmayabilir.

Sertifika Var Ama Listede Görünmüyor

Belirti: Sunucunun sertifika aldığını biliyorsunuz, konsolda listeyi boş görüyorsunuz.

Sebep: Yanlış depoya bakılıyor. Sunucu ve domain controller sertifikaları bilgisayar deposunda durur; certmgr.msc ise oturum açan kullanıcının deposunu açar.

Çözüm: certlm.msc açıp Personal → Certificates dalına bakın.

Sertifikalar Yanlış İptal Listesi Adresini Taşıyor

Belirti: Sertifikalar geçerli görünüyor ama bazı istemcilerde doğrulama takılıyor, özellikle ofis dışındakilerde.

Sebep: CDP adresi ilk sertifikalar basıldıktan sonra düzeltilmiş. Extensions sekmesindeki değişiklik yalnız yeni sertifikaları etkiler.

Çözüm: Adresi düzeltin, sonra yanlış adresle çıkmış sertifikaları yeniden bastırın. Bu arızanın tek gerçek çözümü budur; başka bir kestirme yolu yok.

Yanlışlıkla Standalone CA Kuruldu

Belirti: CA çalışıyor ama Active Directory tarafında hiçbir iz yok: şablon listesi boş, otomatik kayıt hiç devreye girmiyor, istemciler CA’yı bulamıyor.

Sebep: Setup Type ekranında Standalone CA seçilmiş. Standalone CA dizine hiçbir şey yazmaz.

Çözüm: Bu, ayarla düzeltilebilecek bir durum değil. CA kaldırılıp Enterprise olarak yeniden kurulur. Kontrol etmenin en hızlı yolu, doğrulama bölümündeki Enrollment Services sorgusudur: konteyner boşsa dizinle bağ hiç kurulmamıştır.

Kurulumdan Sonra Sunucu Yeniden Adlandırıldı

Belirti: Bir gün önce çalışan sertifikalar toptan geçersiz.

Sebep: AD CS kurulduktan sonra bilgisayar adının değişmesi, o CA’nın bastığı bütün sertifikaları geçersiz kılar.

Çözüm: Geri dönüş pahalıdır: CA kaldırılır, makine eski adına döndürülür ya da CA aynı anahtarlarla yeniden kurulup kayıt defteri elle düzeltilir. Bu yüzden ad ve IP kurulumdan önce kesinleştirilir, ve CA adı ve rolü değişebilecek makinelere, özellikle domain controller’lara kurulmaz.

Sertifika Şablonu: Hangi Şablon, Hangi İzin

CA’dan sertifika basılmadan önce hangi şablonun kullanılacağına karar verilir. Şablon, sertifikanın ne kadar süreceğini, hangi amaç için geçerli olduğunu ve kimin talep edebileceğini belirler. Şablonlar Certificate Templates Console (certtmpl.msc) üzerinden yönetilir.

Kutudan gelen şablonlar iş görür ama doğrudan kullanılmaz. Nedeni üçüncü maddede saklı: kimin talep edebileceği. Sertifika almaya çalıştığınızda karşınıza çıkan retlerin büyük kısmı buradan gelir ve hata mesajı bunu size söylemez.

Lab’da Yaşadığımız Ders: Talep Eden Kim?

Web sunucumuza sertifika bastırırken sırayla üç yol denedik ve ikisi reddedildi. Sıra önemli, çünkü her ret bir öncekinden başka bir sebeple geldi.

Birinci deneme, IIS’in kendi sihirbazı. Create Domain Certificate sertifikayı sorunsuz bastırdı. Ama tarayıcı siteyi açmayı reddetti:

ERR_CERT_COMMON_NAME_INVALID

Bu bir güven hatası değil, isim hatasıdır. İç CA’ya zaten güveniliyordu; sorun sertifikanın SAN (Subject Alternative Name) alanının boş olmasıydı. Tarayıcılar adı CN alanından okumayı yıllar önce bıraktı. SAN yoksa sertifika teknik olarak geçerli, pratikte kullanılamaz olur.

İkinci deneme, certlm.msc ve Get-Certificate. SAN’lı talep için bu araçları denedik, ikisi de reddedildi. Sebebi ancak şablonun izin listesi okununca anlaşıldı: bu araçlar talebi makine hesabıyla gönderiyor, kullandığımız şablon ise Enroll iznini yalnız yönetici gruplarına vermişti. Makine hesabı o listede yoktu.

Asıl ders şudur: şablon izni bir kullanıcı listesi değil, talebi hangi kimliğin gönderebileceğinin listesidir. Aracı değiştirmek yetmez; talebi kimin gönderdiğini bilmeniz gerekir.

Kendi Şablonunuzu Kopyalayarak Açın

Yerleşik şablonu doğrudan düzenlemeyin, kopyalayın; kutudan gelenler güncellemelerle değişebilir.

1. certtmpl.msc konsolunda ilgili şablona sağ tıklayıp Duplicate Template seçin.
2. General sekmesinde ayırt edici bir ad ve makul bir geçerlilik süresi verin.
3. Security sekmesinde sertifikayı talep edecek kimliğe Enroll izni verin. Sunucular kendi adına talep edecekse bu izin bilgisayar grubuna gider, yöneticiye değil.
4. Subject Name sekmesinde Supply in the request seçeneğini işaretleyin; SAN’ı talebin kendisi taşıyacaksa bu şarttır.
5. Şablonu yayına almayı unutmayın: CA konsolunda Certificate Templates → New → Certificate Template to Issue. Bu adım atlanırsa şablon var olur ama CA onu tanımaz.

Otomatik Kayıt Domain Üyelerine Ulaşır, Diğerlerine Ulaşmaz

Şablon hazır. Sıra sertifikanın makinelere nasıl ulaşacağında, ve burada yol ikiye ayrılıyor.

Domain üyesi makinelerde iş kendiliğinden yürür. Otomatik kayıt (autoenrollment) grup ilkesiyle açılır; makine domain’e giriş yaptığında CA’ya kendi kimliğiyle başvurur, şablonda Enroll ve Autoenroll izni varsa sertifikayı alır ve süresi dolmadan kendisi yeniler. Yönetici hiçbir şey yapmaz.

Bu zincirin çalışmasının tek sebebi şudur: makine zaten domain’de kimliği olan bir nesnedir. CA onu tanır, Kerberos ile doğrular, izin listesinde arar.

Domain dışı makinede bu zincirin ilk halkası yoktur. Bir Linux sunucu, DMZ’deki bir web sunucusu ya da bir ağ cihazı domain üyesi değilse:

• Grup ilkesi ona ulaşmaz, dolayısıyla otomatik kayıt hiç tetiklenmez.
• CA’ya kendini tanıtacağı bir makine hesabı yoktur.
• Sertifikanın süresi dolduğunda kimse yenilemez; süre dolumu sessizce gelir.

Sonuç şudur: domain dışı her makinede sertifika elle alınır ve elle yenilenir. Bu bir eksiklik değil, mimarinin doğal sınırı. Ama bilinmeden kurulan altyapılarda iki yıl sonra aynı hafta içinde çöken servisler olarak geri döner.

Domain Dışı Sunucuya Sertifika: certreq ile Talep Göndermek

Otomatik kaydın ulaşmadığı makineye sertifikayı elle taşıyacağız. Akış üç adım ve makine domain dışında olsa da CA yine sizin AD CS’iniz kalır:

1. Sunucuda bir anahtar çifti ve ona bağlı bir talep dosyası (CSR) üretilir.
2. Talep, domain üyesi bir makineden CA’ya gönderilir ve imzalanır.
3. İmzalı sertifika ile kök zinciri sunucuya geri taşınır, servise bağlanır.

Üç adımın en kritik yanı ikinci maddede: özel anahtar hiçbir zaman sunucudan çıkmaz. Taşınan şey yalnız talep dosyası ve imzalı sertifikadır; ikisi de gizli değildir.

Talebi Tanımlayan INF Dosyası

Windows tarafında talebi bir metin dosyası tanımlar. SAN’ı buraya yazmak zorundasınız, çünkü GUI sihirbazı onu boş bırakıyor:

[NewRequest]
Subject = "CN=portal.ad.sercebilisim.com"
KeyLength = 2048
KeyAlgorithm = RSA
MachineKeySet = TRUE
Exportable = TRUE
RequestType = PKCS10

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=portal.ad.sercebilisim.com&"

İki satır kararı taşıyor. MachineKeySet = TRUE, anahtarın kullanıcı deposuna değil makine deposuna yazılmasını sağlar; IIS ve benzeri servisler sertifikayı ancak orada görür. 2.5.29.17 ise SAN uzantısının nesne tanımlayıcısıdır ve bu blok olmadan yukarıdaki isim hatasına geri dönersiniz.

Talebi Gönderin

certreq -new istek.inf istek.req
certreq -submit -attrib "CertificateTemplate:SunucuSertifikasi" istek.req sertifika.cer
certreq -accept sertifika.cer

Bizim kurulumumuzda çalışan yol tam olarak buydu, ve talebi gönderen kimliğin önemi burada ortaya çıktı: komutu makine hesabıyla değil, şablonda Enroll iznine sahip bir yönetici hesabıyla çalıştırdık. Basılan sertifika iç kök CA tarafından imzalandı, SAN alanı doluydu ve tarayıcı siteyi itiraz etmeden açtı.

Linux Sunucular İçin Aynı Akış

Linux tarafında değişen tek şey talebin nasıl üretildiğidir; gerisi aynı kalır. Aşağıdaki adımları domain üyesi olmayan bir Ubuntu sunucuda çalıştırdık ve sertifikayı kendi iç CA’mıza imzalattık.

Anahtar ve talep openssl ile üretilir. SAN’ı burada da elle vermek zorundasınız:

openssl req -newkey rsa:2048 -nodes \
  -keyout sercesyslog.key -out sercesyslog.csr \
  -subj "/CN=sercesyslog.ad.sercebilisim.com" \
  -addext "subjectAltName=DNS:sercesyslog.ad.sercebilisim.com,DNS:sercesyslog,IP:192.168.1.46"

Göndermeden önce talebin gerçekten istediğiniz şeyi taşıdığını doğrulayın; SAN’ın içeri girmediğini CA’dan sertifika döndükten sonra fark etmek pahalıdır:

openssl req -in sercesyslog.csr -noout -verify
openssl req -in sercesyslog.csr -noout -text | grep -A1 "Subject Alternative Name"

Certificate request self-signature verify OK
            X509v3 Subject Alternative Name:
                DNS:sercesyslog.ad.sercebilisim.com, DNS:sercesyslog, IP Address:192.168.1.46

Buradan sonrası Türkçe kaynakların bittiği yer. Ürettiğiniz .csr dosyası tek başına bir işe yaramaz ve Linux makine domain’de olmadığı için CA’ya kendisi başvuramaz. Dosyayı domain üyesi bir Windows makineye taşıyıp talebi oradan gönderirsiniz. Uzaktaki bir CA’ya göndermek için -config parametresi kullanılır:

certreq -submit -config "ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA" -attrib "CertificateTemplate:WebServer" sercesyslog.csr sercesyslog.cer

RequestId: 7
Certificate retrieved(Issued) Issued

Issued kelimesi sertifikanın basıldığını söyler. Şablonda onay şartı tanımlıysa bunun yerine Taken Under Submission görürsünüz; o durumda talep sırada bekler ve CA konsolundan onaylanana kadar sertifika üretilmez.

Dönen dosyayı ve kök sertifikayı Linux sunucuya geri taşıdıktan sonra iki şeyi doğrulayın. Birincisi sertifikanın gerçekten sizin anahtarınıza ait olduğu; ikisinin genel anahtar modülü aynı çıkmalıdır:

openssl x509 -in sercesyslog.cer -noout -modulus | openssl md5
openssl rsa  -in sercesyslog.key -noout -modulus | openssl md5

MD5(stdin)= 0a0f9ba7b77fef6f38f1db53fb8cecda
MD5(stdin)= 0a0f9ba7b77fef6f38f1db53fb8cecda

İkincisi zincirin kapandığı, yani sertifikanın gerçekten o kök tarafından imzalandığı:

openssl verify -CAfile kok-ca.cer sercesyslog.cer

sercesyslog.cer: OK

Son olarak sertifikanın içine bakın. Aradığınız üç şey var: SAN korunmuş mu, veren doğru CA mı, ve kullanım amacı sunucu kimliği mi?

subject=CN = sercesyslog.ad.sercebilisim.com
issuer=DC = com, DC = sercebilisim, DC = ad, CN = SerceBilisim-Lab-Root-CA
notBefore=Aug 19 02:23:23 2026 GMT
notAfter=Aug 18 02:23:23 2028 GMT
            X509v3 Subject Alternative Name:
                DNS:sercesyslog.ad.sercebilisim.com, DNS:sercesyslog, IP Address:192.168.1.46
            X509v3 Extended Key Usage:
                TLS Web Server Authentication

Üçü de yerinde. Artık sertifikayı servise bağlayabilirsiniz; Apache tarafında üç satır yeter:

SSLCertificateFile      /etc/ssl/certs/sercesyslog.cer
SSLCertificateKeyFile   /etc/ssl/private/sercesyslog.key
SSLCACertificateFile    /etc/ssl/certs/kok-ca.cer

Küçük bir ortamda AD CS yerine Linux üzerinde kendi otoritenizi kurmak da mümkündür; bunun openssl ile en kısa hâlini syslog sunucusu rehberimizin TLS bölümünde ölçümle gösterdik. Kurumsal ölçekte bir Linux CA ise iptal listesi, ara CA ve yenileme düzeniyle birlikte ayrı bir konudur.

Sonuç: Kurulum Bitti, Asıl İş Şimdi Başlıyor

CA’nın ayakta olması, ondan faydalanıldığı anlamına gelmez. Yukarıda kurulumdan sonraki üç adımı da ele aldık: şablonun kopyalanıp yayına alınması, otomatik kaydın domain üyelerinde işleyip diğerlerinde işlememesi, ve domain dışı bir sunucuya certreq ile elle sertifika taşınması.

Bu üç adımın ortak dersi tek cümlede toplanıyor: CA bir sertifika üretecidir, dağıtım mekanizması değildir. Domain üyeleri için dağıtımı grup ilkesi yapar; onun dışında kalan her makinede dağıtım da yenileme de sizin işinizdir.

Sertifikanın hangi mekanizmayla doğrulandığını, güven zincirinin nasıl kurulduğunu ve sertifika arızalarının neden ağ sorunu gibi göründüğünü sertifika otoritesi rehberimizde ele aldık.

Bu yapının sahada ne işe yaradığını görmek isterseniz, on üç lokasyonlu bir kurumda switch ve kablosuz ağ erişimini kişisel hesaplara bağlarken kurduğumuz sertifika sunucusunu ağ erişim kontrolü projemizde anlattık.

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.