Makale Hakkında
Önceki yazılarımdan birinde Offline Root CA migration işlemlerini anlatmıştık. Bu yazımızda da Enterprise Subordinate CA rolümüzü taşıma işlemini ele alıyor olacağız. Aslında adımları benzer hatta hemen hemen aynı olsa da, SubCA taşırken yapılacak bir hatanın, VPN bağlantılarının kopmasına, iç web sitelerinin “güvensiz” uyarısı vermesine ve binlerce kullanıcının domain login sorunları yaşamasına neden olabileceğinin farkında olmak gerekiyor. Önceki yazıda da belirttiğimiz gibi Offline Root CA taşımak işin “cerrahi” kısmıydı. Ancak Subordinate (Issuing) CA taşımak asıl “canlı bomba” operasyonudur.
Çünkü Root genelde uykudadır, ama Subordinate her an sertifika basar, CRL (Sertifika İptal Listesi) yayınlar ve tüm network ile konuşur. Bu sebepledir ki, AD ortamındaki Subordinate (Issuing) CA sunucusunu yeni bir sunucuya taşımak, planlama yapılmadan girişildiğinde PKI altyapısını çökertebilecek kritik bir operasyondur. Bu yazıda terminolojiden adım adım göç prosedürüne, dikkat edilmesi gereken noktalara ve ileri seviye senaryolara kadar her şeyi ele alıyoruz..
Bu rehber Windows Server 2016, 2019, 2022 ve 2025 üzerindeki Enterprise CA’lar için geçerlidir. Microsoft Learn resmi dokümantasyonu temel alınmıştır.
Genel Bakış
CA migration, mevcut Sertifika Yetkilisini bir sunucudan diğerine, PKI altyapısını bozmadan taşıma işlemidir. Microsoft’un resmi yaklaşımına göre bu işlemde CA adı hiçbir koşulda değişmez; genelde de kaynak ve hedef sunucular aynı bilgisayar adını paylaşır. Bu nedenle süreç sırasında kaynak sunucu önce domain’den çıkarılır, hedef sunucu kaynak sunucunun adını alarak domain’e katılır. Fakat sunucu ismini de değiştirebilirsiniz. Anlatımı aynı sunucu ismi vererek yapacağım. Fakat CA sunucu ismini farklı vereceğim. Bu sayade aslında bir fark olmadığını sadece bir ayar daha eklemeniz gerektiğini göreceğiz.
Migration boyunca CA sertifika veremez ve CRL yayınlayamaz. Bu nedenle migration başlamadan önce geçerlilik süresi uzatılmış bir CRL yayınlanması kritik önemdedir.
Önemli: Bu işleme başlamadan önce mutlaka test ortamında prova yapın. Üretim ortamında hata yapıldığında geri dönüş süreleri kritik olabilir.Terminoloji
Migration sürecini anlamak için aşağıdaki kavramlara hâkim olmak gerekmektedir:
%systemroot%\system32\CertLog altındaki .edb/.log dosyaları.Local Machine\My (CA private key + cert) ve Local Machine\CA (zincir sertifikaları) depoları kritiktir.PKI Mimarisi & Migration Senaryosu
Tipik iki katmanlı PKI ortamında göç senaryosunun görsel temsili ve hangi bileşenlerin etkileneceği:
İki Katmanlı PKI — Migration Senaryosu
OFFLINE
DECOMMISSION
Taşınıyor
YENİ SUNUCU
Aynı İsim Stratejisi: Migration’da CA adının aynı tutulması (CORP-SubCA), mevcut sertifikalardaki Issuer bilgisini geçersiz kılmaz. Bu sayede yüzlerce/binlerce mevcut sertifika otomatik olarak yeni CA tarafından doğrulanmaya devam eder.Önkoşullar
- Hem kaynak hem hedef sunucuda yerel Administrators yetkisi; Enterprise CA için Enterprise Admins veya Domain Admins grup üyeliği
- Yedek dosyaları saklamak için güvenli ve her iki sunucudan erişilebilir bir konum (ağ paylaşımı veya taşınabilir medya)
- Certutil, PowerShell (ADCS modülü) ve Certification Authority snap-in araçlarına erişim
LAB Ortamı
Lab ortamında toplam 4 adet sunucu vardır. Sahip oldukları ip adresleri ve roller :
| Operating System | Role | CIDR | |
| DC01 | Server 2022 Standard | Active Directory, DNS | 172.17.15.11/24 |
| DC02 | Server 2022 Standard | Active Directory, DNS | 172.17.15.21/24 |
| CA01 | Server 2022 Standard | Certification Authority | 172.17.15.12/24 |
| CA02 | Server 2025 Standard | Certification Authority | 172.17.15.22/24 |
Migration Akışı
Migration altı ana fazdan oluşur. Sıraya uymak kritiktir — özellikle kaynak sunucudan rol kaldırılmadan hedef sunucuya kurulum yapılmamalıdır.
* İlgili adım detayına gitmek için adım başlığına tıklayabilirsiniz
Kaynak sunucudan AD CS rolü kaldırılmadan hedef sunucuya kurulum yapılmamalıdır. Her ikisi de aynı CA adıyla aynı anda aktif olursa AD DS’deki CA yapılandırma verileri bozulur.
Yedekleme (Kaynak Sunucu)
Yedekleme işlemi kaynak CA üzerinde gerçekleştirilir. Tüm dosyalar aynı konuma kaydedilmeli ve hedef sunucudan erişilebilir olmalıdır.
CA Veritabanı ve Private Key — 3 Yöntem
# Veritabanı + private key tek komutla yedeklenir
Backup-CARoleService -Path “C:\CABackup”
# Yedek tamamlandıktan sonra servisi durdur
Stop-Service -Name “certsvc”
# Doğrulama: bu dosyalar oluşmalı
# C:\CABackup\CORP-SubCA.p12 — sertifika + private key
# C:\CABackup\Database\ — certbkxp.dat, edb####.log, CORP-SubCA.edb
certutil -backupdb C:\CABackup
# Private key’i yedekle (parola girilmesi istenir — kaydedin)
certutil -backupkey C:\CABackup
# Servisi durdur
net stop certsvc
# CA adına sağ tık → All Tasks → Back Up CA
# İşaretleyin: “Private key and CA certificate”
# “Certificate database and certificate database log”
# Yedek konumunu belirleyin, parola girin, Finish
# Yedek sonrası manuel olarak servisi durdurun:
net stop certsvc
LAB – CA Veritabanı ve Private Key
Örnek olması açısından iki komutla da yedek alındı.
LIVE_VIEW: LAB_ENVIRONMENT
Registry Ayarlarını Yedekle
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\CABackup\CASrcReg.reg
# Yöntem B: Regedit ile
# regedit → HKLM\SYSTEM\CurrentControlSet\Services\CertSvc
# “Configuration” üzerine sağ tık → Export → C:\CABackup\CASrcReg.reg
LAB – Registry Ayarlarını Yedekle
LIVE_VIEW: LAB_ENVIRONMENT
CAPolicy.inf ve Sertifika Şablonları
copy C:\Windows\CAPolicy.inf C:\CABackup\CAPolicy.inf
# Enterprise CA için şablon listesini kaydet
certutil -catemplates > C:\CABackup\catemplates.txt
# Not: Şablon listesi CA veritabanında saklanmaz;
# AD DS’de tutulur. Ayrıca not alınması zorunludur.
LAB – CAPolicy.inf ve Sertifika Şablonları
Benim ortamımda herhangi bir CAPolicy.inf dosyası bulunmamakta. Template olarak default dışı 3 sertifika olduğu görülmekte. Migrate sonrası bu sertifikaları yeni sunucumuzda da issue edebilmemiz gerekiyor.
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
Uzatılmış CRL Yayınlama
Migration süresince CA çevrimdışı olacaktır. Bu süreçte client’ların sertifika doğrulaması yapabilmesi için geçerlilik süresi migration süresini aşacak bir CRL önceden yayınlanmalıdır.
certutil -getreg CA\CRLPeriodUnits
certutil -getreg CA\CRLPeriod
# Geçerlilik süresini migration için uzat (örnek: 4 hafta)
certutil -setreg CA\CRLPeriodUnits 4
certutil -setreg CA\CRLPeriod “Weeks”
# Servisi yeniden başlat ve CRL yayınla
net stop certsvc && net start certsvc
certutil -crl
# Migration tamamlandıktan sonra orijinal değerlere döndürmeyi unutmayın
LAB – Uzatılmış CRL Yayınlama
Yukarıdakş komutlarla yapabilecğiniz gibi GUI üzerinden de aşağıdaki gibi yapabilirsiniz. Benim sunucumda hali hazırda 4 hafta olduğundan herhangi bir değişiklik yapmıyorum.
LIVE_VIEW: LAB_ENVIRONMENT
 |
 |
Varsayılan olarak CRL geçerlilik süresi = yayınlama periyodu + %10’dur. Aşırı uzun süreli CRL ayarlamayın: client’lar önbelleklerindeki CRL süresi dolmadan yeni CRL indirmez.
Kaynak Sunucudan AD CS Rolünü Kaldırma
Yedekleme ve CRL yayınlama tamamlandıktan sonra, hedef sunucuya kurulum yapılmadan önce kaynak sunucudan AD CS rolü kaldırılmalıdır.
Rol kaldırıldığında CA veritabanı, private key ve sertifika silinmez. Migration başarısız olursa kaynağa rol yeniden yüklenerek geri dönüş yapılabilir.
# Server Roles → Active Directory Certificate Services
# “Certification Authority” kutusunu temizle
# Confirmation sayfasına kadar ilerle → Remove
# Başarılı kaldırma mesajını doğrula
Komut Çalıştırmasında HataEğer ortamınızda Web Enrollment Role Servisi yüklü ise yukarıdaki Uninstall-WindowsFeature komutunda hata alacaksınız. Öncelikle Web-Enrollment Role Servisi kaldırmanız gerekmektedir.
LAB – AD CS Rolünü Kaldır
Benim ortamımda web enrollment olduğundan dolayı hata aldım. Önce o rol servisi kaldırdıktan sonra ADCS rolünü kaldırdım.
LIVE_VIEW: LAB_ENVIRONMENT
Kaynak Sunucuyu Domain’den Çıkar +
Hedefi Yeniden Adlandır
AD’de bilgisayar adları benzersiz olmak zorundadır. Hedef sunucu kaynak sunucunun adını alacağı için önce kaynak sunucu domain’den çıkarılmalı ve bilgisayar hesabı silinmelidir.
Remove-ADComputer -Identity “CORP-SUBCA01”
# Veya ADUC → Computers → Hesaba sağ tık → Delete
Rename-Computer -NewName “CORP-SUBCA01” -Restart
# Yeniden başlama sonrası domain’e katıştır
Add-Computer -DomainName “emre.local” -Restart
LAB – Kaynak Sunucuyu Domain’den Çıkar
LIVE_VIEW: LAB_ENVIRONMENT
Bu adımda yeni sunucunuzu eski sunucunun aynı ismiyle domaine alabilirsiniz. Ben farklı bir isim ile domaine alıyorum. Amaç : Bu değişik için nerede müdahele etmemiz gerektiğini göstermek.
LIVE_VIEW: LAB_ENVIRONMENT
CA Sertifikasını Import Et ve AD CS Rol Kur
Hedef sunucuda rol kurulumu öncesinde, yedeklenen .p12 dosyasından CA sertifikası Local Computer Personal deposuna import edilir. Ardından rol kurulumu sırasında mevcut sertifika ve private key kullanılarak kurulum yapılır — yeni sertifika oluşturulmamalıdır.
CA Sertifikasını Import Et
# Personal → All Tasks → Import
# Yedekten CORP-SubCA.p12 dosyasını seç, parolayı gir
# “Place all certificates in the following store: Personal”
# Finish ile tamamla
# İsteğe bağlı: import sonrası private key bağlantısını onar
certutil -repairstore My “<SertifikaninSeriNumarasi>”
Kaynak CA’dan aldığınız
CAPolicy.inf dosyasını AD CS rolü kurulmadan önce hedef sunucunun C:\Windows\ klasörüne kopyalayın. Rol kurulumu bu dosyayı okur.LAB – Kaynak Sunucuyu Domain’den Çıkar
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
RootCA CertificateEğer RootCA sertifikası group policy ile dağıtılmıyorsa, RootCA setrifikasını
Trusted Root Authorities store’una yüklemeyi unutmayın. AD CS Rolü Kurulumu — PowerShell
Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools
# Mevcut sertifika ile yapılandır (seri numarası veya thumbprint ile)
# Sertifika thumbprint’ini bul:
Get-ChildItem “Cert:\LocalMachine\My” | Where-Object { $_.Subject -like “*CORP-SubCA*” }
# Enterprise Subordinate CA olarak yapılandır
Install-AdcsCertificationAuthority `
-CAType EnterpriseSubordinateCA `
-CertificateID “<Thumbprint veya SeriNumarasi>” `
-Credential (Get-Credential “
-Force
LAB – AD CS Rolü Kurulumu
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
AD CS Rolü Kurulumu — GUI (Server Manager)
# 2. Active Directory Certificate Services → Next
# 3. Role Services: yalnızca “Certification Authority” seç → Next
# 4. Setup Type: Enterprise (kaynakla aynı)
# 5. CA Type: Subordinate CA (kaynakla aynı)
# 6. Set Up Private Key: “Use existing private key”
# → “Select a certificate and use its associated private key”
# 7. Certificates listesinden import edilen CA sertifikasını seç
# 8. CA Database: veritabanı ve log konumlarını belirle → Configure
CA Geri Yükleme — Veritabanı
AD CS rolü kurulduktan sonra kaynak CA veritabanı hedef sunucuya geri yüklenir.
Geri yükleme sırasında
Database klasörünü değil, üst klasörü seçin. Örneğin: yedek C:\CABackup\Database\ altındaysa C:\CABackup seçilmelidir.Stop-Service -Name “certsvc”
# Sadece veritabanını geri yükle (-DatabaseOnly)
# -Force: rol kurulumu sırasında oluşan boş DB’nin üzerine yazar
Restore-CARoleService -Path “C:\CARestore” -DatabaseOnly -Force
# Servisi başlat
Start-Service -Name “certsvc”
net stop certsvc
# Veritabanını geri yükle (-f: mevcut boş DB üzerine yaz)
certutil -f -restoredb “C:\CARestore”
# Servisi başlat
net start certsvc
# “Certificate database and certificate database log” seç
# Browse ile Database klasörünün ÜST klasörünü seç
# Next → Finish → Yes (servis başlatılsın)
LAB – AD CS Rolü Kurulumu
Ben lab ortamımda ilk yöntemi kullandım. Siz istediğinizi tercih edebilirsiniz.
LIVE_VIEW: LAB_ENVIRONMENT
Registry Ayarlarını Geri Yükle ve Düzenle
CA yapılandırma bilgileri HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration altında tutulur. Kaynak CA registry dosyası doğrudan import edilmemelidir; önce metin editörüyle incelenip gerekliyse düzenlenmelidir.
Hedef CA’nın mevcut registry’sini yedekle
Import öncesinde hedef CA’nın varsayılan registry yapılandırmasını ayrı bir dosyaya dışa aktarın (örnek: TargetRegDefault.reg). Hata durumunda geri dönüş imkanı sağlar.
Kaynak registry dosyasını metin editörüyle incele
Sunucu adı, dosya yolları ve sürücü harfleri gibi değerleri kontrol et. Kaynak ve hedef sunucunun adı farklıysa CAServerName, RequestFileName, WebClientCAMachine değerlerini güncelle.
LAB – Registry Ayarlarını Geri Yükle ve Düzenle
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
Registry dosyasını import et
Servisi durdur, registry’yi import et: net stop certsvc ardından reg import CASrcReg.reg
# Registry’yi import et
reg import “C:\CARestore\CASrcReg.reg”
# DBSessionCount değeri hex 64 (=100 decimal) olarak set edilmemişse bu değere ayarla. Bu değer, CA hizmeti için izin verilen eş zamanlı veritabanı oturumlarının maksimum sayısını belirler.
reg add HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration /v DBSessionCount /t REG_DWORD /d 0x64 /f
# Hedef sunucu adı farklıysa CAServerName güncelle:
# regedit → …CertSvc\Configuration\<CA-Adi> → CAServerName → yeni sunucu adı
net start certsvc
LAB – Registry dosyasını import et
LIVE_VIEW: LAB_ENVIRONMENT
CRL Dağıtım Noktası ve AIA Uzantılarını Doğrula
Registry ayarları geri yüklendikten sonra CDP (CRL Distribution Point) ve AIA (Authority Information Access) uzantılarını kontrol edin. Kaynak sunucu adı ile hedef sunucu adı farklıysa bu uzantılardaki eski yollar güncellenmeli; daha önce verilmiş sertifikaların yolları hâlâ geçerli kalacak şekilde eski yol da korunmalıdır.
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
# GUI ile düzenleme:
# certsrv.msc → CA adına sağ tık → Properties
# → “Extensions” sekmesi → CDP / AIA uzantılarını incele
# Gerekirse eski yolu “Include in CRLs” seçili bırakarak koru
Kaynak ve hedef sunucunun adı aynıysa (önerilen senaryo) ya da DNS name kullanıldıysa CDP/AIA uzantılarında değişiklik gerekmez.
Certificate Templates Listesini Geri Yükle
Sertifika şablonları ve bunların CA’ya atanması AD DS’de saklanır — CA veritabanında veya registry’de bulunmaz. Bu nedenle migration öncesinde not alınan şablon listesi hedef CA’ya ayrıca eklenmek zorundadır.
# → New → Certificate Template to Issue
# Yedeklenen catemplates.txt dosyasına göre aynı şablonları ekle
LAB – Certificate Templates Listesini Geri Yükle
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
certutil -catemplates
LAB – Certificate Templates Listesini Geri Yükle
LIVE_VIEW: LAB_ENVIRONMENT
Doğrulama
Get-Service -Name “certsvc”
# CA sertifikası ve zincir doğrulama
certutil -verify -urlfetch “C:\CARestore\CORP-SubCA.cer”
# CRL erişimini doğrula
certutil -URL “C:\CARestore\CORP-SubCA.cer”
# Yeni sertifika talebi (enrollment) testi — client üzerinden
certreq -enroll -machine “WebServer”
certutil -dspublish -f “C:\CARestore\CORP-SubCA.cer” SubCA
# Enrollment service erişim testi (IIS üzerinden)
# https://CORP-SUBCA01/certsrv adresini tarayıcıda kontrol et
LAB – CA Servis Durumu ve Sertifika Zinciri Doğrulama
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
Sertifikalarımızda ve Enterprise PKI konsulumuzda sonn bir kontrol yapalım.
LIVE_VIEW: LAB_ENVIRONMENT
LIVE_VIEW: LAB_ENVIRONMENT
Doğrulamalar başarılıysa kaynak sunucuya ilişkin geçici düzenlemeleri geri alın: CRL yayınlama periyodunu eski değerine döndürün, ardından yeni CRL yayınlayın. Migration işlemi başarıyla tamamlanmıştır.
Faydalı olması dileğiyle…
Aşağıdaki linkler de ilginizi çekebilir.
