CAA Kayıtları Derinlemesine: Neden, Nasıl ve Ne Zaman Çoklu‑CA’ya Geçmelisin?

Küçük Bir CAA Hikâyesi: “Sertifika Neden Birden Durdu?”

Hiç başınıza geldi mi? Gece 02:00, kahve bitmiş, gözler yarı açık. ACME otomasyonunun sertifikayı yenilemesini bekliyorsunuz. Her şey yolunda derken bir anda hata: CAA mismatch. O an anlıyorsunuz ki DNS’teki minicik bir kayıt, bütün akışı kilitlemiş. Ben bu filmi izledim. Bir müşteri, subdomain’lerde bir düzenleme yaparken farkında olmadan CAA kaydını öyle bir sıkılaştırmış ki, Let’s Encrypt’in yerine sadece farklı bir CA’yı yetkilendirir hale gelmiş. Sonuç: Otomasyon durmuş, panik başlamış.

İşte o geceden sonra CAA’nın sadece “güvenlik için iyi bir fikir” olmadığını, aynı zamanda yaşayan bir operasyon politikası olduğunu daha net gördüm. Bu yazıda CAA kayıtlarını, issue / issuewild ayrımını, iodef ile bildirimleri, ve Let’s Encrypt ile ZeroSSL yetkilendirmesini baştan sona, tatlı tatlı konuşacağız. Bir de işin kalbinde yatan konuya geleceğiz: çoklu‑CA stratejisi. Çünkü tek bir sağlayıcıya yaslanmak; kesinti, oran limiti ya da bölgesel bir aksaklıkta en son isteyeceğiniz şey.

Hazırsanız beraber ayar dosyalarınızı değil, önce akışınızı düzenleyelim. Mesela şöyle düşünün: CAA, kapınızdaki güvenlik görevlisi. Kimi içeri alacağını siz söylüyorsunuz. Bazen tek isim söylersiniz, bazen de iki kapıdan giriş açarsınız. İşte o iki kapının doğru zamanda, doğru şekilde açık olduğundan emin olacağız.

CAA Nedir? Neyi, Neden Kontrol Eder?

CAA (Certification Authority Authorization), kısaca “Bu alan adına sertifika vermeye kimlerin yetkili olduğunu DNS’te ilan ettiğiniz” bir kayıt. Sertifikanızı düzenlemek isteyen bir CA (örneğin Let’s Encrypt), önce DNS’inize bakar: “Beni yetkili kılmışlar mı?” Cevap evetse devam, değilse başvuruyu reddeder. Böylece rastgele bir sağlayıcının, sizin bilginiz dışında sertifika vermesinin önüne geçmiş olursunuz.

Buradaki güzel ayrıntı şu: CAA miras alır. Yani sub.example.com için ayrı bir CAA yoksa, example.com’daki kurallar geçerlidir. Bu iyi bir şey, çünkü tek bir merkezden tüm alt alanlarınızı yönetebilirsiniz. Ama bir de ters yüzü var: Üst alanda gereğinden katı bir kural koyarsanız, beklemediğiniz bir alt alan yenilemesinde duvara toslayabilirsiniz.

Bazen şunu da duyarım: “Zaten DNSSEC kullanıyorum, CAA şart mı?” Birbirini tamamlıyorlar. DNSSEC kayıtlarınızın doğruluğunu kanıtlar, CAA ise kimin sertifika düzenleyebileceğini sınırlar. Birlikte düşünün; ayrı ayrı değil.

issue, issuewild ve iodef: Küçük Farklar, Büyük Etkiler

CAA’nın üç tatlı anahtar kelimesi var: issue, issuewild ve iodef. Her biri aynı cümlenin farklı tonları gibi davranır.

issue, alan adınız için genel sertifika yetkisi verir. “Bu alan için sertifika isteyen olursa, şu CA’lar verebilir” dersiniz. Mesela: example.com CAA 0 issue "letsencrypt.org" dediğinizde, Let’s Encrypt’i yeşil listeye almış olursunuz. Birden fazla sağlayıcıyı yan yana yazabilirsiniz; her satır ayrı bir izin gibi düşünün.

issuewild ise joker karakterli (wildcard) sertifikaları hedefler. *.example.com gibi yıldızlı bir sertifika düzenlenmek istendiğinde, CA bu kez issuewild kurallarını kontrol eder. Şöyle bir kural, “wildcard sadece ZeroSSL versin” diye fısıldar: example.com CAA 0 issuewild "zerossl.com". Eğer wildcard’ı sıkı tutmak, ama tekil alt alanları daha serbest bırakmak istiyorsanız, bu ayrım çok işinize yarar.

Gelelim iodef’e. Bu da bir tür haberleşme kanalı. CA diyor ki: “Ben bir şey fark edersem, kime haber vereyim?” Siz de mailto: ya da https: ile bir adres veriyorsunuz. Örneğin: example.com CAA 0 iodef "mailto:[email protected]" ya da example.com CAA 0 iodef "https://certs.example.com/notify". Bir gün beklemediğiniz bir deneme olursa, size e‑posta ya da webhook ile “Kapıda bir hareket var” diye haber gelir. Sessiz sakin bir ağ günü için paha biçilemez.

Ufak ama kritik bir not: CAA satırlarında parametreler de kullanılabiliyor. Bazı CA’lar, belirli doğrulama yöntemlerini (“validationmethods=http-01,dns-01”) ya da belirli bir hesabı (“accounturi=...”) şart koşmanıza izin veriyor. Bu, özellikle çok kiracılı yapılarda veya birden fazla ekip aynı alanı yönetirken hayat kurtarır. Yetkiliyi değil, nasıl ve hangi hesapla yetkili olduğunu tarif edersiniz.

Let’s Encrypt ve ZeroSSL’i Nasıl Yetkilendirirsin? Küçük Farkların Büyük Konforu

İş pratiğe geliyor. Let’s Encrypt için genellikle issue "letsencrypt.org" satırı yeterli olur. Wildcard kullanacaksanız issuewild ile de ayrı bir satır ekleyebilirsiniz. ZeroSSL tarafında ise ben çoğu kurulumda issue "zerossl.com" gördüm ve sağlıklı çalıştı. Bazı altyapılarda sectigo.com etiketi de kabul edilebilir; çünkü işin arka tarafında ilişkiler var. Ama net ve sade kalmak için zerossl.com yazma alışkanlığı pratikte iş görüyor.

Örnek bir kurulum zihninizde dursun: Genel sertifikaları Let’s Encrypt, wildcard’ları ZeroSSL versin isteyin. O zaman iki satırınız olur. Biri example.com CAA 0 issue "letsencrypt.org", diğeri example.com CAA 0 issuewild "zerossl.com". Böylece otomasyonunuz, wildcard’ı yenilerken “Ben ZeroSSL’e gideyim” der; tekil alt alanlarda ise Let’s Encrypt ile devam eder.

Bir tık daha ileri seviyede, belirli doğrulama yöntemlerini şart koşabilirsiniz. Diyelim ki HTTP‑01 yerine sadece DNS‑01 ile doğrulama yapılmasını istiyorsunuz. Bazı CA’lar bu parametreyi CAA içinde anlayabiliyor: example.com CAA 0 issue "letsencrypt.org; validationmethods=dns-01". Bu satır, “Benim kapımdan içeri sadece DNS doğrulamasını yapan girsin” demek gibi bir şey. Kurallar net olunca, otomatikleştirilmiş işlemler daha düzenli akıyor.

Garip hatalarla karşılaşırsanız, önce CA’ların kendi dokümantasyonuna bakmak iyi fikir. Let’s Encrypt tarafında Let’s Encrypt CAA rehberi net ve kısa. ZeroSSL içinse genel yol haritasını, onların CAA kayıtlarını anlatan yazısından takip etmek kolay oluyor. Bir de DNS panelinizin CAA alanına nasıl yaklaştığını görmek için kullandığınız sağlayıcının dokümanlarına göz atın; örneğin Cloudflare’ın CAA referansı ara yüzle birebir uyumlu açıklıyor.

Çoklu‑CA Stratejisi: Tek Kapıya Güvenmek Neden Yorucu?

Şöyle düşünün: Tatlı bir e‑ticaret siteniz var, kampanya dönemi. Trafik artmış, herkes ödeme sayfasında. Tam o sırada tek bir CA’nın oran limitine takıldınız veya kısa süreli bölgesel bir sorunu oldu. Otomasyon yenileyemedi. İşte burada çoklu‑CA stratejisi fark yaratıyor. CAA’da hem Let’s Encrypt’i hem de ZeroSSL’i yetkili kıldığınızda, otomasyonunuz ikinci kapıdan içeri usulca girip sertifika işini tamamlayabiliyor.

Benim pratikte sevdiğim yaklaşım şu: CAA’da iki sağlayıcıyı da açık tut, otomasyonunda da fallback sıranı belirle. Yani önce Let’s Encrypt’le dene; olmadıysa ZeroSSL’e otomatik geç. Böylece günlük akışta gereksiz geçiş yapmadan, gerektiğinde yedek plan devreye girer. Bu akışı kurarken ACME otomasyonunda yedekli CA stratejisini adım adım anlatan şu rehber pratikte çok işe yarıyor; CAA tarafı ise bunun DNS’teki izin perdesi gibi.

Wildcard’ı neden bazen farklı bir sağlayıcıya veriyoruz derseniz, sebebi çok insani: “Daha az sürpriz.” Wildcard’lar genelde DNS‑01 doğrulaması gerektiriyor. Bazı CA’lar bu akışta daha stabil davranıyor ya da ek koşullar istiyor. O yüzden wildcard’ı tek bir CA’da standardize etmek, tekil alt alanları ise diğer CA’ya bırakmak sık gördüğüm bir model. Böyle yaptığınızda CAA satırları stratejiyi görünür kılıyor.

İşin güvenlik tonu da önemli. CAA’ya “accounturi=...” koyarak, belli bir ACME hesabıyla sınırlandırma yaparsanız, “yetkili CA tamam, ama sadece benim hesabım üzerinden” demiş olursunuz. Ekip sayısı artınca bu ince ayar, gece yarısı sürprizlerini ciddi biçimde azaltıyor.

Operasyonel İncelikler: TTL, Miras, CNAME ve Küçük Tuzaklar

CAA’yı kurdunuz diyelim. İlk günlerde TTL değerini çok şişirmeyin. Deneme‑yanılma yaparken kısa TTL, “hata yaptım, düzelttim, etkisini çabuk göreyim” demek. Oturduğunda uzatabilirsiniz. Özellikle üretim öncesi geçişlerde beni en çok rahatlatan şey, kontrollü ve kısa TTL oldu.

Miras meselesini unutmayın: shop.example.com için ayrı CAA eklemediyseniz, example.com’daki kurallar geçerlidir. Bazen ekipler alt alan özelinde farklı bir politika ister, ama ana alan o kadar katıdır ki alt alanın ihtiyacına yer kalmaz. O zaman alt alanda daha serbest bir CAA tanımı yapıp, ana alanın katılığını o dallanmanın üstüne taşımamak gerekir.

CNAME zinciri olan alanlarda da bazen kafa karıştırıcı davranışlar görülür. Sertifika isteyen CA, başvuru yapılan adrese, gerektiğinde CNAME’in hedeflediği isme ve nihayetinde üst alanlara bakarak CAA kararını verir. Bu yüzden zincirdeki her halkada beklenmedik bir CAA’nin veto etkisi olabileceğini aklınızda tutun. Özellikle harici bir hizmete yönlendirdiğiniz alt alanlarda, hedef alanın CAA politikasının sizinkini gölgelemediğinden emin olun.

Şu “kritik bayrak” meselesi de arada sorulur. CAA kaydındaki bayrak alanı genellikle 0’dır. Bazı ileri kullanımlarda “bilinmeyen parametreyi görürsen başvuruyu reddet” anlamına gelen kritik bir bayrak setlenebilir. Pratikte bu pek kullanılmaz; zira uyumsuz bir yorum, gereksiz reddedişlere yol açabilir. Başlangıç için sade kalmak, sonra gerçekten ihtiyacınız doğarsa bu seviyeye inmek daha huzurlu.

Son olarak, iodef adresinizi çalışır tutun. Bir e‑posta veriyorsanız posta kutusunu izleyen bir ekip olsun, bir HTTP uç noktası veriyorsanız log’lanan, alarmlanan, ulaşılabilir bir yer olsun. Haber geliyor ama kimse görmüyorsa, gelmeyen haber kadar kötü.

CAA, ACME ve Otomasyonun Dansı: Akışınızı Nasıl Rahatlarsınız?

Otomasyon dünyasında iki şey huzur getiriyor: Net yetkiler ve iyi bir geri dönüş planı. CAA size net yetkileri veriyor, ACME istemciniz de geri dönüşü. Örneğin önce Let’s Encrypt, başaramazsa ZeroSSL deneyecek bir akış kurdunuz. CAA tarafında da her iki sağlayıcıya izin verdiniz. O zaman bir CA’nın sessiz sedasız problem yaşadığı bir gün, akışınız durmuyor; sadece diğer kapıdan devam ediyorsunuz.

Burada ince bir rafine ayar var: issue ve issuewild ile politikayı katmanlandırmak. Wildcard her zaman DNS‑01 ile gidecekse, onun akışını daha ayrı bir rayda tutmak, genel alan sertifikalarını ise HTTP‑01’e bırakarak web sunucularıyla daha yakın entegre etmek zaten doğal bir bölünme yaratıyor. CAA satırları bu ayrımı görünür kılınca, ekipler arasında yanlış anlaşılma azalıyor.

Bir de üretim öncesi dry‑run tadında kontroller: Otomasyonun güncellemeyi yapmasından önce CAA’yı hazırlayıp küçük bir alt alanda deneme yapmak, “beklediğim CA’ya gidiyor mu, beklediğim doğrulama yöntemi tetikleniyor mu” sorularına hızlı cevap verdiriyor. Sonra yaygınlaştırmak daha kolay.

Gerçek Hayattan Kısa Senaryolar: “Mesela Şöyle Düşünün…”

Senaryo 1: Geliştirme ortamında wildcard lazım değil. O halde dev.example.com için sadece issue ile Let’s Encrypt’i yetkilendirin. Wildcard’ı ise ana alan için ZeroSSL’e bırakın. Böylece geliştirme tarafında hızlı ve sade kalırken, üretimde daha kontrollü bir ray kurmuş olursunuz.

Senaryo 2: Müşterilerin kendi alan adlarını bağladığı bir SaaS ürününüz var. Her müşterinin DNS’ine dokunamayacağınız için, ACME tarafında DNS‑01 yerine müşterinin sitesinde HTTP‑01 doğrulaması yapmak istiyorsunuz. O zaman CAA’da “validationmethods=http-01” parametresini destekleyen CA’yı açıkça yetkilendirmek, beklenmedik bir “yanlış yöntemle denendi, reddedildi” sürprizini ortadan kaldırır. Bu yaklaşımı, çok kiracılı SSL otomasyonunu konuştuğumuz çok kiracılı mimaride DNS‑01 stratejileri tadında düşünmek isterseniz, perspektif sağlamak için şuradaki anlatımı seviyorum: SaaS’te özel alan adları ve otomatik SSL akışı. (Not: Burada mimari lensine bakıyoruz; CAA alanı ise aynı dansın yetki kısmı.)

Senaryo 3: Kök alanınızda katı kurallar var ama alt alanlardan biri harici bir sağlayıcıya yönleniyor. O harici sağlayıcının da kendi CAA politikaları var. Böyle durumlarda alt alana özel bir issue satırı ekleyip, o servis için gerekli CA’yı açıkça yetkilendirmek köşedeki taşları düzeltir. “Üstten miras gelsin, ama burada biraz eğilelim” demek gibi.

Sorun Giderme: “Neden Reddedildi?” dediğinizde Bakılacak Noktalar

İlk kontrol her zaman doğru isim. Yanlış etiket, yanlış tırnak, yanlış alan adı, bazen en masum hatadır. Ardından miras zincirini baştan sona okuyun: Başvurulan FQDN, varsa CNAME hedefi, sonra bir üst alan ve derken köğe kadar gidip CAA var mı bakın. Bir yerde “Ben burada bir şey yazmışım ama unuttum” çıkar.

Eğer wildcard başvurusu yapıyorsanız, issuewild yoksa veya yanlış CA’yı işaret ediyorsa reddedilir. Wildcard’ın genelde DNS‑01 istediğini, otomasyonunuzun DNS güncelleme yetkisi olup olmadığını da yoklayın. Yanlış bir doğrulama yöntemi bazen “CAA reddi” gibi görünür.

Son olarak log okumayı sevin. ACME istemcisinin sunduğu günlüklerde “CA’dan dönen hata” mesajı sizi doğrudan CAA ipucuna götürür. Bir de iodef kullanıyorsanız, oraya düşen bildirimler olayın saatini, hangi adrese bakıldığını, hangi yönergenin reddi tetiklediğini söyler. Bu küçük mesajlar, büyük soruları küçültür.

Kapanış: CAA’yı Bir Kayıt Değil, Bir Politika Gibi Tutmak

CAA’yı ilk kez kurarken his, genelde “küçük ama önemli bir kayıt ekledim” şeklinde oluyor. Sonra işler büyüyüp ekipler çoğalınca, aslında bunun sertifika düzenleme politikanız olduğunu fark ediyorsunuz. Kimi içeri alacağınız, wildcard’ı kime bırakacağınız, hangi doğrulama yöntemine izin verdiğiniz, beklenmedik denemelerde nasıl haberdar olduğunuz… Hepsi o küçücük satırlarda. Güzel tarafı şu: Bir kez akışınızı düşünerek yazdığınızda, CAA size her gün huzur veriyor.

Pratik bir özetle vedalaşayım. Önce neye ihtiyacınız olduğuna karar verin: Genel sertifikalar bir CA’dan, wildcard başka bir CA’dan gelebilir. CAA’da issue ve issuewild ile bunu görünür yapın. iodef ile haberdar olun; e‑posta ya da https uç noktanızı gerçekten izleyin. Çoklu‑CA’ya kapı açın ve otomasyonunuzda fallback kurgusunu kurun; tek kapıya güvenmeyin. Değişikliklerde kısa TTL ile başlayın, mirası ve CNAME zincirlerini iki kere kontrol edin. Hepsi bu. Umarım bu yazı, gece yarısı CAA sürprizlerini sabah kahvesi kadar sıradan ve huzurlu hale getirir. Bir dahaki yazıda görüşmek üzere.