CAA Kaydı Nedir? SSL Sertifikasını DNS ile Sınırlama
CAA — Certification Authority Authorization — bir alan adına SSL/TLS sertifikası verebilecek sertifika otoritelerini DNS düzeyinde belirleyen bir kayıt türüdür. Yanıt doğrudan zone dosyasında saklanır: hangi CA, bu domain için sertifika imzalamaya yetkilidir? Her sertifika otoritesi, sertifika vermeden önce hedef domainin DNS zone'unu sorgulamak ve geçerli bir CAA kaydı varsa onun izin verdiği sınırlar içinde kalmak zorundadır. Bu zorunluluk 2017'de CA/Browser Forum kararıyla tüm CA'lar için standart hale gelmiş; RFC 8659 ise 2019'da teknik çerçeveyi netleştirmiştir.
CAA, sertifika doğrulama sürecinin içinde değil, önündedir. DV (Domain Validation), OV veya EV tipinde bir sertifika talep edildiğinde seçilen CA, sertifikayı imzalamadan önce zone dosyasına bakar. CAA kaydı yoksa herhangi bir CA kendi doğrulama süreciyle sertifika verebilir; kayıt varsa ve CA kendi domain değerini listede görmüyorsa talebi reddeder. Domain sahibi bu mekanizma aracılığıyla SSL ekosisteminin geniş CA havuzunu DNS politikasıyla süzer.
Bu kısıtlamanın değeri iki noktada netleşir. Birincisi, misissuance riskini azaltmak: bir CA'nın doğrulama sürecinde hata yapması ya da kandırılması sonucu verilen yetkisiz sertifikaları engellemek. İkincisi, kurumsal ortamlarda hangi CA'nın kullanılacağını merkezi DNS politikasına bağlamak; böylece sertifika temin kararları sistem yöneticisi seviyesinde dağılmak yerine zone dosyasında kontrol altında tutulur. CAA, DNSSEC veya benzeri kapsamlı bir güvenlik katmanı değildir — A, CNAME, MX gibi standart DNS kayıtlarıyla birlikte zone dosyasının bir parçasını oluşturur ve yalnızca sertifika verme yetkisini hedef alır.
CAA kaydının söz dizimi ve alan yapısı
Bir CAA kaydı üç zorunlu alandan oluşur: flags (bayrak), tag (etiket) ve value (değer). Standart biçimi şu şekildedir:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"Soldaki 0 bayrak değeridir. Günümüzde yalnızca iki değer geçerlidir: 0 ve 128. 128 değeri "kritik" bayrağını temsil eder ve bir CA'nın tanımadığı bir tag ile karşılaştığında kaydı yok saymak yerine sertifika vermekten kaçınmasını zorunlu kılar. Pratikte neredeyse tüm CAA uygulamaları 0 kullanır; 128 değeri, yeni ya da henüz yaygınlaşmamış direktifler için geriye dönük uyumluluğu tehlikeye atmadan bir güvenlik kapısı işlevi görür.
Orta alandaki tag, kaydın ne tür bir kısıtlama getirdiğini belirtir. Üç geçerli tag bulunur: issue, issuewild ve iodef. Her biri farklı bir sertifika senaryosunu ya da bildirim mekanizmasını kontrol eder. Tırnak içindeki son alan ise CA'nın kamuoyuna açık CAA domain değerini taşır. Let's Encrypt için "letsencrypt.org", DigiCert için "digicert.com", Sectigo için "sectigo.com" kullanılır. Bazı CA'lar birden fazla geçerli değer tanımlar; Amazon Certificate Manager örneğinde hem "amazon.com" hem "amazonaws.com" hem de "amazontrust.com" geçerli sayılır. Kullanılacak CA'nın güncel dokümantasyonundan doğru değerin teyit edilmesi gerekir.
TTL için 3600 saniye yaygın bir değerdir. Sertifika alım sürecinde CAA kaydını değiştirmeniz gerekirse geçici olarak daha kısa bir TTL — örneğin 300 saniye — değişikliğin hızlı yayılmasını sağlar. Güncellemeden önce TTL'yi düşürmek, eski değerin önbellekte bekleme süresini kısaltacağından TTL değeri optimizasyonu sürecine dikkat etmek faydalıdır.
issue ile issuewild direktifleri arasındaki fark
issue tag'i, belirtilen CA'ya alan adı için sertifika verme yetkisi tanır. Eğer zone'da issuewild kaydı tanımlı değilse, issue wildcard sertifikaları (*.example.com) da kapsar. Bu durumda yalnızca issue "letsencrypt.org" kaydı olan bir domain için Let's Encrypt, hem example.com hem de *.example.com sertifikası verebilir.
issuewild ise yalnızca wildcard sertifikaları denetler. Aynı zone'da hem issue hem issuewild bulunuyorsa, wildcard kararı için issue devre dışı kalır; yalnızca issuewild geçerli olur. Bu etkileşim, birden fazla CA ile çalışan yapılarda beklenmedik sertifika ret durumlarına yol açabilir.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "digicert.com"Bu konfigürasyonda Let's Encrypt yalnızca example.com ve www.example.com gibi normal sertifikalar için yetkilidir. *.example.com wildcard talebi için artık yalnızca DigiCert geçerlidir; issue satırındaki Let's Encrypt bu yetkiye sahip değildir — issuewild kaydının varlığı, wildcard kararında issue kaydını tamamen devre dışı bırakır.
Tersine, zone'da yalnızca issue "letsencrypt.org" varsa ve hiç issuewild tanımlı değilse, Let's Encrypt hem normal hem wildcard sertifika verebilir. issuewild ";" veya issuewild "" biçiminde boş bir değer ise tüm CA'ların wildcard sertifika vermesini engeller — issue kaydında adı geçen CA dahil. Çünkü artık wildcard için özel bir kural aktiftir ve bu kural hiçbir CA'ya izin vermemektedir.
Birden fazla CA iznini doğru tanımlamak
Bir zone'da birden fazla issue kaydı bulunabilir. Her satır ayrı bir CA için izin ekler ve kayıtlar kümülatif etki yaratır; herhangi bir sıralama öncelik anlamı taşımaz. Her CA, kendi domain değerinin listede olup olmadığına bakarak karar verir.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issue "comodoca.com"Bu üç satır, üç CA'nın da sertifika verebileceği anlamına gelir. Tek bir kayıt satırında birden fazla CA belirtmek desteklenmez; her CA için ayrı bir kayıt oluşturulmalıdır. DNS yönetim panellerinin büyük çoğunluğu CAA kaydını tip + etiket + değer şeklinde üç ayrı alan olarak sunar, bu nedenle yeni bir CA eklemek yeni bir kayıt girişi anlamına gelir. Cloudflare DNS panelinde kayıt ekleme formunu incelerseniz bu ayrımı doğrudan görebilirsiniz.
Bazı CA'lar, sertifikayı yalnızca belirli bir ACME hesabına kısıtlamak için accounturi parametresini destekler. Bu parametre, CAA değerinin sonuna noktalı virgül ve boşlukla eklenerek kullanılır:
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456"Bu konfigürasyon, sertifika alımını yalnızca belirtilen ACME hesap ID'siyle sınırlar. Let's Encrypt bu parametreyi destekler; ancak her CA'nın implementasyonu farklılık gösterir. Otomasyon ortamlarında birden fazla sunucunun aynı ACME hesabını kullanmadığı durumlarda veya izinsiz sertifika taleplerini engellemek istediğinizde accounturi ekstra bir kontrol noktası sağlar. issuewild için de aynı çoğaltma mantığı geçerlidir: birden fazla CA'ya wildcard sertifika yetkisi vermek istiyorsanız her biri için ayrı bir issuewild satırı tanımlanmalıdır.
iodef ile ihlal bildirimi kurma
iodef tag'i, bir CA'nın yetkisiz sertifika talebiyle karşılaştığında bildirimi göndereceği adresi tanımlar. Değer, mailto: veya https:// ile başlayan bir URL'dir.
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
example.com. 3600 IN CAA 0 iodef "https://example.com/caa-report"RFC 8659 kapsamında CA'ların bu bildirimleri göndermesi önerilir ancak zorunlu tutulmaz. Büyük CA'lar genellikle mailto: adresini tanır; HTTPS URL'leri ise daha yapılandırılmış, makine tarafından işlenebilir raporlama için kullanılır. Hem mailto: hem de https:// kaydı aynı anda tanımlıysa CA her ikisine de bildirim gönderebilir — bu çift bildirimi destekleyen CA'lar için ek bir güvence katmanı oluşturur.
Pratikte bazı CA'lar iodef bildirimlerini aktif olarak göndermez ya da yalnızca belirli koşullarda tetikler. iodef kaydının var olması, her misissuance girişiminin e-postayla bildirileceğinin garantisi değildir. Bununla birlikte iodef tanımlamak kurumsal CAA politikasının anlamlı bir tamamlayıcısıdır: bir CA'nın anomali tespit ettiği durumda bildirim göndereceği adres hazır olur ve bu yapı dış denetimler veya güvenlik politikası belgeleri için somut bir kanıt noktası oluşturur.
Zone davranışı: kayıt yokluğu ve boş değer
CAA kaydının zone'da hiç bulunmaması ile kasıtlı olarak boş değer atanması arasında anlamlı bir davranış ayrımı vardır; ikisini karıştırmak beklenmedik sonuçlara yol açar.
CAA kaydı yoksa herhangi bir CA kendi doğrulama süreci aracılığıyla domain için sertifika verebilir. Bu, CAA zorunluluğu öncesindeki evrensel izin durumudur. Kişisel web siteleri ve küçük projeler genellikle bu konumda kalır — eksik bir yapılandırma değil, yalnızca kısıtlama getirilmemiş bir durumdur.
issue ";" biçiminde boş değer ise tüm CA'ların ilgili sertifika türü için yetkisiz olduğunu açıkça bildirir. Park edilmiş domainler veya SSL sertifikası kullanılmaması gereken alt alanlar için tercih edilen yaklaşımdır:
parked.example.com. 3600 IN CAA 0 issue ";"
parked.example.com. 3600 IN CAA 0 issuewild ";"Bu iki satır birlikte hem normal hem wildcard sertifika verilmesini tamamen engeller. Yalnızca issue ";" varken issuewild hiç tanımlı değilse, wildcard için CA'nın referans alacağı açık bir kural yoktur; bu durumda CA'nın davranışı implementasyona göre farklılık gösterebilir. Belirsizliği ortadan kaldırmak için her iki kaydı açıkça tanımlamak, daha güvenilir bir yaklaşımdır.
CAA kaydının miras (inheritance) davranışı da dikkat gerektirir. Bir CA, sub.example.com için CAA sorguladığında ve bu alt alan için kayıt bulamazsa bir üst seviye olan example.com'a çıkar ve orada tanımlı kaydı referans alır. Bu kaskad davranış RFC 8659'da belgelenmiştir. Subdomain yapılandırması yaparken alt alan bazında farklı CA politikaları uygulanacaksa, ilgili alt alana ait CAA kayıtlarını açıkça tanımlamak gerekir; yoksa üst domainin kuralları otomatik olarak devreye girer.
DNS panelinde CAA kaydı oluşturma ve doğrulama
Çoğu modern DNS yönetim paneli CAA kaydını doğrudan destekler. Cloudflare, AWS Route 53 ve cPanel gibi araçlarda "CAA" türü seçilir, ardından flags (0), tag ve değer alanları ayrı kutulara girilir. Bazı eski paneller CAA türünü ayrıca sunmayabilir; bu durumda kayıt type 257 koduyla ham DNS biçiminde girilebilir — wire format değerinin sağlayıcı dokümantasyonundan doğrulanması gerekir.
DNS propagasyonu tamamlandıktan sonra kaydı doğrulamak için dig komutunu kullanabilirsiniz:
dig CAA example.com +shortYanıt şu biçimde döner:
0 issue "letsencrypt.org"
0 issue "digicert.com"Boş yanıt, zone'da CAA kaydının bulunmadığı anlamına gelir. Windows ortamında PowerShell ile de sorgulama yapılabilir:
Resolve-DnsName -Name example.com -Type CAALet's Encrypt ile sertifika alınmadan önce konfigürasyonu test etmek için certbot'un --dry-run seçeneği değerlidir. Bu mod, ACME protokolü üzerinden CAA kontrolünü de kapsayan doğrulama adımlarını gerçek sertifika vermeden çalıştırır ve varsa hata mesajı döndürür. CAA nedeniyle reddedilen talepler genellikle urn:ietf:params:acme:error:caa hata kodu ile bildirilir; bu kod, ret kararının zone dosyasındaki bir kısıtlamadan geldiğini açıkça gösterir ve sorunun kaynağını hızlıca belirlemenizi sağlar.
DNS yanıtlarının bütünlüğü CAA'nın güvenilirliğini de doğrudan etkiler. Zone üzerinde gerçekleştirilecek bir DNS manipülasyonu, CAA kaydını da değiştirebilir. Bu bağlamda DNSSEC yapılandırması, DNS yanıtlarını kriptografik imzayla güvence altına alarak CAA kaydının da manipüle edilmesini önemli ölçüde zorlaştırır.
CAA kaydı kurumsal düzeyde DNS güvenlik mimarisi için küçük ama belirleyici bir bileşendir. SSL sertifika altyapısını merkezileştirmek veya belirli CA'larla sınırlı tutmak isteyen yapılar için net bir politika aracı sunar; tek CA kullanan bireysel veya küçük siteler açısından ise zorunlu olmaktan çok iyi pratik olma niteliği taşır.
Kayıt sözdizimi görece basit olsa da issuewild ile issue etkileşimi ve kaskad miras davranışı, gözden kaçırılması kolay ayrıntılar barındırır. CA ile imzalanacak ilk sertifikadan önce dig CAA çıktısını doğrulamak ve subdomain bazında istenmeyen miras durumlarını ele almak, sonradan yaşanabilecek sertifika redlerini önceden engeller.
CAA'nın kapsam sınırını da hatırlamakta fayda var: yalnızca sertifika verme yetkisini kısıtlar. Sertifikanın tarayıcıya nasıl sunulduğu, sertifika zincirinin geçerliliği ya da HTTPS yönlendirme davranışı bu kaydın kapsamı dışındadır. Bu açıdan CAA, TXT tabanlı domain doğrulama mekanizmalarını tamamlayan ama onların yerini almayan bir katmandır; her ikisi de DNS zone'u üzerinden farklı güvenlik hedeflerine hizmet eder.