CAA Yetkisi Sertifika Yenilemeyi Nasıl Etkiler?
ACME istemcisi alan adı kontrolünü doğrulayabilse de CAA politikası seçilen sertifika otoritesine izin vermiyorsa yeni sertifika düzenlenemeyebilir. Örneğin wildcard isteğinde geçerli issuewild kümesi yalnız başka bir CA’yı yetkilendiriyorsa, issue içindeki Let’s Encrypt izni bu isteği kurtarmaz. Bu iki kontrolü ayrı değerlendirmek, yenileme hatasında yanlış katmanı değiştirmeyi önler.
Bu rehber, web TLS sertifikaları için CAA kayıtlarının nasıl seçildiğini ve issue, issuewild, iodef etiketlerini açıklar. Let’s Encrypt ve ZeroSSL örnekleriyle çoklu CA, hesap kısıtı ve wildcard politikasını karşılaştırır. Örnek kayıt kümeleri alternatif politikalardır; birini seçerken önce mevcut kümenin tamamını ve otomasyonun ihtiyaçlarını inceleyin.
İlk adım, sertifikadaki tüm adları, bu adların gerçek TLS sonlandırma noktalarını ve kullanılan CA hesaplarını çıkarmaktır. Bir sertifikada hem example.com hem *.example.com bulunuyorsa seçilen CA her ikisi için de yetkili olmalıdır. CAA kaydının doğru görünmesi, istemcinin doğru CA’ya bağlandığını veya yenilenen sertifikanın CDN, yük dengeleyici ya da sunucuya yüklendiğini göstermez.
CAA’nın Kapsamı ve DNSSEC’ten Farkı
CAA (Certification Authority Authorization), DNS üzerinden sertifika düzenleme yetkisini belirtir. Kurallara uyan CA, her istenen adın ilgili kayıt kümesini değerlendirir; uygulanabilir bir düzenleme kısıtı bulunmuyorsa CAA açısından engel yoktur. İzin bulunması alan adı doğrulamasını, CA politikasını veya diğer başvuru koşullarını kaldırmaz. CAA, hatalı düzenleme riskini azaltır; bütün saldırıları engelleyen veya mevcut sertifikaları otomatik iptal eden bir mekanizma değildir.
CAA araması ilk boş olmayan CAA kayıt kümesinde durur. Basit, aliasesiz durumda shop.example.com’da CAA yoksa example.com sorgulanır; o da boşsa üst adlarla devam edilir. Alt alanda bir küme bulunduğunda üst küme ile izinler birleştirilmez. Bu nedenle yalnız iodef içeren bir alt alan kümesi bile üstteki issue kısıtını taşımayabilir. Alt alana kayıt eklemek başlı başına daha sıkı politika anlamına gelmez.
DNSSEC, geçerli bir güven zinciriyle doğrulanan DNS yanıtının kaynağını ve bütünlüğünü korur. CAA ise sertifika düzenleme politikasını ifade eder. DNSSEC, CAA kaydının içeriğini sizin yerinize seçmez; CAA da DNS yanıtını imzalamaz. Hatalı DS veya imza yapılandırmasının doğrulama hatasına ve dolayısıyla sertifika düzenleme sorununa yol açabileceğini hesaba katın. İki mekanizmayı ayrı ayrı izleyin.
issue, issuewild ve iodef Nasıl Çalışır?
Standart bölge dosyasında bir CAA kaydı ad, TTL, sınıf, CAA türü, bayrak, etiket ve tırnak içindeki değerden oluşur. Örneğin example.com. 3600 IN CAA 0 issue "letsencrypt.org" bir saat TTL ile Let’s Encrypt yetkisi bildirir. DNS panelleri bu alanları ayrı isteyebilir; tam bölge satırını doğrudan değer kutusuna yapıştırmayın. Her issue veya issuewild satırı en fazla bir CA kimliği içerir; düzenlemeyi yasaklayan örneklerde düzenleyici değeri boştur. iodef ise CA kimliği değil, rapor hedefi içerir.
issue normal alan adlarının düzenleme yetkisini belirler. İlgili kümede hiç issuewild yoksa wildcard isteklerinde de issue kullanılır. Aynı etikette birden fazla izin toplamsaldır: bunlardan biri koşullarıyla CA’ya izin veriyorsa diğer satırdaki boş düzenleyici bu izni iptal etmez. İzinlerin altına issue ";" eklemek ek bir yasak katmanı oluşturmaz.
issuewild varsa wildcard yetkisi için issue yerine kullanılır; normal adların kontrolüne uygulanmaz. Örneğin example.com. 3600 IN CAA 0 issuewild "sectigo.com", o kümede wildcard düzenlemesini bu kimliğe yetkilendirir. ZeroSSL’in belgelediği kimlik sectigo.com değeridir; zerossl.com kullanılmamalıdır. Wildcard adının başındaki *. kaldırılarak ilgili CAA kümesi aranır.
iodef, CA’nın desteklemesi hâlinde ihlal raporları için iletişim hedefi belirtir; düzenleme izni vermez ve rapor garantisi sağlamaz. mailto:cert-notify@example.com e-posta ile IODEF raporuna, HTTPS adresi ise RFC 6546 ile tanımlı web hizmeti aktarımına yöneliktir. Herhangi bir JSON webhook’unun uyumlu olduğunu varsaymayın. CA desteğini ve alıcı protokolünü doğrulayın.
accounturi ve validationmethods parametreleri, destekleyen CA için ilgili yetkilendirme satırını sınırlar. Let’s Encrypt bu parametreleri destekler; yöntem adları http-01, dns-01 ve tls-alpn-01 olabilir. Gerçek ACME hesap URI’sini kullanın. Aynı CA’yı koşulsuz yetkilendiren başka satır varsa hesap kısıtı bütün politikayı kilitlemez; bütün ilgili izinleri birlikte incelemek gerekir.
Let’s Encrypt ve ZeroSSL İçin CAA Örnekleri
Aşağıdaki alternatif küme, normal ve wildcard adlar için hem Let’s Encrypt’i hem ZeroSSL’in kullandığı Sectigo kimliğini yetkilendirir. iodef satırı isteğe bağlı rapor hedefidir. Bu izinler iki sağlayıcıya başvuru imkânı verir; istemcinin hangisini seçeceğini belirlemez. Wildcard ve normal adlarda aynı izinler istendiğinde issuewild zorunlu değildir, burada kapsamı açık göstermek için yazılmıştır.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "sectigo.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "sectigo.com"
example.com. 3600 IN CAA 0 iodef "mailto:cert-notify@example.com"
Farklı bir politika olarak normal adları Let’s Encrypt’e, wildcard adları ZeroSSL/Sectigo’ya ayırmak için aşağıdaki iki satır kullanılabilir. Bu, önceki kümenin yerine geçecek bir alternatiftir. Aynı sertifikada example.com ve *.example.com istenirse iki CA’dan hiçbiri iki adın tamamına yetkili değildir; ayrı siparişler kullanın veya seçilen CA’yı her iki kapsam için yetkilendirin.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "sectigo.com"
Yalnız kendi Let’s Encrypt hesabınızın DNS-01 ile düzenleme yapmasını istiyorsanız aşağıdaki ayrı alternatifi değerlendirin. 12345678 örnek değerdir; hesap URI’sini istemcinin gerçek üretim hesabıyla değiştirin. Hem issue hem issuewild kısıtlıdır. Bu kümeyi önceki koşulsuz izinlere eklemek kısıtı etkisiz bırakabilir. Sectigo’nun güncel belgesi ek kısıtlayıcı parametreleri desteklemediğini belirttiği için aynı parametreleri onun satırına taşımayın.
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
Let’s Encrypt CAA rehberi kimlik ve parametre desteğini açıklar. ZeroSSL belgeleri içinden “Invalid CAA Records” yardım başlığındaki sectigo.com örneklerini doğrulayın. Cloudflare CAA referansı ise Universal SSL kapsamında otomatik eklenen kayıtları ve ürün farklılıklarını açıklar. Panelde görünen satırlar gerçek DNS yanıtının tamamı olmayabilir; koşulsuz ek izinler hesap kısıtını zayıflatabileceğinden yönetilen TLS hizmetinin davranışını inceleyin.
Çoklu CA ve ACME Geçiş Planı
Çoklu CA, bir sağlayıcıdaki düzenleme sorunu sırasında alternatif sağlayıcıyı kullanma seçeneği sağlayabilir. Ancak aynı DNS kesintisi veya hatalı alan adı doğrulaması iki sağlayıcıyı da etkileyebilir. İkinci CA’yı yetkilendirmek, ikinci hesabı ve gerekli sözleşme, kota, EAB veya doğrulama koşullarını hazırlamaz. Yedekli tasarımın maliyeti; ek hesapların, anahtarların, yenileme durumunun ve dağıtım yolunun işletilmesidir.
Birincil CA ve geçiş koşullarını ACME otomasyonunda açıkça tanımlayın. DNS, CAA veya hesap hatasında sınırsız tekrarlar yerine hata türünü kaydedin, bekleme ve deneme sınırı uygulayın. ACME otomasyonunda yedekli CA rehberi istemci tarafını ele alır. Buradaki CAA izinleri o planın yalnız DNS ayağıdır; seçilen istemci sürümünün hesap, sağlayıcı ve dağıtım desteğini ayrıca doğrulayın.
Wildcard yönetimini ayrı bir CA veya hesapta toplamak somut bir işletim gereksinimini karşılayabilir; otomatik olarak daha güvenli veya daha sorunsuz değildir. Let’s Encrypt wildcard için DNS-01 ister. Diğer ürünlerin kabul ettiği doğrulama yollarını kendi belgelerinden kontrol edin. Normal adlar ile wildcard’ı ayırırken aynı sertifikadaki tüm SAN’ları ve paylaşılan özel anahtar yetkisini hesaba katın.
Hesap kısıtı CA’nın desteklediği biçimde uygulanır ve hesap anahtarı yönetiminin yerini almaz. Kısıtlı hesabın anahtarı kaybolursa yeni hesabın URI’si farklı olabilir; politika değişmeden yenileme başarısız olabilir. Planlı geçişte gerekli yeni hesabı yetkilendirin, işlemi doğrulayın ve eski yetkiyi kaldırın. Yetkisiz hesapla başarılı başvuruyu engelleme amacıyla yazılan kısıtın yanında koşulsuz aynı CA izni bırakmayın.
CAA Araması, CNAME ve Önbellek Süreleri
TTL değişikliği önbellekleri temizlemez. Kısa TTL’ye geçmek istiyorsanız bunu önceden yapın ve daha önce yayımlanan uzun TTL’nin etkisini bekleyin. Olmayan kayıt yanıtları ayrıca negatif önbelleğe alınabilir; bunun süresi ilgili SOA verilerinden etkilenir. Yetkili sunucuların güncellenmesi ile CA’nın recursive çözümleyicisinin yeni yanıtı görmesi aynı an değildir. Evrensel bir “beş dakikada yayılır” süresi vermeyin.
Alt alana özel CAA kümesi, bulunduğunda üst politikanın yerini alır; üst izinlere eklenmez. Örneğin shop.example.com için ayrı issue izni tanımlamak o dalın etkin kümesini değiştirebilir. Bunun istenen tüm normal ve wildcard adlara etkisini kontrol edin. Yalnız bildirim adresi ekleyip mevcut kısıtların otomatik miras kalacağını varsaymak, fark edilmeden izinleri genişletebilir.
RFC 8659’da her aday ad için normal CAA DNS sorgusu yapılır ve bu sorgu CNAME alias’larını izler. Sonuç boş değilse arama durur; boşsa başlangıçtaki adayın sol etiketi çıkarılarak üst adı sorgulanır. Alias hedefinin üst alanlarına otomatik ayrı bir politika yürüyüşü yapılmaz. Bulunan kümeler birleştirilmez. Aynı kayıt sahibi adında CNAME ile CAA birlikte bulunamayacağı için sağlayıcıya yönlenen adlarda CAA politikasını hizmetle koordine edin.
Kritik bayrak ondalık 128 değeridir. CA, ilgili kümede bu bayrağı taşıyan tanımadığı veya desteklemediği bir özellik etiketi görürse düzenlememelidir. Bu, her bilinmeyen parametrenin bütün CA’larda zorla uygulanması anlamına gelmez. Örneklerde bayrak 0’dır; accounturi desteğini yalnız kritik bayrak ekleyerek elde etmeye çalışmayın.
iodef hedefinin sorumlusu ve rapor işleme yolu tanımlı olsun. HTTPS için uygun IODEF aktarımı destekleyen alıcı gerekir; sıradan iç webhook uygun olmayabilir. Rapor gönderilmese de ACME hataları, kalan sertifika ömrü ve dağıtılan sertifika bağımsız olarak izlenmelidir. Certificate Transparency gözlemleri ise beklenmedik kamusal sertifikaları araştırmaya yardımcı olabilir; iodef yerine garantili bildirim kanalı sayılmaz.
CAA Politikasını ACME Otomasyonuyla Eşleştirme
Otomasyonun seçtiği CA, hesap ve doğrulama yöntemi CAA’daki koşullarla eşleşmelidir. Geçişte ikinci CA’dan alınan zincirin hedef istemcilerle uyumluluğunu ve sunucudaki anahtar/sertifika eşleşmesini kontrol edin. Başarılı düzenleme, dosyanın doğru sunucuya dağıtıldığını göstermez. CDN veya yük dengeleyici TLS’i sonlandırıyorsa sertifikayı o noktadan yeni bağlantıyla doğrulayın.
Wildcard için DNS-01 ve normal adlar için HTTP-01 seçilecekse bu ayrımı destekleyen istemci ve CA yapılandırması gerekir. Let’s Encrypt’te HTTP-01 port 80 üzerinden erişilebilir challenge yanıtı ister ve wildcard vermez. DNS-01’de sınırlı DNS yetkileri, gerçek challenge adı, yayılım bekleme ve eşzamanlı TXT değerlerini koruyan temizlik önemlidir. CAA yönteme izin verebilir; challenge yanıtını oluşturmaz.
Üretim öncesinde kayıt sözdizimini, bütün yetkili DNS sunucularını ve recursive yanıtları kontrol edin. CA’nın sunduğu ve istemcinin desteklediği test ortamını kullanın. Her sağlayıcının staging sunucusu olduğu veya aynı hesap/CAA koşullarını paylaştığı varsayılmamalıdır. Staging başarılı olsa bile üretim hesabı, kota ve güven zinciri farklı olabilir. Test sertifikasını canlı sertifikanın yerine dağıtmayın.
Alt Alan ve SaaS İçin Uygulama Senaryoları
Geliştirme dalında Let’s Encrypt normal adlarına izin verip wildcard düzenlemesini kapatmak için dev.example.com kümesinde issue "letsencrypt.org" ile issuewild ";" birlikte tanımlanabilir. Yalnız issue eklemek wildcard’ı kapatmaz; issuewild yoksa aynı issue izni wildcard’a da uygulanır. Üretim için ayrı wildcard politikasının hangi adlarda ilgili küme olacağını ayrıca kontrol edin.
Müşteri alan adlarını bağlayan SaaS’ta HTTP-01 seçilecekse müşteri yetkisi, alan adının doğru yönlenmesi ve bütün olası ön uçlarda port 80 challenge erişimi gerekir. Uygun Let’s Encrypt yetkisinde validationmethods=http-01 kullanılabilir; bu kısıt wildcard düzenlemeye uygun değildir. SaaS özel alan adları ve DNS-01 otomasyonu rehberi alternatif DNS doğrulama mimarisini açıklar. Uygulama CNAME’i tek başına yenilemede de çalışan bir doğrulama yolu kurmaz.
Harici hizmete CNAME ile bağlanan bir alt alanda yanına CAA eklemeyin. Önce alias sorgusunun hangi CAA kümesini döndürdüğünü ve hizmetin hangi CA’ları gerektirdiğini belirleyin. Hedefte küme varsa üst alanınızdaki izinler bununla birleşmez. Yönetilen sağlayıcının otomatik CAA eklemesi veya sertifika ürünü, kendi hesap kısıtı hedefinizle uyuşmuyorsa çözümü DNS mimarisi ve hizmet desteği düzeyinde planlayın.
CAA Hatalarını Teşhis Etme
Başvurudaki tüm SAN’ları, tam alan adını ve wildcard ayrımını kontrol edin. dig +noall +answer +comments CAA example.com yanıt ve durum bilgisini gösterir; aynı sorguyu ilgili alt adlara uygulayın. Tek bir dig sorgusu RFC 8659’un üst ad yürüyüşünü sizin yerinize tamamlamaz. CNAME yanıtını, her adayın boş/boş olmayan CAA sonucunu ve SERVFAIL gibi hataları ayrı kaydedin.
Wildcard reddinde önce issuewild var mı bakın. Varsa o kümedeki wildcard izinlerini, yoksa issue izinlerini değerlendirin. CA kimliği, accounturi, doğrulama yöntemi ve istemcinin gerçek hesabı eşleşmelidir. CAA yetkisi uygun olduğu hâlde DNS-01 challenge başarısızsa DNS erişimi ve TXT yanıtlarını araştırın; bunu otomatik olarak CAA hatası diye sınıflandırmayın. Yetkili sunucular arasında farklı yanıtlar da aralıklı hataya yol açabilir.
İstemci günlüğünde tarih, CA uç noktası, hesap kimliği, istenen adlar ve dönen hata türünü ilişkilendirin; özel anahtar veya DNS API sırrını rapora koymayın. Kendi istemci günlüğünüz her CA iç DNS sorgusunu göstermeyebilir. iodef raporu gelirse ek kanıt olarak kullanın, gelmemesini başarı saymayın. Mevcut sertifikanın kalan süresi azalıyorsa hatayı giderirken kontrollü alternatif düzenleme ve dağıtım planını izleyin.
CAA Değişikliklerini Doğrulama ve Sürdürme
Hiçbir CA’nın yeni sertifika düzenlemesini istemediğiniz bir ad için aşağıdaki küme ayrı bir alternatiftir. Aynı ilgili kümede izin veren issue veya issuewild satırları bulunmamalıdır. Bu kayıtları mevcut izinlerin sonuna eklemek onları geçersiz kılmaz; ayrıca başka adlarda seçilen alt kümelerin kapsamını değiştirmez. CAA değişikliği mevcut sertifikayı iptal etmez; anahtar ihlalinde yeni anahtar, değiştirme ve CA iptal süreci gerekir.
example.com. 3600 IN CAA 0 issue ";"
example.com. 3600 IN CAA 0 issuewild ";"
Değişiklik kaydında amaçlanan CA ve hesapları, normal/wildcard kapsamını, ilgili DNS yanıtlarını ve doğrulama sonuçlarını tutun. Yeni kayıtlar yayımlandıktan sonra hem birincil hem gerekli yedek yolun çalışmasını ve gerçek TLS sonlandırma noktasındaki sertifikayı doğrulayın. CA desteği, hesaplar veya yönetilen hizmet değiştiğinde politikayı yeniden değerlendirin. iodef’i isteğe bağlı ek raporlama olarak tutarken yenileme ve süre izlemeyi sürdürün.
