SSL Sertifika Türleri: Domain Validation (DV) Sertifikaları Rehberi

yazar

Kurumsal ortamlarda SSL sertifika yönetimi, sysadmin’lerin günlük hayatının kaçınılmaz bir parçası. Active Directory altyapısı üzerinde çalışırken, web servisleri yayınlarken veya iç ağdaki uygulamaları HTTPS üzerinden sunarken mutlaka SSL sertifika türleriyle yüzleşiyorsunuz. Bu yazıda özellikle DV (Domain Validation) sertifikalarına odaklanacağız. Neyi kapsar, nerede kullanılır, Windows Server ortamında nasıl yönetilir, bunları adım adım ele alacağız.

DV Sertifikası Nedir?

Domain Validation (DV) sertifikaları, SSL sertifika hiyerarşisinin en temel katmanını oluşturur. Sertifika otoritesi (CA), yalnızca başvuran kişinin söz konusu domain üzerinde kontrol sahibi olduğunu doğrular. Şirketin varlığı, kimliği, fiziksel adresi gibi bilgiler doğrulanmaz. Bu nedenle DV sertifikaları dakikalar içinde düzenlenebilir.

Peki bu “domain kontrolü” nasıl kanıtlanır? Üç yöntem yaygın olarak kullanılır:

  • DNS doğrulama: CA’nın verdiği bir TXT veya CNAME kaydını DNS zone’unuza ekliyorsunuz.
  • HTTP doğrulama: CA’nın belirlediği bir dosyayı belirli bir URL path’ine koyuyorsunuz.
  • E-posta doğrulama: Domain’e ait admin@, webmaster@ gibi standart adreslere gelen onay mailini tıklıyorsunuz.

Windows Server ortamında, özellikle Active Directory ile yönetilen domain yapılarında DV sertifikalarını hem iç hizmetler hem de dışarıya açık servisler için kullanabilirsiniz. Ancak dikkat edilmesi gereken bazı kritik noktalar var.

DV Sertifikasının Kapsadığı Alanlar

DV sertifikaları üç farklı formda gelebilir:

  • Single Domain: Yalnızca tek bir FQDN’i kapsar. Örneğin sadece www.sirketiniz.com
  • Wildcard DV: *.sirketiniz.com şeklinde bir seviye alt domainleri kapsar. mail.sirketiniz.com, vpn.sirketiniz.com gibi.
  • Multi-Domain / SAN DV: Subject Alternative Name alanlarıyla birden fazla farklı domain adını tek sertifikada toplar.

Active Directory ortamında özellikle Wildcard DV sertifikaları çok işe yarar. Tek bir sertifikayla hem RD Gateway, hem Web Application Proxy, hem de ADFS sunucunuzu kapatabilirsiniz.

Windows Server’da Mevcut Sertifikaları Kontrol Etme

Ortama yeni dahil olan bir sysadmin olarak ilk yapmanız gereken şey, sunuculardaki mevcut sertifikaları envanterlemektir. PowerShell ile bunu hızlıca yapabilirsiniz.

# Yerel makinedeki tüm sertifikaları listele
Get-ChildItem -Path Cert:LocalMachineMy | Select-Object Subject, NotAfter, Thumbprint, Issuer

Eğer uzak sunuculardaki sertifikaları da görmek istiyorsanız:

# Uzak sunucudaki sertifikaları sorgula
Invoke-Command -ComputerName "WEBSERVER01" -ScriptBlock {
    Get-ChildItem -Path Cert:LocalMachineMy | 
    Select-Object Subject, NotAfter, Thumbprint, DnsNameList |
    Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) }
}

Bu komut özellikle kritik. Son 30 gün içinde sona erecek sertifikaları filtreler. Sabah monitoring rutinlerinize bu sorguyu ekleyin.

Let’s Encrypt ile Ücretsiz DV Sertifikası Alma

Let’s Encrypt, bugün itibarıyla en yaygın kullanılan ücretsiz DV CA’sı konumunda. Windows Server üzerinde win-acme (eski adıyla wacs) aracıyla Let’s Encrypt entegrasyonu çok kolaylaşmış durumda.

Önce win-acme’yi indirip yapılandıralım:

# win-acme'yi PowerShell ile indir
$url = "https://github.com/win-acme/win-acme/releases/latest/download/win-acme.v2.2.9.1701.x64.pluggable.zip"
Invoke-WebRequest -Uri $url -OutFile "C:Toolswin-acme.zip"
Expand-Archive -Path "C:Toolswin-acme.zip" -DestinationPath "C:Toolswin-acme"

Şimdi interaktif modda sertifika alalım:

# win-acme'yi interaktif modda başlat
cd C:Toolswin-acme
.wacs.exe

Eğer IIS üzerinde barındırılan bir site için tamamen otomatik sertifika almak istiyorsanız:

# IIS sitesi için otomatik DV sertifikası al ve bağla
.wacs.exe --target iis --siteid 1 --installation iis --certificatestore My --acl-fullcontrol "network service,administrators"

Bu komut şunları yapar: IIS site ID 1’i hedef alır, HTTP challenge için gerekli dosyayı otomatik oluşturur, sertifikayı alır ve IIS binding’e bağlar.

DNS Challenge ile DV Sertifikası Alma

Eğer sunucunuz internet üzerinden erişilebilir değilse (iç ağdaki bir AD FS sunucusu gibi), HTTP challenge çalışmaz. Bu durumda DNS challenge kullanmanız gerekir. Cloudflare DNS kullanıyorsanız bu işlem oldukça kolaylaşır.

# Cloudflare DNS plugin ile sertifika alma
.wacs.exe --target manual --host vpn.sirketiniz.com,adfs.sirketiniz.com `
  --validation dns-01 `
  --validationplugin cloudflare `
  --cloudflareapitoken "YOUR_CF_API_TOKEN" `
  --store certificatestore `
  --certificatestore My

DNS challenge kullanırken dikkat edilmesi gereken nokta: Cloudflare veya kullandığınız DNS sağlayıcısının API token’ının yalnızca ilgili zone için Zone:DNS:Edit yetkisine sahip olması gerekir. Tam yetkili token kullanmaktan kaçının.

Active Directory Certificate Services ile İç DV Benzeri Sertifika

Kurumsal ortamlarda zaman zaman iç kullanım için kendi CA’nızdan sertifika düzenlemeniz gerekir. Active Directory Certificate Services (AD CS) bu iş için tasarlanmış bir role. Teknik olarak AD CS kendi enterprise CA’nızdan ürettiği için “DV” standardında bir public sertifika değildir, ancak iç domainler için aynı işlevi görür.

AD CS kurulumu:

# AD CS rolünü yükle
Install-WindowsFeature -Name AD-Certificate, ADCS-Cert-Authority, ADCS-Web-Enrollment `
  -IncludeManagementTools

# Enterprise Root CA olarak yapılandır
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCa `
  -CACommonName "Sirket Internal CA" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 10 `
  -Force

Kurulum tamamlandıktan sonra domain üyesi makineler bu CA’ya otomatik olarak güvenecektir. Ancak mobil cihazlar ve dış kullanıcılar için ayrıca root sertifikayı dağıtmanız gerekir.

Sertifika Yenileme Süreçlerini Otomatize Etme

DV sertifikalarının en büyük dezavantajı kısa geçerlilik süresidir. Let’s Encrypt sertifikaları 90 gün geçerli. Bunu manuel takip etmeye çalışırsanız er ya da geç bir sertifika expire olacak ve gece yarısı arayan kullanıcılarla karşılaşacaksınız. Otomatize edin.

# Sertifika yenileme için scheduled task oluştur
$action = New-ScheduledTaskAction -Execute "C:Toolswin-acmewacs.exe" -Argument "--renew --baseuri https://acme-v02.api.letsencrypt.org/"
$trigger = New-ScheduledTaskTrigger -Daily -At "03:00AM"
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Hours 1)
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -TaskName "SSL Sertifika Yenileme" `
  -Action $action `
  -Trigger $trigger `
  -Settings $settings `
  -Principal $principal `
  -Description "Let's Encrypt DV sertifikalarini otomatik yeniler"

Bu scheduled task her gece saat 03:00’te çalışır ve süresi 30 günün altına düşmüş sertifikaları otomatik yeniler. Win-acme zaten bunu akıllıca yönetir, her seferinde yenileme yapmaz.

Sertifika Expire Monitoring Script’i

Sadece yenileme yetmez, monitoring da şart. Aşağıdaki script domain’inizdeki önemli sunucuları tarayarak 30 gün içinde sona erecek sertifikaları raporlar ve mail atar.

# Sertifika expire monitoring scripti
$sunucular = @("WEBSERVER01", "ADFS01", "RDG01", "EXCHANGE01")
$uyariGunu = 30
$smtpServer = "mail.sirketiniz.local"
$gonderen = "[email protected]"
$alici = "[email protected]"

$uyarilar = @()

foreach ($sunucu in $sunucular) {
    try {
        $sertifikalar = Invoke-Command -ComputerName $sunucu -ScriptBlock {
            Get-ChildItem -Path Cert:LocalMachineMy | 
            Where-Object { $_.NotAfter -lt (Get-Date).AddDays($using:uyariGunu) -and $_.NotAfter -gt (Get-Date) } |
            Select-Object Subject, NotAfter, Thumbprint, @{N='DaysLeft';E={($_.NotAfter - (Get-Date)).Days}}
        } -ErrorAction Stop

        foreach ($sert in $sertifikalar) {
            $uyarilar += [PSCustomObject]@{
                Sunucu = $sunucu
                Subject = $sert.Subject
                SonGun = $sert.NotAfter.ToString("dd.MM.yyyy")
                KalanGun = $sert.DaysLeft
            }
        }
    } catch {
        Write-Warning "$sunucu sunucusuna erisilemedi: $_"
    }
}

if ($uyarilar.Count -gt 0) {
    $govde = "Asagidaki sertifikalar $uyariGunu gun icinde sona erecek:`n`n"
    $uyarilar | ForEach-Object {
        $govde += "Sunucu: $($_.Sunucu) | Domain: $($_.Subject) | Son Gun: $($_.SonGun) | Kalan: $($_.KalanGun) gun`n"
    }
    
    Send-MailMessage -SmtpServer $smtpServer -From $gonderen -To $alici `
      -Subject "UYARI: SSL Sertifika Suresi Doluyor" -Body $govde -Encoding UTF8
    
    Write-Output "Uyari maili gonderildi. $($uyarilar.Count) sertifika risk altinda."
} else {
    Write-Output "Tum sertifikalar gecerli. Sorun yok."
}

Bu scripti da bir scheduled task ile haftada bir çalıştırın. Böylece sürprizlerle karşılaşmazsınız.

Gerçek Dünya Senaryosu: Web Application Proxy + DV Sertifikası

Diyelim ki şirketinizin iç ağındaki bir web uygulamasını dışarıya açmanız gerekiyor. Bunun için Web Application Proxy (WAP) kullanıyorsunuz ve tabii ki bir DV sertifikasına ihtiyacınız var. İşte bu senaryoda izlemeniz gereken adımlar:

Önce CSR (Certificate Signing Request) üretin:

# PowerShell ile CSR oluştur
$req = @"
[Version]
Signature="`$Windows NT`$"

[NewRequest]
Subject = "CN=app.sirketiniz.com, O=Sirket AS, C=TR"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=app.sirketiniz.com&"
_continue_ = "dns=www.sirketiniz.com&"
"@

$req | Out-File -FilePath "C:Temprequest.inf" -Encoding ASCII
certreq -new "C:Temprequest.inf" "C:Temprequest.csr"
Write-Output "CSR olusturuldu: C:Temprequest.csr"

CSR’ı CA’ya gönderdikten ve sertifikayı aldıktan sonra yükleyin:

# Sertifikayı sisteme yukle ve CSR ile eslesir
certreq -accept "C:Tempsirket_sertifika.cer"

# Sertifikanin dogru yuklendigi dogrula
Get-ChildItem -Path Cert:LocalMachineMy | 
  Where-Object { $_.Subject -like "*app.sirketiniz.com*" } |
  Select-Object Subject, NotAfter, HasPrivateKey

HasPrivateKey değerinin True olması kritik önem taşır. Eğer False ise sertifika ile private key eşleşmemiş demektir ve bu sertifikayla güvenli bağlantı kurulamaz.

DV Sertifikası ile IIS Binding Yapılandırma

Sertifikayı aldınız, şimdi IIS’e bağlamanız gerekiyor:

# Mevcut IIS sitelerine sertifika bağla
Import-Module WebAdministration

# Thumbprint'i al
$thumbprint = (Get-ChildItem -Path Cert:LocalMachineMy | 
  Where-Object { $_.Subject -like "*app.sirketiniz.com*" } | 
  Sort-Object NotAfter -Descending | 
  Select-Object -First 1).Thumbprint

# HTTPS binding ekle veya guncelle
$site = Get-Website -Name "DısUygulama"
$binding = Get-WebBinding -Name "DısUygulama" -Protocol "https" -Port 443

if ($binding) {
    # Mevcut binding'i guncelle
    $binding.AddSslCertificate($thumbprint, "My")
    Write-Output "Mevcut HTTPS binding guncellendi."
} else {
    # Yeni binding olustur
    New-WebBinding -Name "DısUygulama" -Protocol "https" -Port 443 -HostHeader "app.sirketiniz.com" -SslFlags 1
    $yeniBinding = Get-WebBinding -Name "DısUygulama" -Protocol "https" -Port 443
    $yeniBinding.AddSslCertificate($thumbprint, "My")
    Write-Output "Yeni HTTPS binding olusturuldu ve sertifika baglandi."
}

DV mi, OV mi, EV mi? Ne Zaman DV Yeterli?

Kategorinin başlığında da belirttiğimiz gibi odağımız DV. Ancak ne zaman DV’nin yeterli olduğunu bilmek önemli.

DV sertifikası yeterlidir:

  • İç ağ servisleri ve intranet uygulamaları için
  • Geliştirme ve test ortamları için
  • Blog, bilgi portalı gibi kurumsal kimlik gerektirmeyen siteler için
  • API endpoint’leri ve servis-servis iletişimi için
  • Active Directory Federation Services gibi teknik altyapı bileşenleri için

DV sertifikası yetersiz kalır:

  • E-ticaret ve ödeme sayfaları (en azından OV önerilir)
  • Kurumsal bankacılık ve fintech uygulamaları
  • Kullanıcının kurumsal kimliği görmesinin önemli olduğu durumlar (banka, devlet kurumu gibi)

Sysadmin olarak bu kararı tek başınıza vermeyin. Güvenlik ekibi ve yöneticilerle birlikte değerlendirin.

Group Policy ile Sertifika Dağıtımı

AD ortamınızdaki tüm istemcilere kendi CA’nızın root sertifikasını dağıtmak istiyorsanız, bunu Group Policy üzerinden kolayca yapabilirsiniz. Bu özellikle iç kullanım için kendi CA’nızdan ürettiğiniz sertifikalara domain makinelerinin güvenmesini sağlar.

# Group Policy'e root sertifika eklemek icin (PowerShell ile GPO uzerinden)
# Once sertifika dosyasini SYSVOL'e kopyala
Copy-Item -Path "C:TempInternalRootCA.cer" -Destination "\sirket.localSYSVOLsirket.localPoliciesCertDist"

# Sonra PowerShell ile GPO'ya ekle
Import-Module GroupPolicy

$gpo = Get-GPO -Name "Sertifika Dagitimlari"
if (-not $gpo) {
    $gpo = New-GPO -Name "Sertifika Dagitimlari" -Comment "Dahili CA sertifika dagitimi"
    New-GPLink -Name "Sertifika Dagitimlari" -Target "DC=sirket,DC=local"
}

# Sertifika GPO icerigini manuel olarak GPMC uzerinden de ekleyebilirsiniz:
# Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
Write-Output "GPO hazir. GPMC uzerinden sertifika ekleyin: Computer Config > Security Settings > PKI"

Komut satırından GPO içine sertifika eklemek bazen karmaşık olabiliyor. GPMC (Group Policy Management Console) üzerinden Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities yolunu izleyerek sertifikayı import etmek daha güvenli bir yöntem.

Sık Karşılaşılan Sorunlar ve Çözümleri

Sertifika var ama tarayıcı “güvenli değil” diyor: Büyük ihtimalle intermediate (ara) sertifikalar eksik. CA’nın chain sertifikalarını da yüklemeniz gerekiyor.

# Certificate chain'i kontrol et
$sert = Get-ChildItem -Path Cert:LocalMachineMy | Where-Object { $_.Subject -like "*app.sirketiniz.com*" }
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($sert)
$chain.ChainElements | ForEach-Object { Write-Output $_.Certificate.Subject }

Private key yok hatası: Sertifikayı import ederken private key’i de dahil etmeniz gerekir. PFX formatını kullanın.

# PFX olarak export et (private key dahil)
$sert = Get-ChildItem -Path Cert:LocalMachineMy | Where-Object { $_.Thumbprint -eq "THUMBPRINT_BURAYA" }
$pwd = ConvertTo-SecureString -String "GucluSifre123!" -Force -AsPlainText
Export-PfxCertificate -Cert $sert -FilePath "C:Backupsertifika.pfx" -Password $pwd

IIS sertifikayı seçemiyor: Uygulama havuzunun (application pool) sertifikanın private key’ine erişim izni olmayabilir. Network Service veya IIS AppPool hesabına private key okuma izni verin.

Sonuç

DV sertifikaları, doğru kullanıldığında sysadmin’lerin en güçlü araçlarından biridir. Ücretsiz, hızlı alınabilir ve iyi araçlarla tam otomatize edilebilir. Active Directory ortamında, özellikle iç servisler, ADFS, WAP, RD Gateway gibi bileşenler için DV sertifikaları hem pratik hem de maliyet açısından mantıklı bir tercih.

Özetlemek gerekirse şunlara dikkat edin:

  • Otomatize edin: 90 günlük Let’s Encrypt sertifikalarını manuel takip etmeye çalışmayın. Win-acme + scheduled task kombinasyonu hayat kurtarır.
  • Monitoring kurun: Expire monitoring scripti olmadan uyuma. Bir sertifika expire olduğunda kullanıcılar sizi siz fark etmeden önce bulacaktır.
  • Chain sertifikalarını ihmal etmeyin: Sadece leaf sertifika yeterli değil, tam certificate chain gerekli.
  • Private key güvenliğini ciddiye alın: PFX dosyalarını güvenli bir yerde saklayın, güçlü şifreyle koruyun.
  • GPO ile dağıtın: İç CA kullanıyorsanız root sertifikayı GPO ile tüm makinalara dağıtmayı unutmayın.

Kurumsal ortamda sertifika yönetimi, göz ardı edildiğinde kritik outage’lara yol açan sessiz bir risk alanıdır. Ama yukarıdaki adımları uygularsanız, bu riski büyük ölçüde kontrol altına alabilirsiniz.

Yorum yapın