SaaS Özel Alan Adlarında DNS-01 Otomasyonu
SaaS’te özel alan adı desteği, bir hostname’i müşteri hesabına kaydetmekten fazlasıdır. Platform alan adını doğru tenant’a bağlamalı, uygun sertifikayı TLS sırasında sunmalı ve HTTP isteğini yalnız yetkili uygulamaya yönlendirmelidir. DNS-01, müşteri uygulama trafiğini taşımadan sertifikayı hazırlamaya yardımcı olur; bu üç sorumluluğu tek bir doğrulama işlemi hâline getirmez.
Bu rehber, kamusal müşteri alan adları için DNS-01 tabanlı ACME otomasyonunun mimarisini ele alır. Platform doğrulaması, CA doğrulaması, kayıt delegasyonu, kuyruk, anahtar saklama ve trafik geçişi ayrı aşamalardır. Let’s Encrypt ve cert-manager örneklerinin sağlayıcıya özgü koşulları belirtilir. Amaç, hataları görünür olan ve yenilemede de sürdürülen bir süreç kurmaktır.
Alan Adı Bağlama, TLS ve Trafik Sorumlulukları
Platformun kendi alan adı altında kullanılan wildcard yalnız eşleşen tek etiketli adları kapsar. Müşterinin shop.example.com veya example.com adresi platform alan adının wildcard’ıyla korunamaz. Her müşteri adı için DNS kontrol yetkisi, sertifika kapsamı ve etkin tenant eşlemesi gerekir. Kök alanın yönlendirme seçenekleri ile _acme-challenge kaydının yönetimi farklı konulardır; müşteri talimatlarında bunları ayrı gösterin.
shop.example.com için önce bu adın platformda hangi tenant tarafından talep edildiğini doğrulayın. Ardından CA doğrulaması ve sertifika dağıtımını hazırlayın; uygulama trafiğini hazır uç noktaya taşıyın. HTTP-01 uygun port-80 yoluna ihtiyaç duyar; DNS-01 ise kamusal TXT yönetimi sayesinde bu HTTP yönlenmesinden önce çalışabilir. DNS-01’in başarılı olması tek başına platform içindeki müşteri eşlemesinin doğru olduğunu kanıtlamaz.
DNS-01 ile Trafik Geçişinden Önce Sertifika Hazırlama
DNS-01’de müşterinin uygulama A/AAAA veya CNAME kaydı henüz platforma taşınmadan doğrulama yapılabilir. Önerilen sıra: tenant’a bağlı alan adı talebini doğrulayın, otomatik DNS doğrulama yetkisini hazırlayın, sertifikayı düzenletin, uçlara dağıtıp test edin, ardından uygulama trafiğini yönlendirin. HTTP-01, DNS-01 ve TLS-ALPN-01 yöntemleri arasında Let’s Encrypt wildcard için yalnız DNS-01’i destekler; diğer CA ürünlerinin desteğini ayrıca doğrulayın.
CA challenge token’ını verir; ACME istemcisi token ve hesap anahtarı parmak izinden key authorization üretir, bunun SHA-256 özetini base64url kodlayarak TXT değeri yapar. example.com için sahibi _acme-challenge.example.com olur; ham token yayımlanmaz. Bir defalık elle TXT eklemek gözetimsiz yenileme sağlamaz. Desteklenen DNS API’si veya istemcinin güncelleyebildiği bir doğrulama delegasyonu gerekir.
Tenant’a Bağlı Alan Adı Doğrulaması
Platform Doğrulaması ile CA Doğrulamasını Ayırma
Platform doğrulamasını CA challenge’ından ayrı tasarlayın. Örneğin belirli tenant, hostname ve güncel talebe bağlı tahmin edilemez bir TXT doğrulama değeri kullanın; bunun yaşam süresini ve tekrar kullanımını yönetin. Bu kontrol güncel DNS kontrolünü ve talebin hesabını bağlar, hukuki mülkiyeti kanıtlamaz. ACME TXT ise CA hesabına bağlıdır; aynı platform hesabını kullanan tenant’ları tek başına ayıramaz. Platform içinde bir hostname için tek etkin tenant eşlemesi tutun ve yeniden bağlama taleplerinde yeni yetki kanıtı isteyin.
Sertifikayı Dağıtıp Sonra Trafiği Taşıma
DNS-01 başarılı olduktan sonra siparişi tamamlayın; sertifikanın SAN’larını, zincirini ve özel anahtar eşleşmesini kontrol edin. Sertifikayı bütün hedef uçlara dağıtıp hostname’e uygun TLS yanıtını trafik geçişinden önce sınayın. Sonra müşteriden uygulama DNS’ini değiştirmesini isteyin ve gerçek trafiği doğrulayın. Geçiş sırasında eski yol bir süre kullanılabileceğinden hizmeti ve gerekiyorsa veriyi planlı biçimde koruyun. Sertifika dosyasının depoda bulunması uçta hazır olduğunu göstermez.
DNS Yayılımı ve Önbellekleri Bekleme
DNS API’sinin başarı yanıtı bütün yetkili sunucuların güncellendiği anlamına gelmez. Yetkili yayım, pozitif TTL ve SOA’ya bağlı negatif önbellek sürelerini ayrı değerlendirin. TTL’yi düşürmek mevcut önbellekleri temizlemez. Panelde gözlenen durumu ve bir sonraki kontrolü gösterin; sabit bir dakikalık garanti vermeyin. Eşzamanlı doğrulamalar aynı ad altında TXT değerleri kullanabilir; yalnız tamamlanan işin değerini temizleyin, diğer etkin değerleri koruyun.
Sipariş Kuyruğu, Yeniden Deneme ve Oran Limitleri
Her alan adı için kalıcı bir durum kaydı ve sınırlı eşzamanlılık kullanın. Tenant doğrulaması bekleyen, challenge hazırlanan, DNS bekleyen, CA doğrulanan, düzenlenen, dağıtılan ve etkin adları ayırın. Aynı talebin tekrarı yeni siparişler üretmesin; alan adı veya sertifika kapsamındaki çakışan işleri koordine edin. Hata türüne göre bekleme ve tekrar sınırı uygulayın, süresi dolmaya yaklaşan mevcut sertifikaların yenilenmesine yeterli pay bırakın.
Let’s Encrypt staging ortamı üretimden ayrı hesaplar, kotalar ve güvenilmeyen test zincirleri kullanır; test sertifikasını canlıya dağıtmayın. SAN gruplama, tenant’ların yenileme ve anahtar yaşam döngülerini birbirine bağlayabilir. Ayrı sertifikalar bazı işlemleri bağımsızlaştırır ancak kotayı ortadan kaldırmaz. Let’s Encrypt oran limitleri ve çok alan adlı sertifika planlama rehberi güncel kapsamları ve yenileme koşullarını ele alır; yeni hesap açmayı genel bir limit çözümü saymayın.
Önce TLS SNI, Sonra HTTP Host Yönlendirmesi
İşlem sırası TLS ile başlar: uç nokta ClientHello içindeki SNI’ye göre uygun sertifikayı seçer ve el sıkışmasını yürütür. HTTP Host veya HTTP/2-3 :authority bilgisi daha sonra işlenir; henüz okunmamış Host’a bakarak önceki sertifika seçilemez. HTTP hedef adını doğrulanmış etkin tenant haritasıyla eşleştirin ve bağlantı bağlamının bu ad için uygunluğunu kontrol edin. Bilinmeyen ya da yetkisiz adlar varsayılan olarak başka tenant’a düşmemelidir.
Sertifika ve anahtar sürümlerini tutarlı çiftler olarak dağıtın; anahtar erişimini ilgili uçlar ve yetkili süreçlerle sınırlayın. Depolama şifrelemesi tek başına geniş okuma yetkisinin riskini gidermez. Ucun desteklediği atomik güncelleme veya yeniden yükleme yöntemini test edin, yeni bağlantılardan sunulan zinciri kontrol edin. SNI/HTTP hedef ilişkisini uygulamanın gerçek protokolüne göre doğrulayın; güvenilen proxy veya bağlantı paylaşımı olan durumlarda yalnız ham metin eşitliğine dayalı evrensel kural kullanmayın.
DNS Sağlayıcı Entegrasyonları ve Kayıt Temizliği
DNS adaptörü kayıt oluşturma, gözleme ve yalnız kendine ait değeri kaldırma işlemlerini sağlayıcının gerçek API modeliyle gerçekleştirmelidir. Aynı talebin tekrarında mükerrer kayıt veya sipariş üretmeyen işlem kimlikleri kullanın. Let’s Encrypt challenge sorgularında CNAME ve NS delegasyonunu izleyebilir; istemcinin nereye kayıt yazacağı ayrıca ayarlanır. Delegasyon kalıcı düzenleme yetkisi doğurur, yalnız ilk kurulum kolaylığı olarak görülmemelidir.
Kimlik bilgilerini sağlayıcının desteklediği en dar kaynak ve işlem kapsamıyla verin; tüm ürünlerin TXT düzeyinde kısıt sunduğunu varsaymayın. Sınırlama mümkün değilse ayrı doğrulama bölgesi düşünülebilir. Temizlik diğer etkin challenge’ları korumalıdır. DNSSEC’te gerekli olan geçerli DS/DNSKEY/RRSIG güven zinciridir; yalnız anahtar döndürmeyi başka saate taşımak yeterli olmaz. DNSSEC anahtar döndürme ve DS güncelleme rehberi geçiş koşullarını açıklar. Hatalı imza zinciri ile glue/delegasyon erişim sorunlarını ayrı araştırın.
Wildcard, Ayrı Sertifika ve Anahtar Kapsamı
*.yourapp.com platformdaki tek etiketli tenant adlarını kapsayabilir; müşteri alan adlarını veya daha derin adları kapsamaz. Ayrı sertifika/anahtarlar bazı tenant işlemlerini ayırabilir, ancak aynı adı kapsayan mevcut wildcard anahtarının yetkisini kaldırmaz. RSA/ECDSA çift sunum istemci uyumluluğu için değerlendirilebilir; her istemci veya hız kazancı garanti değildir ve iki yaşam döngüsü yönetilir. Nginx ve Apache’de RSA/ECDSA çift sertifika rehberi bu seçeneğin koşullarını açıklar.
Yenileme zamanını desteklenen ARI yönlendirmesi veya sertifikanın gerçek geçerlilik süresine göre planlayın; kalan süreyi ve başarısızlıkları izleyin. İşleri yaymak yoğunluğu azaltabilir, fakat bütün kotaları veya ortak DNS arızasını çözmez. Sağlayıcıya özgü hatalar için hazırlanmış alternatif CA ayrı hesap, CAA yetkisi ve dağıtım desteği ister. Bekleme süresi anlamındaki backoff’u eski anahtara veya sertifikaya geri dönüşle karıştırmayın.
Kök Alan Adını SaaS Ucuna Yönlendirme
Standart CNAME aynı kayıt sahibi adındaki diğer verilerle birlikte bulunamaz; zone kökünde SOA ve NS gerektiğinden düz CNAME uygun değildir. ALIAS, ANAME veya CNAME flattening sağlayıcıya özgü yönlendirme özellikleridir; destek ve yanıt davranışı değişir. Bunlar yoksa platformun desteklediği sabit A/AAAA hedefleri veya www gibi bir alt alan kullanılabilir. Yalnız gerçekten desteklenen IPv6 yolunu yayımlayın.
Kök alanda CNAME, ALIAS ve flattening rehberi sağlayıcı seçeneklerini karşılaştırır. Uygulama yönlendirme kaydı DNS-01 delegasyonuyla aynı kayıt değildir. Kök için sertifika doğrulaması _acme-challenge.example.com gibi ayrı bir ad üzerinden yürür. Panelde her kaydın sahibini, türünü, hedefini ve amacını ayrı gösterin; uygulama DNS’ini değiştirmek sertifika üretimini veya tenant onayını kendiliğinden tamamlamaz.
Kubernetes ve VM Üzerinde Yaşam Döngüsü
Kubernetes’te cert-manager belgeleri üzerinden DNS01 sağlayıcı desteğini ve yetkileri doğrulayın. CNAME hedefini izleyerek yazma varsayılan değildir; uygun solver’da cnameStrategy: Follow ve hedef zone kimlik bilgileri gerekir. VM üzerinde seçilen ACME istemcisinin aynı delegasyonu nasıl yönettiğini kendi belgelerinden kontrol edin. Sertifika sürecini uygulama sürümünden ayrı yönetebilirsiniz; durum ve hesap anahtarları kaybolan “durumsuz” işçilerle yenileme güvenilir olmaz.
RFC 8555 ACME challenge yanıtının hesapla ilişkisini, Let’s Encrypt challenge belgeleri DNS-01’in kamusal TXT ve delegasyon koşullarını açıklar. api.example.com için challenge sahibi _acme-challenge.api.example.com’dur; _acme-challenge.example.com delegasyonu bunu kendiliğinden kapsamaz. Her istenen ad için doğru sahibi ve kayıt yazma yetkisini hesaplayın, ardından gerçek resolver görünümünü kontrol edin.
Erişim Kontrolü, İzleme ve Alan Adını Kaldırma
Alan adı bağlama, sertifika anahtarı okuma ve DNS güncelleme yetkilerini ihtiyaç duyan süreçlerle sınırlayın. Tenant değişiminde yeni yetki doğrulaması yapın; eski etkin eşlemeyi başka hesaba otomatik devretmeyin. Alan adı kaldırıldığında yönlendirmeyi ve yeni düzenleme/yenileme işlerini durdurun, müşteriye artık gerekmeyen trafik ve challenge delegasyonlarını kaldırmasını bildirin. Artık sahipsiz kalan hedefleri doğrulamasız başka tenant’a atamayın.
Desteklenen test ortamında tüm durum geçişlerini ve hata yollarını doğrulayın: yanlış tenant talebi, henüz görünmeyen TXT, çakışan işler, dağıtım hatası ve alan adı kaldırılması. Üretimde ise gerçek sertifika, hesap ve uç noktayı ayrıca kontrol edin. Anahtar ihlalinde yeni anahtar ve değiştirme/iptal planı gerekir; maruz kalmış anahtara sıradan geri dönüş yapmayın. Yenileme başarısı ile uçta sunulan sertifikayı ayrı metrikler olarak izleyin.
Alan Adını Etkinleştirmeden Önce Son Kontroller
Etkinleştirme için dört sonuç birlikte doğrulanmalıdır: güncel tenant-alan adı yetkisi, tamamlanmış CA düzenlemesi, sertifikanın hedef uçlarda sunulması ve doğru tenant’a uygulama yönlendirmesi. DNS-01 bunlardan CA doğrulaması için uygulama trafiğinden bağımsız bir yol sağlar. CAA, DNSSEC, API yetkileri veya dağıtım hataları kalan aşamaları yine engelleyebilir; bunları tek bir “DNS bekleniyor” durumunda gizlemeyin.
Müşteri talimatlarını sağlayıcının gerçekten desteklediği kayıt biçimine göre hazırlayın, doğrulama ve trafik kayıtlarını ayırın, gözlenen ilerlemeyi gösterin. Kalıcı durum, sınırlı tekrarlar, doğru TXT temizliği ve anahtar erişim kontrolüyle süreci işletin. DNS veya müşteri hesabı değiştiğinde yeniden değerlendirin. Başarılı bir başlangıç, alan adının gelecekte de aynı tenant’a yetkili kaldığını veya sertifikanın otomatik yenileneceğini tek başına kanıtlamaz.
