Alan adınız için geçerli HTTPS sertifikası alabilen tek kurum, bugün kullandığınız sertifika sağlayıcısı değildir. Genel DNS’te varsayılan olarak her kamu sertifika otoritesi, alan adı kontrolünü doğrulayabilirse sertifika düzenleyebilir. CAA kaydı bu yüzeyi daraltır: “Bu alan adı için hangi sertifika otoritelerine izin veriyorum?” sorusunun cevabını DNS’e yazarsınız. Küçük bir kayıt güçlü kontrol sağlar; yanlış yazılırsa yenilemeyi durdurabileceği için körlemesine eklenmemelidir.

CAA kaydı ne yapar, ne yapmaz?

Certificate Authority Authorization, alan adı sahibinin sertifika düzenlemeye yetkili otoriteleri belirtmesini sağlayan DNS kayıt türüdür. Let’s Encrypt belgesine göre güncel yapı RFC 8659 ve RFC 8657 ile standartlaştırılmıştır. Sertifika otoriteleri düzenleme işleminden önce CAA sonucunu kontrol eder. Tarayıcı ise ziyaret sırasında CAA kaydını okuyup bağlantıya onay vermez.

Bu nedenle CAA, mevcut sertifikayı anında iptal etmez; saldırganın DNS veya sunucu erişimini tek başına çözmez ve sertifika şeffaflığı izlemesinin yerine geçmez. Esas faydası, yanlışlık veya bir doğrulama açığı üzerinden istenmeyen başka bir otoriteden yeni sertifika alınabilecek alanı daraltmaktır.

issue ve issuewild farkı

CAA kaydı genellikle bayrak, etiket ve değerden oluşur. Bayrak çoğu kurulumda 0 olur. issue etiketi normal sertifikaları hangi otoritenin düzenleyebileceğini belirtir. Ayrı bir issuewild kaydı yoksa issue wildcard sertifikalar için de etkili olabilir. Wildcard yetkisini farklı düzenlemek istiyorsanız issuewild kullanılır.

Örneğin yalnız Let’s Encrypt’e izin veren temel kayıt mantığı CAA 0 issue "letsencrypt.org" biçimindedir. Birden fazla aynı tür kayıt eklenirse izinler toplanır; kayıtların herhangi biri otoriteye izin veriyorsa o otorite sertifika düzenleyebilir. “İki kayıt daha güvenli olur” diye kullanılmayan otoriteleri eklemek sınırı yeniden genişletir.

Kayıt hangi seviyeye eklenmeli?

Genel yaklaşım CAA’yı kayıtlı ana alan adına eklemektir; böylece alt alanlar ilk buldukları CAA kuralını miras alabilir. Sertifika otoritesi en yakın addan başlayıp yukarı doğru kontrol eder ve bulduğu ilk CAA kümesini kullanır. Bu sayede ana alan için Let’s Encrypt, ayrı bir bulut hizmetindeki api alt alanı için başka otorite tanımlanabilir.

CNAME kullanılan yerde davranış daha dikkat ister. Let’s Encrypt, CAA kontrolünün CNAME yönlendirmesini de izlediğini açıklıyor. CDN, SaaS, mağaza veya e-posta sağlayıcınız kendi hedef alanındaki kurallarla sürece katılabilir. Bu nedenle yalnız DNS panelindeki ana alan kaydına bakıp sonucu varsaymayın; gerçek sorgu zincirini test edin.

WordPress ve hosting müşterisi için risk nerede?

Otomatik SSL kullanan DirectAdmin, cPanel, CyberPanel veya yönetilen WordPress altyapısında sertifika yenilemesi çoğu zaman kullanıcı fark etmeden çalışır. CAA’ya yanlış otorite yazılırsa bir sonraki yenileme başarısız olabilir; hata sertifikanın bitiş gününe kadar görünmez. Özellikle CDN’in edge sertifikasıyla origin sertifikası farklı otoritelerden geliyorsa ikisinin de ihtiyacı anlaşılmalıdır.

Önceki Chrome 154 HTTPS hazırlık rehberinde güvenli bağlantının kullanıcı tarafını ele almıştık. CAA ise sertifikanın kim tarafından üretilebileceğine ilişkin DNS tarafındaki politika katmanıdır. Birbirini tamamlar; biri diğerinin yerine geçmez.

Güvenli kurulum sırası

  1. Mevcut canlı sertifikanın düzenleyicisini ve bitiş tarihini kaydedin.
  2. Hosting paneli, CDN, yük dengeleyici, e-posta ve yedek sertifika süreçlerinde kullanılan bütün otoriteleri listeleyin.
  3. Ana alan, www, API ve özel CNAME alt alanlarının DNS zincirini ayrı sorgulayın.
  4. Önce düşük TTL ve belgelenmiş geri dönüş planı hazırlayın.
  5. Yalnız gerçekten gereken otoriteler için issue kayıtlarını ekleyin.
  6. Wildcard kullanıyorsanız issuewild davranışını ayrıca belirleyin.
  7. DNS yayılımından sonra farklı genel çözücülerden CAA cevabını kontrol edin.
  8. Üretim sertifikasını silmeden staging alanında veya sağlayıcının test ortamında yenileme provası yapın.

CAA hatası neden sertifika yokmuş gibi çıkabilir?

Let’s Encrypt her sertifika öncesinde CAA kontrolü yaptığını belirtiyor. DNS zaman aşımı, SERVFAIL veya yetkili sunucular arasında tutarsız cevap olduğunda otorite izin verildiğini doğrulayamayabilir ve düzenlemeyi durdurabilir. Alan adında açıkça CAA kaydı bulunmaması ile sorgunun hata vermesi aynı şey değildir. “Kayıt eklemedim, CAA sorunu olamaz” düşüncesi bu yüzden yanlıştır.

DNSSEC bozukluğu, hatalı CNAME zinciri ve birbirinden farklı cevap veren nameserver’lar da tanıyı zorlaştırabilir. Sertifika istemcisinin hata günlüğünü saklayın; yalnız paneldeki kırmızı uyarıya bakmayın. Değişiklikten önce çalışan kayıtların ekran görüntüsü ve metin yedeği geri dönüşü hızlandırır.

Kurulum sonrası aylık kontrol

CAA bir kez yazılıp unutulan kayıt değildir. CDN veya sertifika sağlayıcısı değiştiğinde politika da güncellenmelidir. Ayda bir ana alan ve kritik alt alanlarda CAA cevaplarını, sertifika düzenleyicisini ve yaklaşan bitiş tarihlerini karşılaştırın. Certificate Transparency uyarısı kullanıyorsanız yetkisiz görünen yeni sertifikayı CAA politikasıyla birlikte araştırın.

Ayrıca otomatik yenileme hatasını sertifika bitmeden bildiren alarm kurun. Başarısız tek deneme hemen kesinti yaratmayabilir; fakat günlerce fark edilmeyen hata sonunda bütün ziyaretçilerin güvenlik uyarısı görmesine yol açar.

En güvenli sonuç “tek satır ekledim” değil, sertifika yaşam döngüsünün belgelenmesidir. Hangi otoritenin hangi alan için neden yetkili olduğunu bilir, yenilemeyi önceden test eder ve DNS hatasını izlerseniz CAA küçük ama etkili bir savunma katmanına dönüşür.

Kaynak