CAA Kayıtlarını Doğru Yapılandırma Kılavuzu

Certification Authority Authorization (CAA) kaydı, bir alan adına ekleyebileceğiniz en basit güvenlik kontrollerinden biridir; ama aynı zamanda ince bir şekilde yanlış yapılandırılması en kolay olanlardan biridir. Özünde “bu ad için yalnızca şu sertifika otoriteleri TLS sertifikası verebilir” diyen bir DNS kaydıdır. Eylül 2017’den bu yana CA/Browser Forum Temel Gereksinimleri, genel olarak güvenilen her sertifika otoritesinin sertifika vermeden önce CAA kaydını kontrol etmesini zorunlu tutuyor. Kayıt mevcutsa ve o CA’ya yetki vermiyorsa talep reddedilmelidir.

Bu durum CAA’yı hatalı sertifika verilmesine karşı yararlı bir kalkan hâline getirir: başka bir CA’daki ele geçirilmiş bir hesap, onaylanmamış bir satıcıdan sertifika sipariş eden dikkatsiz bir çalışan ya da alan adı doğrulaması kandırılan bir CA. Aynı zamanda bozuk bir CAA kaydının kendi sertifika yenilemelerinizi sessizce durdurabileceği anlamına gelir. Bu rehberde RFC 8659’da tanımlanan sözdizimini, gerçekten kullanacağınız etiketleri, CA’ların kayıtları nasıl aradığını ve her şeyi iş işten geçmeden nasıl test edeceğinizi anlatıyoruz.

Bir CAA kaydı neler içerir?

2019’da yayımlanan RFC 8659, orijinal RFC 6844’ün yerini aldı ve güncel standarttır. Her CAA kaydının üç parçası vardır:

• Bayraklar (flags) – 0 ile 255 arasında bir sayı. Pratikte 0 kullanırsınız. 128 değeri “issuer critical” bitini ayarlar; bu, CA’ya etiketi anlamıyorsa sertifika vermeyi reddetmesi gerektiğini söyler.
• Etiket (tag) – issue, issuewild ya da iodef gibi özellik adı.
• Değer (value) – anlamı etikete göre değişen, tırnak içindeki bir dize; genellikle bir CA’nın alan adı.

Bölge dosyası sözdiziminde temel bir kayıt şöyle görünür:

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"

Aynı ada birden fazla CAA kaydı yayımlayabilirsiniz. Her issue kaydı izin verilen bir CA daha ekler; kayıtlar birbirinin üzerine yazılmaz, birleştirilir.

Bilmeniz gereken üç etiket

issue

issue etiketi, bir CA’ya ad için her türlü sertifikayı verme yetkisi tanır; bir issuewild kaydı aksini söylemedikçe joker sertifikalar da buna dahildir. Tek bir noktalı virgülden oluşan özel değer, yani ";", “hiçbir CA’ya izin verilmez” anlamına gelir. Bu, park edilmiş adlar ya da yalnızca e-posta için kullanılan alan adları gibi hiçbir zaman sertifikası olmaması gereken alan adları için kullanışlıdır.

issuewild

issuewild etiketi yalnızca *.example.com gibi joker sertifikalara uygulanır. En az bir issuewild kaydı varsa CA’lar joker talepler için issue kaydını yok sayar ve yalnızca issuewild’ı kullanır. Yaygın bir kalıp, normal sertifikalara tek bir CA’dan izin verip joker sertifikaları tamamen engellemektir:

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

iodef

iodef etiketi, bir CA’nın politikanız nedeniyle reddettiği talebi bildirebileceği bir URL verir. mailto: ve https: adreslerini kabul eder. Desteklenmesi isteğe bağlıdır; bu yüzden bir izleme sistemi değil, ek bir sinyal olarak görün.

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Yaygın sağlayıcıların CA tanımlayıcıları

Bir issue kaydının değeri, CA’nın kendisinin yayımladığı tanımlayıcıyla, genellikle Sertifika Politikası ya da CPS belgesindekiyle eşleşmelidir. Bu dizeyi yanlış yazmak, başarısız sertifika verme işlemlerinin en sık nedenidir. Aşağıdaki tanımlayıcılar geniş çapta belgelenmiştir, ancak bunlara güvenmeden önce CA’nızın güncel belgelerini kontrol edin.

Pek çok hizmetin sizin adınıza sertifika aldığını unutmayın. Bir CDN, yönetilen bir WordPress hosting hizmeti ya da bir e-posta güvenlik ürünü, hiç doğrudan seçmediğiniz bir CA kullanıyor olabilir. Kısıtlamaları sıkılaştırmadan önce alan adınızın önündeki her sağlayıcının hangi CA’yı kullandığını öğrenin.

CA’lar kaydınızı nasıl bulur: ağaçta tırmanma

Bir CA yalnızca sertifika talebindeki tam ada bakmaz. RFC 8659, istenen addan başlayıp her seferinde bir etiket yukarı çıkan bir arama tanımlar. Boş olmayan bir CAA kayıt kümesi döndüren ilk ad geçerli olandır ve arama orada durur.

shop.eu.example.com için yapılan bir talepte CA şu sırayla kontrol eder:

1. shop.eu.example.com
2. eu.example.com
3. example.com
4. com

Bundan iki pratik sonuç çıkar. Birincisi, bölge kökündeki tek bir kayıt kümesi genellikle tüm alt alan adlarını korur; çoğu alan adının yalnızca example.com düzeyinde CAA’ya ihtiyaç duymasının nedeni budur. İkincisi, bir alt alan adındaki CAA kaydı, o alt ağaç için kök politikasının yerini tamamen alır; ona ekleme yapmaz. eu.example.com adına 0 issue "digicert.com" eklerseniz, kök izin verse bile Let’s Encrypt’e orada artık izin verilmez. Zincirin hiçbir yerinde CAA kaydı yoksa herhangi bir CA sertifika verebilir.

CNAME kayıtları ve CAA

CAA’nın kafa karıştırdığı yer CNAME’lerdir. Bir CA, CNAME olan bir ad için CAA türünü sorguladığında normal DNS çözümlemesi takma adı izler ve hedefte bulunan CAA kayıtlarını döndürür. Hedefin CAA kayıtları varsa orijinal ad için bunlar kullanılır.

RFC 8659’a göre takma ad hedefinin CAA kaydı yoksa CA, hedefin üst düzeylerine değil, orijinal adın ağacına tırmanmaya devam eder. Eski RFC 6844’teki hedefin ağacına da tırmanma davranışı kaldırılmıştır. Bu, www.example.com adının example.cdn-provider.net gibi bir ada işaret ettiği durumlarda önemlidir:

• CDN hedefte CAA yayımlıyorsa onun politikası www adınıza uygulanır ve kök kaydınıza hiç ulaşılmaz.
• Hedefte CAA yoksa CA example.com düzeyine geçer ve kök politikanızı uygular.

Aynı adda CNAME’in yanına başka kayıt yayımlayamadığınız için hedefin politikasını takma adın kendisinde geçersiz kılamazsınız. Bir sağlayıcının CAA kaydı ihtiyaç duyduğunuz CA’yı engelliyorsa sağlayıcıya başvurun ya da farklı bir ana makine yapısı kullanın.

Adım adım yapılandırma

1. Sertifikalarınızın envanterini çıkarın. TLS kullanan her ana makine adını ve sertifikasını hangi CA’nın verdiğini listeleyin. crt.sh gibi Sertifika Şeffaflığı (CT) günlükleri unuttuğunuz sertifikaları bulmanıza yardımcı olur.
2. Bir politika belirleyin. İzin vereceğiniz CA’ları ve joker sertifikalara ihtiyaç olup olmadığını seçin.
3. Kayıtları bölge kökünde yayımlayın. Her CA için bir issue, isteğe bağlı olarak issuewild ve bir iodef iletişim adresi ekleyin.
4. Başlangıçta düşük TTL kullanın. 300 saniye gibi bir TTL hataları hızla düzeltmenizi sağlar; işler oturduğunda yükseltin.
5. Bir yenilemeyi test edin. CA’nın hâlâ sertifika verebildiğini doğrulamak için bir staging ya da deneme (dry-run) yenilemesi başlatın.

Web sitesi için Let’s Encrypt, joker sertifika için Sectigo kullanan bir alan adı için eksiksiz bir örnek şöyledir:

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 "sectigo.com"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Bazı CA’lar RFC 8657’de tanımlanan ek parametreleri de destekler; örneğin sertifika vermeyi tek bir ACME hesabıyla sınırlayan accounturi ve yalnızca belirli doğrulama türlerine izin veren validationmethods. Bunlar güvenliği daha da sıkılaştırır, ancak önce CA’nızın desteklediğini doğrulayın.

CAA kayıtlarını dig ile test etmek

Sağlayıcınızın paneline güvenmek yerine her zaman genel DNS’i sorgulayın. Aşağıdaki komutlar bir CA’nın ne göreceğini gösterir:

dig example.com CAA +short
dig www.example.com CAA +short
dig @1.1.1.1 example.com CAA
dig +trace example.com CAA

Önceki örnek için sağlıklı bir yanıt şöyle görünür:

0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"

Bir alt alan adının hiçbir şey döndürmemesi normaldir; CA üst ada tırmanacaktır. İstemediğiniz şey bir SERVFAIL yanıtıdır. Kesin bir yanıt alamayan bir CA genellikle sertifika vermeyi reddeder ve bazı eski DNS sunucuları ile cihazlar CAA kayıt türüne kötü yanıt verir. Bir alan adının hangi ad sunucularını ve kayıt firmasını kullandığını da görmeniz gerekiyorsa TLDix WHOIS sorgulama aracı bunu bitiş tarihiyle birlikte gösterir.

Pratik senaryo: CA değiştirirken kesintisiz geçiş

Diyelim ki siteniz yıllardır Sectigo sertifikası kullanıyor ve ücretsiz otomatik yenileme için Let’s Encrypt’e geçmek istiyorsunuz. Mevcut CAA kaydınız yalnızca sectigo.com içeriyor. Sık yapılan hata, önce sunucuda ACME istemcisini kurup sertifika istemek ve doğrulamanın neden başarısız olduğunu saatlerce aramaktır; neden basittir, CAA yeni CA’ya izin vermiyordur.

Doğru sıra şöyledir: önce mevcut kaydın yanına 0 issue "letsencrypt.org" ekleyin ve TTL’yi geçici olarak düşürün. dig @1.1.1.1 example.com CAA ile yeni kaydın genel çözümleyicilerde göründüğünü doğrulayın. Ardından yeni sertifikayı alın, sunucuya yükleyin ve tarayıcıda zinciri kontrol edin. Birkaç gün boyunca her şeyin sorunsuz çalıştığından emin olduktan sonra eski sectigo.com kaydını kaldırın ve TTL’yi normal değerine yükseltin. Bu yöntemle hiçbir aşamada sertifikasız kalmazsınız ve geri dönmeniz gerekirse eski CA hâlâ yetkilidir. Aynı mantık, bir CDN’e geçerken ya da yeni bir SaaS hizmetine özel alan adı bağlarken de geçerlidir.

Kaçınılması gereken yaygın hatalar

• CAA’yı güncellemeden CA değiştirmek. Önce yeni CA’yı ekleyin, sertifikayı alın, sonra eskisini kaldırın.
• Tanımlayıcılarda yazım hataları. letsencrypt.com ya da lets-encrypt.org sertifika verilmesini sessizce engeller.
• Üçüncü taraf hizmetleri unutmak. Bir CDN ya da SaaS özel alan adı için CA’sının listelenmesi gerekebilir.
• Kritik bayrağı gelişigüzel ayarlamak. Tanınmayan bir etikette 128 kullanmak tüm sertifika verme işlemlerini durdurur.
• DNSSEC’i göz ardı etmek. CAA, DNS yanıtı kadar güvenilirdir; DNSSEC sahteciliği çok daha zor hâle getirir.

CAA en iyi sonucu daha geniş bir rutinin parçası olarak verir: sertifika bitiş tarihlerini takip edin, Sertifika Şeffaflığı günlüklerini izleyin ve DNS değişikliklerini gözden geçirin. Kayıt türlerine yeniyseniz DNS kayıtlarının temelleri rehberimiz iyi bir başlangıç noktasıdır.