CAA Kaydı ile SSL Sertifika Yetkisini Kısıtlama

yazar

Bir sabah işe geliyorsunuz ve domain’iniz için beklenmedik bir SSL sertifikası düzenlendiğini fark ediyorsunuz. Siz sipariş etmediniz, IT ekibiniz bilmiyor, ama sertifika geçerli ve tarayıcılar onu kabul ediyor. Bu senaryo kulağa paranoya gibi gelebilir, ancak gerçek dünyada yaşanmış olaylardan biri. İşte tam bu noktada CAA (Certification Authority Authorization) kaydı devreye giriyor ve domain’iniz adına sertifika kiminin düzenleyebileceğini DNS seviyesinde sınırlandırmanıza imkan veriyor.

CAA Kaydı Nedir ve Neden Önemlidir

CAA kaydı, 2013 yılında RFC 6844 ile tanımlanan ve sonradan RFC 8659 ile güncellenen bir DNS kayıt türüdür. 2017 yılından itibaren CA/Browser Forum kararıyla tüm sertifika otoritelerinin (CA) sertifika düzenlemeden önce CAA kaydını kontrol etmesi zorunlu hale getirildi. Bu zorunluluk, önemli bir güvenlik katmanı oluşturdu.

Temel mantık şu: Domain sahibi olarak DNS’e bir kayıt ekleyerek “bu domain için sadece Let’s Encrypt ve DigiCert sertifika düzenleyebilir” diyebilirsiniz. Başka bir CA bu kaydı gördüğünde sertifika düzenlemeyi reddetmek zorundadır.

Neyi engeller?

  • Yetkisiz CA’ların sertifika düzenlemesini
  • Çalışanların habersizce farklı sağlayıcıdan sertifika almasını
  • BGP hijacking veya DNS spoofing sonrası otomatik sertifika düzenlenmesini
  • Wildcard sertifika düzenlemesini kısıtlamayı

Neyi engellemez?

  • Zaten var olan sertifikaların kullanımını
  • CA’nın kötü niyetli davranışlarını (bu daha çok CT logları ile takip edilir)
  • HTTPS bağlantısını doğrudan etkilemez

CAA Kaydının Yapısı

CAA kaydının sözdizimini anlamak, doğru yapılandırma için kritiktir. Her CAA kaydı üç bölümden oluşur:

<domain> CAA <flag> <tag> "<value>"

Flag (Bayrak) Değerleri:

  • 0: Standart, CA bu kaydı tanımıyorsa sertifika düzenlemeyebilir ama zorunlu değil
  • 128: Critical (kritik), CA bu tag’i tanımıyorsa kesinlikle sertifika düzenleyemez

Tag Değerleri:

  • issue: Belirtilen CA’nın standart sertifika düzenlemesine izin verir
  • issuewild: Wildcard sertifika düzenlemesine özel izin verir
  • iodef: Politika ihlali durumunda bildirim gönderilecek URL veya e-posta

Basit bir örnek:

# Sadece Let's Encrypt'e izin ver
example.com. CAA 0 issue "letsencrypt.org"

Temel CAA Yapılandırmaları

Tek CA ile Basit Yapılandırma

Küçük bir işletme veya kişisel proje için en yaygın senaryo, tek bir CA’ya izin vermektir:

# BIND zone dosyası formatında
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"

Bu yapılandırmada, Let’s Encrypt dışında hiçbir CA example.com için sertifika düzenleyemez. Düzenlenmeye çalışılırsa iodef adresine bildirim gönderilir.

Birden Fazla CA’ya İzin Verme

Kurumsal ortamlarda farklı sistemler için farklı CA’lar gerekebilir. Örneğin web sunucularınız için Let’s Encrypt, ödeme sistemleriniz için DigiCert kullanıyor olabilirsiniz:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issue "sectigo.com"
example.com. IN CAA 0 iodef "mailto:[email protected]"

Bu kayıtlar “VEYA” mantığıyla çalışır, yani listelenen CA’lardan herhangi biri sertifika düzenleyebilir.

Wildcard Sertifikaları Kısıtlama

Bu önemli bir güvenlik detayıdır. issue tag’i standart sertifikaları kontrol ederken, wildcard sertifikalar için ayrıca issuewild tanımlamanız gerekir:

# Standart sertifikalar için Let's Encrypt'e izin ver
example.com. IN CAA 0 issue "letsencrypt.org"

# Wildcard sertifikalar SADECE DigiCert'ten alınabilir
example.com. IN CAA 0 issuewild "digicert.com"

# Bildirimler için
example.com. IN CAA 0 iodef "mailto:[email protected]"

Eğer wildcard sertifika hiç istenmiyorsa:

# Wildcard sertifika tamamen engelle
example.com. IN CAA 0 issuewild ";"

Tüm Sertifikasyonu Engellemek

Bazen bir domain için hiçbir CA’nın sertifika düzenlemesini istemeyebilirsiniz. Dahili domain’ler veya artık kullanılmayan subdomain’ler için bu yararlı olabilir:

# Hiçbir CA sertifika düzenleyemez
legacy.example.com. IN CAA 0 issue ";"
legacy.example.com. IN CAA 0 issuewild ";"

Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Sitesi Güvenliği

Bir e-ticaret şirketinde çalıştığınızı düşünün. Ödeme sayfaları için EV (Extended Validation) sertifikası zorunlu, diğer sayfalar için standart DV sertifikası yeterli. Aynı zamanda DevOps ekibi bazı test subdomain’leri için Let’s Encrypt kullanıyor:

# Ana domain - sadece DigiCert EV sertifikası
shop.example.com. IN CAA 0 issue "digicert.com"
shop.example.com. IN CAA 0 issuewild ";"
shop.example.com. IN CAA 0 iodef "mailto:[email protected]"

# API subdomain - DigiCert ve Sectigo
api.example.com. IN CAA 0 issue "digicert.com"
api.example.com. IN CAA 0 issue "sectigo.com"

# Staging ortamı - Let's Encrypt yeterli
staging.example.com. IN CAA 0 issue "letsencrypt.org"
staging.example.com. IN CAA 0 iodef "https://security.example.com/caa-report"

Senaryo 2: Büyük Kurumsal Yapı

Farklı departmanların farklı ihtiyaçları olan büyük bir şirkette merkezi sertifika politikası uygulamak istiyorsunuz:

# Kök domain politikası - tüm alt kayıtlar bunu miras alır
example.com. IN CAA 0 issue "sectigo.com"
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "sectigo.com"
example.com. IN CAA 0 iodef "mailto:[email protected]"

# İnsan kaynakları - sadece kurumsal CA
hr.example.com. IN CAA 0 issue "sectigo.com"
hr.example.com. IN CAA 0 issuewild ";"

# Geliştirici araçları - daha esnek
dev.example.com. IN CAA 0 issue "letsencrypt.org"
dev.example.com. IN CAA 0 issue "sectigo.com"

DNS Sağlayıcısına Göre Yapılandırma

Cloudflare Üzerinde CAA Kaydı

Cloudflare, CAA kayıtlarını yönetmek için hem web arayüzü hem de API sunuyor. API üzerinden yapılandırma:

# Cloudflare API ile CAA kaydı ekleme
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" 
     -H "Authorization: Bearer API_TOKEN" 
     -H "Content-Type: application/json" 
     --data '{
       "type": "CAA",
       "name": "example.com",
       "data": {
         "flags": 0,
         "tag": "issue",
         "value": "letsencrypt.org"
       },
       "ttl": 3600
     }'

BIND Üzerinde CAA Kaydı

Kendi DNS sunucunuzu yönetiyorsanız ve BIND kullanıyorsanız:

# /etc/bind/zones/example.com.zone dosyasına ekleyin
$ORIGIN example.com.
$TTL 3600

@ IN SOA ns1.example.com. admin.example.com. (
    2024010101 ; Serial
    3600       ; Refresh
    900        ; Retry
    604800     ; Expire
    300 )      ; Minimum TTL

; CAA Kayıtları
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issue "digicert.com"
@ IN CAA 0 issuewild "digicert.com"
@ IN CAA 0 iodef "mailto:[email protected]"

# Zone'u yeniden yükleyin
rndc reload example.com

PowerDNS Üzerinde CAA Kaydı

# PowerDNS API ile CAA kaydı ekleme
curl -X PATCH "http://localhost:8081/api/v1/servers/localhost/zones/example.com." 
     -H "X-API-Key: YOUR_API_KEY" 
     -H "Content-Type: application/json" 
     --data '{
       "rrsets": [{
         "name": "example.com.",
         "type": "CAA",
         "ttl": 3600,
         "changetype": "REPLACE",
         "records": [
           {
             "content": "0 issue "letsencrypt.org"",
             "disabled": false
           },
           {
             "content": "0 iodef "mailto:[email protected]"",
             "disabled": false
           }
         ]
       }]
     }'

CAA Kayıtlarını Doğrulama ve Test Etme

Yapılandırdıktan sonra her zaman doğrulama yapmalısınız. Bunun için birkaç yöntem:

# dig ile CAA kaydını sorgula
dig CAA example.com

# Beklenen çıktı:
# example.com. 3600 IN CAA 0 issue "letsencrypt.org"
# example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

# Belirli bir DNS sunucusuna sorgu at
dig @8.8.8.8 CAA example.com

# nslookup ile kontrol
nslookup -type=CAA example.com

# Propagasyonu kontrol etmek için birden fazla sunucuda test
for dns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo "=== DNS: $dns ==="
    dig @$dns CAA example.com +short
done

Wildcard sertifika kısıtlamasını test etmek için:

# Hem subdomain hem wildcard kontrolü
dig CAA example.com
dig CAA "*.example.com"

# CAA lookup chain'i anlamak için
# www.example.com -> example.com -> (parent domain) sırasıyla kontrol edilir
dig CAA www.example.com
dig CAA example.com

Online araçlarla da doğrulama yapabilirsiniz. sslmate.com/labs/caa ve ssllabs.com bu konuda ücretsiz test imkanı sunar.

CAA ve Sertifika Şeffaflığı (CT) ile Birlikte Kullanım

CAA kaydı tek başına yeterli bir güvenlik mekanizması değildir. Certificate Transparency (CT) log’ları ile birlikte kullanıldığında çok daha güçlü bir koruma sağlar. CT, dünyada düzenlenen tüm SSL sertifikalarının kaydedildiği açık bir log sistemidir.

certspotter veya crt.sh üzerinden domain’iniz için düzenlenen tüm sertifikaları izleyebilirsiniz:

# crt.sh API ile domain sertifikalarını listele
curl -s "https://crt.sh/?q=%.example.com&output=json" | 
    python3 -c "
import sys, json
data = json.load(sys.stdin)
for cert in data:
    print(f"Issuer: {cert['issuer_name']}")
    print(f"Name: {cert['name_value']}")
    print(f"Not Before: {cert['not_before']}")
    print('---')
" 2>/dev/null | head -60

# certspotter ile izleme (certspotter kurulu olmalı)
# /etc/certspotter/hooks.d/ dizinine bildirim scripti ekleyin

Bu iki mekanizmanın birlikte kullanımı şu şekilde çalışır: CAA kaydı yeni sertifika düzenlenmesini önler, CT logları ise eğer bir şekilde sertifika düzenlendiyse sizi haberdar eder.

Yaygın Hatalar ve Çözümleri

Miras (Inheritance) Yanlış Anlaşılması

CAA kayıtları DNS hiyerarşisini takip eder, ancak tam olarak beklediğiniz gibi çalışmayabilir:

# Örnek senaryo
# example.com için CAA kaydı var
example.com. CAA 0 issue "letsencrypt.org"

# www.example.com için CAA kaydı YOK
# Bu durumda www.example.com, example.com'un CAA kaydını MIRAS ALIR
# Yani www.example.com için de sadece Let's Encrypt sertifika düzenleyebilir

# Ancak şu durumda:
sub.example.com. CAA 0 issue "digicert.com"
# sub.example.com'un kendi CAA kaydı var, example.com'u miras ALMAZ

Bu davranışı anlamak kritiktir. Bir subdomain için boş CAA kaydı koymak, o subdomain’in herhangi bir CA’dan sertifika alabilmesini sağlar:

# subdomain'de tüm kısıtlamaları kaldırmak istiyorsanız
# (dikkatli kullanın!)
public.example.com. CAA 0 issue ";"
# Bu, hiçbir CA'nın sertifika düzenleyememesi anlamına gelir
# Tüm kısıtlamaları kaldırmak için bu yöntemi kullanmayın!

Let’s Encrypt Özel Parametreleri

Let’s Encrypt bazı özel parametreler destekler. Örneğin ACME hesabını kısıtlamak:

# Sadece belirli bir Let's Encrypt hesabına izin ver
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567"

# Sadece DNS-01 challenge metoduna izin ver
example.com. CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

# Her ikisini birden belirt
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567; validationmethods=dns-01"

Bu özellik özellikle wildcard sertifikalar için çok değerlidir, çünkü wildcard sertifikalar zaten DNS-01 challenge gerektiriyor ve hesabı kısıtlamak ekstra güvenlik sağlıyor.

Monitoring ve Otomasyon

Üretim ortamında CAA kayıtlarını düzenli olarak izlemek için basit bir script:

#!/bin/bash
# caa_monitor.sh - CAA kayıtlarını izle ve değişiklik varsa uyar

DOMAINS=("example.com" "api.example.com" "shop.example.com")
EXPECTED_CA="letsencrypt.org"
ALERT_EMAIL="[email protected]"
LOG_FILE="/var/log/caa_monitor.log"

check_caa() {
    local domain=$1
    local result=$(dig +short CAA "$domain" 2>/dev/null)
    
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Checking CAA for: $domain" >> "$LOG_FILE"
    
    if [ -z "$result" ]; then
        echo "UYARI: $domain için CAA kaydı bulunamadi!" >> "$LOG_FILE"
        echo "CAA UYARISI: $domain için CAA kaydı eksik!" | 
            mail -s "CAA Alarm: $domain" "$ALERT_EMAIL"
        return 1
    fi
    
    if ! echo "$result" | grep -q "$EXPECTED_CA"; then
        echo "UYARI: $domain CAA kaydında beklenen CA bulunamadi!" >> "$LOG_FILE"
        echo "Mevcut kayit: $result" >> "$LOG_FILE"
    else
        echo "OK: $domain CAA kaydı doğru." >> "$LOG_FILE"
    fi
}

for domain in "${DOMAINS[@]}"; do
    check_caa "$domain"
done

Bu scripti cron’a ekleyin:

# Her gün sabah 9'da çalıştır
0 9 * * * /opt/scripts/caa_monitor.sh

# Veya her 6 saatte bir kontrol
0 */6 * * * /opt/scripts/caa_monitor.sh

CAA Politikası Dokümantasyonu

Kurumsal ortamlarda CAA yapılandırmasının yanı sıra bir politika belgesi de oluşturmanız önerilir. Bu belge şunları içermeli:

Onaylı CA Listesi

  • Hangi CA’ların onaylı olduğunu ve neden seçildiğini
  • Her CA’nın hangi sertifika türleri için kullanılabileceğini
  • CA sözleşme bilgilerini ve iletişim kişilerini

Değişiklik Prosedürü

  • Yeni bir CA eklemek için onay süreci
  • Mevcut bir CA’yı kaldırma prosedürü (aktif sertifikalar ne olacak?)
  • Acil durum sertifika prosedürü (CAA kaydı güncellemesi ne kadar sürer?)

İzleme ve Olay Müdahalesi

  • CT log izleme sorumluluğu
  • Yetkisiz sertifika tespit edildiğinde izlenecek adımlar
  • CA’ya ihbar prosedürü

Sonuç

CAA kaydı, DNS’e eklemeniz gereken birkaç satır karşılığında ciddi bir güvenlik katmanı oluşturan, çoğu zaman göz ardı edilen ama değerli bir mekanizmadır. Özellikle büyük organizasyonlarda ve güvenlik düzenlemelerine tabi sektörlerde (finans, sağlık, e-ticaret) CAA yapılandırması artık bir tercih değil, zorunluluktur.

Başlangıç için basit tutun: Kullandığınız CA’yı tespit edin, iodef ile bildirim adresinizi ekleyin ve wildcard sertifikaları açıkça kısıtlayın. Ardından Certificate Transparency loglarını izlemeye başlayın. Bu iki mekanizmanın birlikte çalışması, sertifika yönetiminize önemli bir görünürlük ve kontrol katacaktır.

Unutmayın, CAA kaydı bir CA’nın kötü niyetli davranışını engelleyemez, ancak kazara veya yetkisiz düzenlemelerin büyük çoğunluğunu önler. Güvenlik her zaman katmanlar halinde düşünülmeli ve CAA bu katmanlardan biri olmalıdır.

Yorum yapın