Alan Adı & DNS

    CAA Kaydı Nedir ve SSL Güvenliği

    Sertifika üretimini yetkilendiren CAA kaydının SSL güvenliğine katkısı.

    12 dk okuma Güncellendi: 10 Temmuz 2026

    Alan adınız için SSL sertifikası aldığınızda çoğu zaman perde arkasında olan bir gerçeği düşünmezsiniz: teknik olarak dünyadaki herhangi bir sertifika otoritesi (Certificate Authority, kısaca CA), sizin izniniz olmadan sizin alan adınıza sertifika üretebilir. Sadece alan adı doğrulamasını (domain validation) geçen kişi, bu üretimi tetikleyebilir. İşte CAA kaydı tam olarak bu boşluğu kapatmak için tasarlanmış, DNS bölgenize yazdığınız küçük ama stratejik bir kayıttır.

    CAA, "Certification Authority Authorization" yani "Sertifika Otoritesi Yetkilendirmesi" kelimelerinin kısaltmasıdır. Kısacası DNS üzerinden bir beyaz liste (whitelist) yayınlarsınız: "Bu alan adına yalnızca şu sertifika otoriteleri sertifika üretebilir" dersiniz. RFC 8659 ile standartlaşan bu mekanizma, 2017'den beri tüm halka açık sertifika otoriteleri için zorunlu bir kontrol adımıdır. Bu rehberde CAA kaydının ne işe yaradığını, issue, issuewild ve iodef etiketlerini, Let's Encrypt için pratik örnekleri ve yetkisiz sertifika üretiminin nasıl engellendiğini uçtan uca ele alacağız.

    CAA Kaydı Ne İşe Yarar?#

    Klasik senaryoyu düşünelim. sirketiniz.com alan adınız var ve SSL sertifikanızı güvenilir bir sağlayıcıdan aldınız. Ancak DNS ayarlarınızda hiçbir kısıtlama yoksa, bir saldırgan ya da hatalı yapılandırılmış bir otomasyon, tamamen farklı bir sertifika otoritesine giderek sizin alan adınıza yeni bir sertifika talep edebilir. Eğer bu kişi bir şekilde alan adı doğrulamasını manipüle edebilirse (örneğin DNS zafiyeti, e-posta ele geçirme ya da BGP hijacking yoluyla), elinde geçerli görünen bir sertifika olur ve bu sertifikayla ortadaki adam (MITM) saldırısı düzenleyebilir.

    CAA kaydı bu riski daraltır. Siz DNS'te "yalnızca Let's Encrypt ve DigiCert benim adıma sertifika üretebilir" dediğinizde, dördüncü bir otorite bu talebi aldığında önce sizin DNS bölgenizi sorgulamak zorundadır. Kendisini listede bulamazsa, standart gereği talebi reddeder. Yani saldırgan doğrulamayı geçse bile, yetkisiz bir CA sertifika basmayı reddeder. Bu, sertifika ekosistemine eklenmiş bir "ikinci kilit" gibidir.

    Burada net olalım: CAA kaydı, sertifikanın nasıl kullanılacağını ya da mevcut sertifikalarınızı doğrudan korumaz. Yaptığı iş, yeni sertifika üretimini yetkilendirmektir. Bu yüzden CAA'yı, SSL güvenliğinizin tamamı değil, bütünü tamamlayan bir katmanı olarak görmek doğru olur. SSL'in bütünsel resmini merak ediyorsanız SSL sertifikası nedir yazımız iyi bir başlangıç noktasıdır.

    CAA Kaydının Anatomisi#

    Bir CAA kaydı üç ana bileşenden oluşur ve DNS'te oldukça basit bir söz dizimine sahiptir. Klasik bir kayıt şöyle görünür:

    sirketiniz.com.   IN   CAA   0   issue   "letsencrypt.org"
    

    Bu satırı parçalara ayıralım:

    • Flags (bayrak): İlk sayısal alandır, burada 0. Yalnızca son bit anlamlıdır. 0 normal (kritik olmayan) bir kaydı, 128 ise "critical" bayrağını temsil eder. Critical bayrağı, kaydı işleyemeyen bir CA'nın işlemi kesinlikle durdurması gerektiğini söyler.
    • Tag (etiket): issue, issuewild ya da iodef olabilir. Kaydın türünü ve amacını belirler.
    • Value (değer): Tırnak içindeki metin. Genellikle bir CA'nın kanonik alan adıdır (örneğin letsencrypt.org, digicert.com, sectigo.com, pki.goog) veya iodef için bir bildirim adresidir.

    Aşağıdaki tablo etiketleri özetliyor:

    EtiketAmaçÖrnek değer
    issueTekil (non-wildcard) sertifika üretimini yetkilendirir"letsencrypt.org"
    issuewildWildcard (*.alan.com) sertifika üretimini yetkilendirir"digicert.com"
    iodefPolitika ihlali durumunda bildirim adresi"mailto:[email protected]"

    Önemli bir davranış: eğer bir alan adında hiç CAA kaydı yoksa, bu "herkese açık" anlamına gelir ve tüm CA'lar sertifika üretebilir. CAA'nın koruması ancak siz en az bir kayıt tanımladığınızda başlar. Kaydı ilk oluşturduğunuz anda, listelemediğiniz tüm otoriteler otomatik olarak dışlanmış olur.

    issue Etiketi ile Yetkilendirme#

    issue etiketi CAA kaydının en yaygın kullanılan biçimidir ve tekil (tek alan adına özgü, wildcard olmayan) sertifikaları kontrol eder. Örneğin yalnızca Let's Encrypt'e izin vermek isterseniz:

    sirketiniz.com.   IN   CAA   0   issue   "letsencrypt.org"
    

    Birden fazla otoriteye izin vermek istiyorsanız, her biri için ayrı bir satır eklersiniz. CAA kayıtları birbirinin üzerine yazmaz; toplu olarak değerlendirilir:

    sirketiniz.com.   IN   CAA   0   issue   "letsencrypt.org"
    sirketiniz.com.   IN   CAA   0   issue   "digicert.com"
    sirketiniz.com.   IN   CAA   0   issue   "sectigo.com"
    

    Bu üç satır birlikte şunu söyler: "Bu alan adına yalnızca Let's Encrypt, DigiCert ve Sectigo tekil sertifika basabilir." Diğer tüm otoriteler talebi reddetmek zorundadır.

    Özel bir durum vardır ki güvenlik açısından oldukça değerlidir: hiçbir otoritenin sertifika üretmesini istemiyorsanız, değer olarak ";" (yalnızca noktalı virgül) kullanırsınız:

    altkullanim.sirketiniz.com.   IN   CAA   0   issue   ";"
    

    Bu satır, altkullanim.sirketiniz.com için hiçbir otoritenin sertifika üretemeyeceğini garanti eder. Aktif olarak kullanmadığınız alt alan adları için bu, saldırı yüzeyini kapatmanın çok etkili bir yoludur. Alan adı ve alt alan adı mantığını derinlemesine anlamak isterseniz DNS nedir yazımızda konu detaylıca işleniyor.

    issuewild ile Wildcard Sertifika Kontrolü#

    Wildcard sertifikalar (*.sirketiniz.com gibi) tek bir sertifikayla sınırsız sayıda alt alan adını kapsadıkları için özel bir güvenlik hassasiyeti taşırlar. Bir saldırgan wildcard sertifika ele geçirirse, oluşturabileceği her alt alan adı için geçerli görünen bir sertifikaya sahip olur. Bu yüzden CAA standardı wildcard üretimini ayrı bir etiketle, issuewild ile yönetir.

    issuewild kaydı varsa, wildcard sertifika talepleri yalnızca issuewild listesine bakar; issue listesi wildcard için dikkate alınmaz. issuewild kaydı hiç yoksa, wildcard talepleri issue listesine düşer. Bu davranış ince ama önemlidir. Örneğin şu yapılandırmayı ele alalım:

    sirketiniz.com.   IN   CAA   0   issue      "letsencrypt.org"
    sirketiniz.com.   IN   CAA   0   issuewild  ";"
    

    Buradaki anlam çok net: "Let's Encrypt tekil sertifika üretebilir, ancak hiç kimse (kendisi dahil) bu alan adına wildcard sertifika üretemez." Bu, wildcard'a ihtiyacınız olmayan ortamlarda mükemmel bir sıkılaştırmadır; birçok kurumsal ortam bu yaklaşımı benimser çünkü wildcard sertifikalar operasyonel olarak daha risklidir.

    Tersine, wildcard'ı belirli bir otoriteyle sınırlamak isterseniz:

    sirketiniz.com.   IN   CAA   0   issue      "letsencrypt.org"
    sirketiniz.com.   IN   CAA   0   issuewild  "digicert.com"
    

    Bu durumda tekil sertifikalar Let's Encrypt'ten, wildcard sertifikalar ise yalnızca DigiCert'ten üretilebilir. Wildcard sertifikaların yapılandırılması ve yönetimiyle ilgili pratik destek için SSL çözümlerimize göz atabilirsiniz.

    iodef ile Olay Bildirimi#

    iodef (Incident Object Description Exchange Format) etiketi, CAA'nın gözden kaçan ama değerli bir özelliğidir. Bir sertifika otoritesi, sizin CAA politikanızı ihlal eden bir talep aldığında — yani listelenmeyen bir CA'ya yapılan bir istek fark edildiğinde — bunu size bildirmesini sağlar. Böylece yetkisiz bir sertifika deneme girişiminden anında haberdar olursunuz.

    sirketiniz.com.   IN   CAA   0   iodef   "mailto:[email protected]"
    

    iodef değeri bir mailto: adresi ya da bir HTTP/HTTPS uç noktası (https://...) olabilir. E-posta seçeneği en yaygın olanıdır çünkü kurulumu basittir. Tam bir güvenlik odaklı yapılandırma şöyle görünür:

    sirketiniz.com.   IN   CAA   0   issue      "letsencrypt.org"
    sirketiniz.com.   IN   CAA   0   issuewild  ";"
    sirketiniz.com.   IN   CAA   0   iodef      "mailto:[email protected]"
    

    Burada dürüst olmak gerekir: iodef desteği tüm sertifika otoriteleri tarafından zorunlu değildir ve raporlama davranışı otoriteden otoriteye değişir. Bazı CA'lar ihlal denemelerini bildirir, bazıları ise yalnızca "best effort" (elinden geldiğince) yaklaşır. Yine de iodef eklemenin hiçbir maliyeti yoktur ve bir erken uyarı kanalı olarak eklemeye değer. Bu bildirimleri kurumsal güvenlik izleme sistemlerinize besleyerek proaktif bir savunma katmanı oluşturabilirsiniz.

    Let's Encrypt Örneği: Yetkisiz Sertifikayı Engelleme#

    Şimdi tüm parçaları birleştirip somut bir senaryo üzerinden yetkisiz üretimin nasıl engellendiğini görelim. Diyelim ki sirketiniz.com için yalnızca Let's Encrypt kullanıyorsunuz ve DNS bölgenize şu kaydı yazdınız:

    sirketiniz.com.   IN   CAA   0   issue   "letsencrypt.org"
    

    Şimdi iki farklı sertifika talebini izleyelim.

    Senaryo 1 — Meşru talep (Let's Encrypt): Sunucunuzdaki Certbot, Let's Encrypt'e bir sertifika ister. Let's Encrypt, sertifikayı basmadan önce sirketiniz.com alan adının CAA kayıtlarını sorgular. Kendisini (letsencrypt.org) listede bulur ve doğrulamayı geçtikten sonra sertifikayı üretir. Certbot komutu sorunsuz tamamlanır:

    sudo certbot certonly --nginx -d sirketiniz.com -d www.sirketiniz.com
    

    Senaryo 2 — Yetkisiz talep (başka bir CA): Bir saldırgan, sirketiniz.com için farklı bir otoriteden sertifika almaya çalışır. O otorite de sertifikayı basmadan önce CAA sorgusu yapar. Ancak kendisini listede bulamaz — listede yalnızca letsencrypt.org var. Standart gereği talebi reddeder ve sertifika hiç üretilmez. Saldırgan, alan adı doğrulamasını bir şekilde geçmiş olsa bile, CAA duvarına takılır.

    CAA'nın kontrol ettiği alanı komut satırından kolayca doğrulayabilirsiniz:

    # CAA kaydını sorgula
    dig CAA sirketiniz.com +short
    
    # Beklenen çıktı:
    # 0 issue "letsencrypt.org"
    

    Alternatif olarak nslookup ya da online CAA test araçlarıyla da kontrol edebilirsiniz. Kaydı oluşturduktan sonra bu doğrulamayı mutlaka yapın; yazım hataları (örneğin letsencrypt.org yerine lets-encrypt.org) sessizce meşru üretiminizi bile engelleyebilir.

    Bir noktaya dikkat: CAA kontrolü sertifika üretim anında yapılır, yenileme anında değil kastediyorum — her yeni imzalamada tekrar sorgulanır. Yani Certbot 60 günde bir yenilerken CAA her seferinde kontrol edilir. Bu yüzden CA'nızı değiştirdiğinizde, yeni sertifika almadan önce CAA kaydını güncellemeyi unutmayın; aksi halde yenileme sessizce başarısız olabilir.

    CAA Kaydını Nasıl Oluşturursunuz?#

    CAA kaydı, DNS yönetim panelinizde diğer kayıtlar (A, CNAME, MX) gibi eklenir. Adımlar sağlayıcıdan bağımsız olarak benzerdir:

    1. DNS yönetim paneline girin ve alan adınızı seçin.
    2. "Kayıt Ekle" bölümünden tür olarak CAA seçin.
    3. Name/Host alanına @ (kök alan adı) yazın; alt alan adı için ise ilgili adı girin.
    4. Flags için 0 girin (özel bir ihtiyacınız yoksa).
    5. Tag olarak issue, issuewild ya da iodef seçin.
    6. Value alanına otoritenin adını (letsencrypt.org) ya da bildirim adresini yazın.
    7. Kaydı kaydedin ve DNS yayılımının tamamlanmasını bekleyin.

    Bazı paneller "flags, tag, value" alanlarını tek bir metin kutusunda ister. Bu durumda değeri şu formatta girersiniz:

    0 issue "letsencrypt.org"
    

    Modern panellerin çoğu (Clou.TR panel dahil) CAA kaydını grafik arayüzden birkaç tıkla eklemenize izin verir; ham bölge dosyasıyla uğraşmanıza gerek kalmaz. DNS yönetiminin size ait olduğu esnek hosting paketlerimizde ya da tam kontrol sunan sanal sunucularımızda CAA dahil tüm kayıt tiplerini rahatça yönetebilirsiniz. Kayıt oluşturmadan önce mevcut değeri kontrol etmek için basit bir betik de kullanabilirsiniz:

    #!/bin/bash
    DOMAIN="sirketiniz.com"
    echo "CAA kayıtları kontrol ediliyor: $DOMAIN"
    RESULT=$(dig CAA "$DOMAIN" +short)
    if [ -z "$RESULT" ]; then
      echo "UYARI: Hiç CAA kaydı yok — tüm CA'lar sertifika üretebilir."
    else
      echo "Mevcut CAA politikası:"
      echo "$RESULT"
    fi
    

    Sık Yapılan Hatalar ve Dikkat Edilecekler#

    CAA kaydı basit görünse de, birkaç yaygın tuzak meşru sertifika üretiminizi bile engelleyebilir. Aşağıdaki tablo en sık karşılaşılan hataları özetliyor:

    HataSonuçDoğrusu
    Yanlış CA adı yazmakYenileme başarısızCA'nın resmi kanonik adını kullanın
    Alt alan adında ayrı CAA yok sanmakKök kaydı miras alınırCAA ağaçta yukarı doğru aranır
    Wildcard için issue yeterli sanmakWildcard reddedilirissuewild ekleyin ya da issue yeterli olsun
    CA değişince kaydı unutmakYeni CA reddedilirÖnce CAA'yı güncelleyin
    TTL'i çok yüksek tutmakDeğişiklik geç yansırGeçiş öncesi TTL'i düşürün

    Özellikle miras (inheritance) davranışı çok yanlış anlaşılır. CAA kayıtları DNS ağacında yukarı doğru aranır. Örneğin blog.sirketiniz.com için sertifika istendiğinde, önce blog.sirketiniz.com'un CAA kaydına bakılır; yoksa sirketiniz.com'a çıkılır. Yani kök alan adında bir CAA kaydı tanımlarsanız, aksi belirtilmedikçe tüm alt alan adları bu politikayı devralır. Bu güçlü bir özelliktir ama bilinçsiz kullanılırsa şaşırtabilir.

    Bir diğer önemli nokta CA adlarının doğruluğudur. Her otoritenin CAA'da kullanılması gereken belirli bir kanonik adı vardır ve bu her zaman markanın günlük adıyla aynı değildir. Örneğin Google Trust Services için pki.goog, Amazon için amazon.com kullanılır. Sertifika sağlayıcınızın dokümantasyonundan doğru değeri teyit edin. DNS değişikliği yaparken TTL'i geçici olarak düşürmek de akıllıca olur; böylece bir hata durumunda düzeltmeniz hızla yayılır. DNS'inizi ve SSL katmanınızı bizim tarafımızdan yönetilmesini isterseniz sunucu yönetimi hizmetimiz bu tür sıkılaştırmaları sizin adınıza kurar.

    CAA'yı Diğer DNS Güvenlik Katmanlarıyla Birleştirmek#

    CAA kaydı tek başına güçlüdür ama gerçek değerini diğer DNS ve SSL güvenlik önlemleriyle birlikte kullanıldığında gösterir. CAA'yı bir güvenlik zincirinin halkası olarak düşünün:

    • DNSSEC: CAA kayıtlarınızın kendisinin sahtelenmemesi için DNS bölgenizi DNSSEC ile imzalayın. DNSSEC olmadan, gelişmiş bir saldırgan teorik olarak CAA yanıtını manipüle etmeye çalışabilir. DNSSEC, CAA'nın DNS katmanındaki bütünlüğünü sağlar.
    • CT (Certificate Transparency) izleme: Tüm halka açık sertifikalar CT loglarına kaydedilir. Bu logları izleyerek (crt.sh gibi araçlarla) alan adınıza kimin sertifika bastığını sürekli takip edebilirsiniz. CAA üretimi engellerken, CT izleme fark edilmeyen üretimleri yakalar.
    • HSTS: Strict-Transport-Security başlığıyla tarayıcıları yalnızca HTTPS kullanmaya zorlarsınız, böylece downgrade saldırılarını engellersiniz.

    Bu katmanları birlikte uyguladığınızda, sertifika ekosisteminizin her aşamasını — üretim, izleme ve kullanım — korumuş olursunuz. Sunucu tarafında ek bir savunma hattı için WAF ve DDoS koruma çözümlerimiz uygulama katmanını, düzenli yedekleme ise felaket kurtarma senaryolarını güvenceye alır. Nginx tarafında HSTS'i şöyle etkinleştirebilirsiniz:

    server {
        listen 443 ssl http2;
        server_name sirketiniz.com;
    
        ssl_certificate     /etc/letsencrypt/live/sirketiniz.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/sirketiniz.com/privkey.pem;
    
        # Tarayıcıyı 2 yıl boyunca yalnızca HTTPS'e zorla
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    }
    

    Sıkça Sorulan Sorular#

    CAA kaydı olmadan SSL sertifikası alabilir miyim?#

    Evet, kesinlikle alabilirsiniz. CAA kaydı bulunmayan bir alan adı, tüm sertifika otoritelerine açık kabul edilir ve herhangi bir CA sertifika üretebilir. CAA kaydı zorunlu değildir; yalnızca hangi otoritelerin sertifika basabileceğini kısıtlamak istediğinizde eklersiniz. Ancak güvenlik açısından en az bir CAA kaydı tanımlamak, yetkisiz üretim riskini ciddi biçimde azalttığı için tavsiye edilir.

    CAA kaydı mevcut sertifikalarımı etkiler mi?#

    Hayır, mevcut ve halihazırda kurulu sertifikalarınıza hiçbir etkisi olmaz. CAA kaydı yalnızca yeni sertifika üretimi ve yenileme anında kontrol edilir. Zaten geçerli olan bir sertifika, siz CAA politikanızı değiştirseniz bile çalışmaya devam eder. Ancak dikkat etmeniz gereken nokta şudur: sertifikanız yenilenirken CAA yeniden sorgulanır, bu yüzden yenileme öncesinde CA'nızın listede olduğundan emin olun.

    Birden fazla sertifika otoritesine izin verebilir miyim?#

    Evet, her otorite için ayrı bir issue satırı ekleyerek istediğiniz kadar CA'yı yetkilendirebilirsiniz. Örneğin Let's Encrypt ve DigiCert'i birlikte kullanıyorsanız, iki ayrı CAA kaydı tanımlarsınız ve her ikisi de sertifika üretebilir. Bu esneklik, birincil sağlayıcınızda bir sorun çıktığında yedek bir otoriteye geçebilmenizi sağlar. Yalnızca gerçekten kullandığınız otoriteleri listelemeye özen gösterin; gereksiz CA'lar saldırı yüzeyini genişletir.

    CAA değişikliği ne kadar sürede etkinleşir?#

    Değişiklik, DNS kaydınızın TTL (Time To Live) değerine ve otoritenin önbellek davranışına bağlıdır. Genellikle birkaç dakika ile birkaç saat arasında yayılır. Yeni bir CA eklemeden ya da mevcut politikayı değiştirmeden önce TTL değerini geçici olarak düşük tutmak (örneğin 300 saniye) iyi bir uygulamadır, böylece değişiklik hızla yansır. Sertifika üretmeden önce dig CAA alanadınız.com +short komutuyla kaydın güncel değerini mutlaka doğrulayın.

    issue ve issuewild etiketlerini aynı anda kullanmam gerekir mi?#

    Zorunlu değildir, ancak wildcard sertifika üretimini ayrı yönetmek istiyorsanız gereklidir. Eğer yalnızca issue tanımlarsanız, wildcard talepleri de bu listeye göre değerlendirilir. issuewild eklediğinizde ise wildcard talepleri artık yalnızca issuewild listesine bakar. Wildcard sertifika kullanmıyorsanız, issuewild ";" ekleyerek tüm wildcard üretimini engellemek güçlü bir sıkılaştırma sağlar ve kurumsal ortamlarda sıkça tercih edilir.

    CAA kaydı DNSSEC olmadan güvenli midir?#

    CAA kaydı DNSSEC olmadan da faydalıdır ve pratikte yaygın olarak bu şekilde kullanılır, ancak ideal olan ikisini birlikte kullanmaktır. DNSSEC, CAA yanıtının yolda değiştirilmediğini kriptografik olarak garanti eder; bu olmadan gelişmiş bir saldırgan teorik olarak CAA sorgusunu manipüle etmeye çalışabilir. Kritik altyapılarda hem CAA hem DNSSEC'i birlikte etkinleştirmek, DNS katmanının bütünlüğünü tam anlamıyla sağlar.

    Kapanış#

    CAA kaydı, tek bir DNS satırıyla kurulabilen ama sertifika güvenliğinize orantısız derecede büyük katkı sağlayan bir mekanizmadır. issue ile tekil sertifikaları, issuewild ile wildcard sertifikaları yetkilendirir, iodef ile de ihlal denemelerinden haberdar olursunuz. Doğru yapılandırıldığında, alan adınıza yalnızca sizin izin verdiğiniz otoriteler sertifika basabilir; yetkisiz üretim daha ilk adımda reddedilir. DNSSEC, Certificate Transparency izleme ve HSTS ile birleştiğinde ise sağlam, çok katmanlı bir SSL savunması elde edersiniz.

    Bu tür sıkılaştırmaları kendiniz kurmak yerine uzman bir ekibin yönetmesini istiyorsanız, Clou.TR olarak yanınızdayız. DNS yönetiminin tamamen size ait olduğu hosting paketlerimiz, tam kontrol sunan sanal sunucularımız ve uçtan uca SSL çözümlerimiz ile CAA dahil tüm güvenlik kayıtlarını dakikalar içinde yapılandırabilirsiniz. Alan adınızı Clou.TR üzerinden yönetiyorsanız, CAA kaydını panelden birkaç tıkla ekleyerek sertifika güvenliğinizi bugün bir üst seviyeye taşıyabilirsiniz.

    DNSCAA KaydıSSL

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.