Kısa cevap: api.example.com için CAA kaydı görmemeniz sertifika düzenlemeye hiçbir kısıtlama uygulanmadığını kanıtlamaz. Üst alanın politikası veya bir CNAME zincirindeki hedef etkili olabilir. Bu nedenle yalnız hosting panelindeki alt alan satırını incelemek yerine isim zincirini çıkarmak gerekir.
Sertifika istenen tam adı sabitleyin
İstek ana alanı mı, www adresini mi yoksa belirli bir uygulama adını mı kapsıyor? Hata metnindeki adı aynen yazın. Sertifikaya birden fazla ad eklenmişse her biri ayrı değerlendirme gerektirebilir. Uygulamanın adını değiştirmek çözümü daha karmaşıklaştırabilir. SSL kapsamı rehberini kullanarak isim uyuşmazlığıyla düzenleme iznini aynı sorun gibi görmeyin.
Üst alanlarda hangi politika var?
Let's Encrypt'in CAA açıklaması, sertifika istenen addan başlayarak ilgili üst adlara bakıldığını belirtir. Bu incelemede yeni bir alt alan açıldığı için üst politikanın kendiliğinden kalktığını düşünmeyin. Şirketinizin DNS sorumlusuna hangi kayıt kümesinin etkili olduğunu sorun. Hedef hizmeti yöneten ekip ile alan adını yöneten ekip farklıysa açıklamayı yazılı kaydedin.
CNAME zincirini görünür hâle getirin
Alt alan üçüncü taraf hizmetine CNAME ile bağlıysa yalnız kendi bölgenizde düzenleme yapmanız yeterli olmayabilir. Hedefin sertifika hizmeti ve CAA davranışını sağlayıcıdan doğrulayın. Cloudflare CAA belgesi, kendi sertifika hizmeti için izinlerin neden önemli olduğunu açıklar. Bu belgeyi başka bir sağlayıcının kullandığı otorite listesi yerine koymayın; her hizmetin güncel gereksinimini ayrıca öğrenin.
İstisnayı yalnız gereken yerde planlayın
Bir uygulama farklı otorite gerektiriyorsa tüm şirket alanının politikasını gevşetmek yerine uygun kapsamı yöneticinizle değerlendirin. Mevcut kayıtları dışa aktarın ve değişikliğin hangi uygulama için yapıldığını not edin. Aynı isimde A ve CNAME çakışması gibi tip hatalarını ayrıca kontrol edin. DNS şemasına aykırı kayıt ekleyerek sertifika hatasını düzeltmeye çalışmayın. E-posta ve diğer uygulamaların ayarlarını bu inceleme sırasında değiştirmeyin.
Kararı yayınlanan cevaba göre verin
DNS yönetimi rehberindeki yetkili nameserver ayrımını kullanın. Kaydın panelde görünmesiyle internetten cevap vermesi farklı kontrol noktalarıdır. Değişiklik sonrası sertifika isteğinin yeni sonucunu alın; hâlâ reddediliyorsa eski ekran görüntüsüne değil güncel hataya dönün. Taşıma planında farklı ekiplerin sertifika sorumluluğunu yazmak, bir sonraki yenilemede aynı belirsizliğin yaşanmasını azaltır. Özel anahtar ve API sırlarını paylaşmadan tanı kaydı oluşturun.
Bu konunun diğer kontrolleri
- CAA issue ve issuewild Farkı: Normal ve Wildcard Sertifika İzinleri
- CAA Hatası Nedeniyle SSL Verilemiyor: DNS Sorgu Hatası mı, İzin Reddi mi?
Sıkça Sorulan Sorular
Alt alanın CAA cevabı boşsa kısıtlama yok mu?
Bunu varsaymayın. Sertifika otoritesi üst isimlerdeki uygulanabilir politikayı da değerlendirebilir. Alt alanın kaydı, üst alanı ve varsa CNAME hedefini birlikte incelemek gerekir; yalnız panelde boş hücre görmek yeterli değildir.
Her alt alana ayrı CAA eklemek zorunda mıyım?
Hayır. Amaç her alt alan için aynı mı farklı mı politika istediğinizi belirlemektir. Gereksiz ayrı kayıtlar gelecekte yönetim yükü yaratır. Farklı sağlayıcıdaki hizmet gerçekten ayrı izin gerektiriyorsa bunu kapsamı belli bir değişiklikle planlayın.
CNAME yanında CAA ekleyebilir miyim?
Aynı isimde CNAME ile başka kayıtları birlikte ekleme konusunda DNS kısıtlarını dikkate alın. Panelin reddini aşmaya çalışmayın. CNAME hedefindeki ve üst alanlardaki politikayı sağlayıcınızla değerlendirin.
Tek alt alan için ana alan politikasını kaldırmak doğru mu?
Önce istisnanın gerçekten nerede gerektiğini belirleyin. Ana alan politikasını kaldırmak diğer alt alanların sertifika düzenleme sınırını da değiştirebilir. Etkilenen uygulama, gerçek sertifika otoritesi ve DNS hedefi yazılı olarak eşleştirilsin. Yetkili DNS yöneticisi uygun kapsamı seçmeli; değişiklik sonrası yalnız sorunlu uygulama değil ana alanın mevcut sertifika yenileme yolu da kontrol edilmelidir.