EN
← Bloga dönRehberler

CAA Kaydı Nedir? SSL Sertifikanızı Kim Verebilir, Siz Belirleyin

CAA kaydı nedir, sertifika otoriteleri onu nasıl değerlendirir (üst alana tırmanma, CNAME, issue ve issuewild), hazır örnekler ve yenilemeleri bozmadan ekleme.

Yayınlanma: · 5 dk okuma

Herkese açık güvenilir her sertifika otoritesi (CA), teknik olarak her alan adı için sertifika düzenleyebilir. Sistem, her CA'nın alan adı kontrolünü düzgün doğrulamasına dayanır ve bunun ters gittiği örnekler yaşanmıştır. CAA kaydı (Certification Authority Authorization), alanı daraltmanın yoludur: "bu alan adı için yalnızca şu CA'lar sertifika verebilir" diyen bir DNS kaydı. Listede olmayan CA reddetmek zorundadır.

Ücretsizdir, beş dakika sürer ve size zarar vermesinin tek bir yolu vardır: CA değiştirirken varlığını unutmak. Bu rehber işin iki yarısını da anlatıyor.

CAA kaydı ne yapar, ne yapmaz?

CAA, RFC 8659'da (ilk hali olan RFC 6844'ün yerini aldı) tanımlıdır. Eylül 2017'den beri CA/Browser Forum'un temel gereksinimleri, herkese açık güvenilir her CA'yı sertifika vermeden önce CAA'yı kontrol etmekle yükümlü tutar.

  • Kontrolü CA, sertifikayı düzenlerken yapar. Tarayıcılar CAA'ya hiç bakmaz. CAA izin verirken düzenlenmiş bir sertifika, kaydı sonradan değiştirseniz de geçerli kalır.
  • CAA kaydı yoksa kısıtlama da yoktur. Eskisi gibi her CA sertifika verebilir.
  • Kullanmadığınız bir CA üzerinden hatalı sertifika düzenlenmesi riskini azaltır; örneğin bir web sunucusunu ya da posta kutusunu kısa süreliğine ele geçirip daha zayıf doğrulama yöntemi olan bir CA'yı deneyen birine karşı. DNS'inizi ele geçirmiş bir saldırganı durdurmaz, çünkü o CAA kaydını da değiştirebilir.
  • Bir iptal mekanizması değildir; Certificate Transparency günlüklerini izlemenin yerini de tutmaz.

CAA kaydının yapısı

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ değer
;                                │ └ etiket (tag)
;                                └ bayrak (flags)

Bayrak neredeyse her zaman 0'dır. 128 değeri "kritik" bitini açar; etiketi anlamayan CA sertifika vermemelidir demektir.

Etiketler:

Etiket Anlamı
issue Adı geçen CA bu ad için sertifika verebilir. issuewild yoksa joker (wildcard) sertifikalar için de geçerlidir.
issuewild Yalnızca joker sertifikaların kuralları. Varsa, joker talepleri için issue'nun yerini alır.
iodef CA'nın, politikayı ihlal eden bir talebi bildirebileceği adres (mailto: ya da https:). CA'ların desteği sınırlıdır; isteğe bağlı sayın.
issuemail Aynı denetimin S/MIME sertifikaları için olanı (RFC 9495).

issue/issuewild için değer, her CA'nın kendi belgelerinde (CAA ya da CPS sayfasında) yayınladığı tanımlayıcı alan adıdır. Bu her zaman CA'nın marka adı ya da web sitesi değildir; başka bir CA'nın sertifikalarını satan firmalar üst CA'nın tanımlayıcısını kullanır. Tahmin etmeyin, bakın. Özel değer ";" ise "hiç kimse" demektir.

CAA kaydı örnekleri

Tek CA, joker sertifika yok, bildirim adresi var:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

İki CA (diyelim ki ACME CA'nız ve CDN'inizin kullandığı CA):

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

Hiç sertifikası olmaması gereken bir alan adı:

parked.example.  IN  CAA  0 issue ";"

Joker sertifikalar normal sertifikalardan farklı bir CA'dan:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

CA ilgili kaydı nasıl bulur?

İnsanların en çok yanıldığı kısım burasıdır. www.shop.example.com adını içeren bir sertifika talebinde CA:

  1. www.shop.example.com adında CAA sorgular;
  2. orada CAA kaydı yoksa shop.example.com adını sorgular;
  3. sonra example.com ve böylece ağaçta yukarı çıkar;
  4. herhangi bir CAA kaydı bulduğu ilk adda durur ve yalnızca oradakileri kullanır.

Sonuçları:

  • example.com adındaki kayıt, kendi CAA'sı olmayan tüm alt alan adlarını kapsar.
  • Kayıtlar birleştirilmez. shop.example.com adındaki CAA, shop altındaki her şey için example.com adındakinin yerini tümüyle alır. Bunu, bir alt alan adına farklı bir CA tanımlamak için bilerek kullanabilirsiniz.
  • CNAME izlenir. shop.example.com, stores.saas.example adına CNAME ise shop.example.com için yapılan CAA sorgusu hedefin CAA kayıtlarıyla yanıtlanır. Yani bir SaaS sağlayıcısının CAA politikası sizin adınıza uygulanabilir. Güncel RFC'ye göre CA hedefin ağacında yukarı çıkmaz; hedefte CAA yoksa tırmanma sizin üst adınızdan, example.com adından devam eder.
  • Sorgu hatası, "kayıt yok" ile aynı şey değildir. CA temiz bir yanıt alamazsa (zaman aşımı, SERVFAIL, bozuk DNSSEC) sertifika vermemelidir. Sağlıksız yetkili DNS, başarısız yenilemeler olarak karşınıza çıkar.

Birden fazla ad içeren sertifikada her ad ayrı ayrı kontrol edilir.

Düzenlemeyi hesaba ya da yönteme bağlamak

RFC 8657, ACME kullananlar için CAA'yı belirgin biçimde güçlendiren parametreler ekler:

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi, düzenlemeyi tek bir ACME hesabıyla sınırlar; aynı CA'da hesabı olan başka biri doğrulamayı geçse bile sertifika alamaz. validationmethods, kontrolün hangi yöntemle kanıtlanabileceğini sınırlar. İkisi de yalnızca bunları uygulayan CA'larda çalışır; güvenmeden önce CA'nın belgelerine bakın ve ACME hesabını yeniden oluşturursanız kaydı güncellemeyi unutmayın.

CAA kaydı nasıl eklenir? Hiçbir şeyi bozmadan, adım adım

  1. Bugün sizin için kimin sertifika düzenlediğini bulun. Her sunucu adındaki sertifikayı inceleyin ya da Certificate Transparency günlüklerinde alan adınızı arayın. Tipik sürprizler: CDN, yük dengeleyicinin yönetilen sertifikaları, hazır e-ticaret altyapısı, durum sayfası, posta hizmeti ve farklı bir ACME CA'sı kullanan bir iç ekip.
  2. Her CA'nın CAA tanımlayıcısını kendi belgelerinden alın.
  3. Üçüncü taraflara CNAME olan alt alan adlarını kontrol edin: üzerlerinde CAA sorgulayın, ne döndüğüne bakın.
  4. Kayıtları kök alan adında, makul bir TTL (3600) ile yayınlayın. CA'lar bir CAA kontrolünün sonucunu en fazla kaydın TTL'i ya da 8 saat (hangisi büyükse) kadar önbellekte tutabilir.
  5. Hemen bir yenileme deneyin. certbot renew --dry-run, test ortamına karşı tam bir doğrulama yapar; çoğu ACME CA'sında buna CAA kontrolü de dahildir. Sonucu 60 gün sonra öğrenmeyin.
  6. CDN ya da CA değiştirecek bir sonraki kişinin bakacağı yere not düşün.

Yayınlananı sorgulayın:

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # boş → CA yukarı tırmanır

Sık yapılan hatalar

  • CDN ya da hosting firması değiştirip yenisinin farklı bir CA kullandığını unutmak. Yeni sertifika sessizce düzenlenemez, eskisinin süresi dolar. Bkz. SSL sertifikası süresi doldu: ne yapmalı.
  • CA'nın belgelenmiş CAA tanımlayıcısı yerine pazarlama adını yazmak.
  • Bir yerde joker sertifika kullanılırken issuewild ";" yayınlamak.
  • Kök alan adındaki issue ile alt alan adındaki issue'nun toplandığını sanmak. Alt alan adındaki küme tek başına geçerlidir.
  • CAA türünü desteklemeyen DNS sağlayıcısında kaydı TXT olarak saklamaya çalışmak. Hiçbir etkisi olmaz.
  • Panellerde tırnak hataları: değer tırnak içinde yazılır, bayrak ve etiket yazılmaz.
  • CAA'nın mevcut sertifikaları geçersiz kılmasını beklemek. Yalnızca yeni düzenlemeleri etkiler.
  • Nameserver taşırken CAA kayıtlarını kopyalamamak; kesintisiz nameserver değişikliği yazısında belirttiğimiz gibi en sık kaybolan kayıtlardandır.

OrbitProbe ile kontrol edin

OrbitProbe DNS sorgulama aracı, sorguladığı kayıt türleri arasında CAA'yı da TTL değeriyle birlikte, herkese açık çözümleyicilerin o anda döndürdüğü haliyle gösterir. Önce çıplak alan adında, sonra dış bir hizmete CNAME olan her alt alan adında çalıştırın; bir CA'nın orada gerçekte hangi politikayı bulacağını görürsünüz. CAA'nın diğer kayıt türleri arasındaki yeri için DNS kayıt türleri yazısına bakın.