Çok Alan Adında Sertifika Taleplerini Planlama
Çok sayıda alan adını yayına alırken rate limit sınırlarını planlamak gerekir. İş sadece sertifikayı çekmekle bitmiyor; zamanlama, gruplaştırma, challenge seçimi ve otomasyon en az sertifikanın kendisi kadar önemli.
Bu rehber, çok sayıda host adı için sertifika düzenini ve yenileme sürecini planlar. SAN ve wildcard kapsamını, ACME doğrulama seçeneklerini, güncel kota ayrımlarını ve hata yönetimini birlikte ele alır. Belirli bir istemcinin kurulum komutlarını vermek yerine, Certbot, lego veya acme.sh ile kurulacak akışın sağlaması gereken koşulları açıklar.
Let’s Encrypt Limitleri ve Yenileme Muafiyetleri
Kayıtlı Alan Adı, İsim Kümesi ve Hesap Limitleri
Let’s Encrypt limitleri tek bir “alan adı başına istek” sayısından oluşmaz. Kayıtlı alan adı Public Suffix List ile belirlenir: app.example.com ve api.example.com için example.com, blog.example.co.uk için example.co.uk. Aynı kayıtlı alan altındaki yeni sertifikalar ilgili ortak kotayı tüketir; hesabı veya alt alanı değiştirmek bu küresel kotayı sıfırlamaz. Aynı isim kümesi, hesap başına yeni sipariş ve isim/hesap başına doğrulama başarısızlığı ayrıca değerlendirilir.
3 Kasım 2026 tarihinde kontrol edilen resmî limit sayfasında yeni siparişler için hesap başına 3 saatte 300, kayıtlı alan için 7 günde 50 sertifika, aynı tam isim kümesi için 7 günde 5 sertifika ve isim/hesap başına saatte 5 doğrulama başarısızlığı sınırı bulunur. Bunlar token bucket yöntemiyle zaman içinde dolar; topluca sıfırlanan takvim haftası kotaları değildir. Yenileme muafiyetleri aşağıda açıklanmıştır; dağıtım öncesinde güncel değerleri ve seçilen profilin koşullarını yeniden kontrol edin.
İlk Sertifika ve Yenileme Bütçesini Ayırma
ARI (ACME Renewal Information) destekleyen istemci, CA’nın önerdiği yenileme aralığını izleyip siparişte değiştirdiği sertifikayı belirtir. Let’s Encrypt’in koşullarını karşılayan ARI yenilemeleri tüm oran limitlerinden muaftır: yeni siparişte eski sertifikayla en az bir ortak isim bulunmalı ve eski sertifika daha önce ARI ile değiştirilmemiş olmalıdır. ARI olmayan yenilemede aynı isim kümesi, sıra ve büyük/küçük harften bağımsız olarak tanınabilir; yeni sipariş ve kayıtlı alan limitlerinden muaf olsa da aynı-küme ve doğrulama-hatası limitleri kalır. Bu nedenle “yenilemeler hiç sınırlanmaz” varsayımıyla kapasite planlamayın.
SAN ve Wildcard Sertifika Seçimi
SAN ile Birden Fazla Adı Gruplama
SAN (Subject Alternative Name), tek sertifikada birden fazla gerekli host adını belirtir. Let’s Encrypt seçilen sertifika profiline bağlı olarak en fazla 100 tanımlayıcıya izin verir; bu üst sınır her profil için hedef boyut değildir. app.example.com ve api.example.com gibi aynı sorumluluk ve yaşam döngüsüne sahip adları gruplayabilirsiniz. İsim eklemek veya çıkarmak yeni bir küme oluşturabilir ve kota hesabını değiştirir. Büyük SAN listesi daha az sertifika yönetimi sağlarken, daha büyük sertifika ve birlikte yürütülen yenileme/dağıtım işlemleri getirir.
Wildcard Kapsamı ve DNS-01 Gereksinimi
*.example.com, app.example.com gibi tam bir alt alan etiketiyle eşleşir; example.com kökünü veya app.eu.example.com gibi daha derin adları kapsamaz. Kök gerekiyorsa ayrıca SAN olarak ekleyin. Let’s Encrypt wildcard için DNS-01 doğrulaması ister; HTTP-01 veya TLS-ALPN-01 yeterli değildir. Yeni ad wildcard kapsamına uyuyorsa sırf o ad açıldı diye yeniden sertifika almak gerekmez. Otomatik yenileme için sınırlı yetkili DNS API erişimi veya istemcinin desteklediği challenge yönlendirmesi planlanmalıdır.
Sertifikaları Sorumluluk Alanlarına Ayırma
Kritik servisleri küçük SAN kümelerine, uygun dinamik hostları ayrı wildcard kapsamlarına ayırmak bir seçenek olabilir. Grupları müşteri, yönetim yetkisi, anahtar erişimi ve dağıtım hedeflerine göre belirleyin. Farklı sorumlulukları tek anahtarda birleştirmek erişim ve hata etkisini büyütebilir. Birden fazla wildcard aynı kayıtlı alan kotasını paylaşabilir; parçalama bir kota atlatma yöntemi değildir. Seçimi, sertifika sayısı ve bağımsız yenileme ihtiyacını birlikte değerlendirerek yapın.
HTTP-01, DNS-01 ve TLS-ALPN-01 Seçimi
HTTP-01: Port 80 ve Challenge Dosyası
HTTP-01, http://alan-adı/.well-known/acme-challenge/TOKEN adresindeki yanıtı doğrular ve ilk erişim dışarıdan port 80 üzerinden yapılır. Let’s Encrypt yalnız HTTP/HTTPS şemalarına, 80/443 portlarına ve sınırlı sayıda yönlendirmeye izin verir; kapalı port 80 yerine doğrudan 443 seçilemez. CDN, WAF ve yük dengeleyiciler doğru yanıtı bütün olası ön uçlarda sunmalı veya desteklenen biçimde merkezi doğrulama sunucusuna yönlendirmelidir. Wildcard için bu yöntemi kullanmayın.
DNS-01: TXT Kaydı ve Yayılım Kontrolü
DNS-01, _acme-challenge altında gereken TXT değerini yayımlar. Wildcard ve kök alan aynı anda doğrulanırken aynı ad altında birden fazla TXT değeri bulunabilir; bir işlem diğerinin etkin değerini silmemelidir. DNS sağlayıcısının tüm yetkili sunuculara yayılımını ve varsa API tamamlanma durumunu kontrol edin. Yetkili sunucu sorguları ve bağımsız çözümleyiciler yararlı teşhis sağlar, ancak farklı anycast noktalarından bakan CA’nın anında aynı yanıtı göreceğini garanti etmez.
TLS-ALPN-01: Port 443 ve İstemci Desteği
TLS-ALPN-01, port 443 üzerinde challenge’a özel ALPN işleyişi ve doğrulama yanıtı gerektirir; sıradan HTTPS hizmeti tek başına yeterli değildir. İstemcinin ve TLS sonlandıran bileşenin desteğini doğrulayın. Wildcard vermez. Resmî challenge belgelerini ağ topolojisiyle birlikte değerlendirin: HTTP-01 için port 80 ve bütün ön uçlar, DNS-01 için güvenli DNS otomasyonu, TLS-ALPN-01 için doğrulama trafiğini karşılayabilen TLS katmanı gerekir.
İlk Dağıtım, Staging ve Kademeli Yenileme
İsimleri Yaşam Döngüsüne Göre Gruplama
İsim envanterine sertifika sahibi, kayıtlı alan, SAN kümesi, anahtar türü ve dağıtım hedefini yazın. İlk sertifikaları ve sonradan değişen isim kümelerini, muafiyete uygun yenilemelerden ayrı hesaplayın. Kademeli dağıtımda küçük bir kümeyle başlayıp gerçek doğrulama ve yükleme sonucunu izleyin. Aynı kayıtlı alanın diğer ekipler veya hesaplar tarafından yapılan sertifika talepleri ortak kotayı etkileyebilir; tek kuyruğun sayacı tüm kullanımın eksiksiz görünümü değildir.
ARI, Gerçek Geçerlilik Süresi ve Jitter
ARI desteğini yalnız istemci adına bakarak varsaymayın; kullandığınız sürümün ARI bilgisine göre yenileme ve yerine-geçen sipariş işlevini doğrulayın. CA’nın önerdiği aralıkta rastgele zaman seçimi ve küçük iş kümeleri kullanın. ARI yoksa sertifikanın gerçek başlangıç/bitiş zamanına göre güvenli bir yenileme aralığı belirleyin; Let’s Encrypt entegrasyon rehberi normalde ömrün üçte biri kalınca, 10 günden kısa sertifikalarda yarısı kalınca yenilemeyi yedek yaklaşım olarak önerir. Sabit 90 günlük ömür veya her sertifika için 30 gün önceden yenileme varsaymayın.
Staging ile Üretimi Ayırma
Let’s Encrypt staging ortamı ayrı ACME uç noktası, hesap ve limit değerleri kullanır. Staging sertifikaları normal tarayıcı güven depolarında güvenilir değildir; üretim sertifikası yerine yüklemeyin ve test köklerini günlük kullanılan güven deposuna eklemeyin. Challenge oluşturma, yayılım, doğrulama, saklama ve hata akışını ayrı test çıktılarıyla sınayın. Üretime geçerken doğru CA uç noktasını, hesabı, anahtar erişimini ve dağıtım yolunu açıkça seçin. Staging başarısı üretim kotası veya istemci güveni için garanti değildir.
ACME İstemcisi, DNS API ve İşlem Kuyruğu
Doğrulama ve Dağıtım Adımları
İstemcinin desteklediği akış şu adımları kapsamalıdır: mevcut sertifika kaydını ve yenileme zamanını kontrol et; gerekli siparişi oluştur; challenge değerlerini yayımla; doğrula; sertifika ve gerçek CA zincirini al; özel anahtarla eşleşmesini ve SAN kapsamını kontrol et; güvenli kalıcı depoya yaz; yapılandırmayı sınayıp servise yükle; yeni bağlantıda sunulan sertifikayı doğrula. Konteyner yeniden başladığında mevcut sertifika/hesap kayıtlarını silip yeniden sipariş vermeyin. Kalıcı kayıt ve tek koordinatör gereksiz tekrarları azaltır.
DNS Yetkileri ve Yeniden Deneme Kuralları
DNS API yetkilerini gerekli zone ve işlemlerle sınırlayın; tüm DNS hesabının anahtarını her web sunucusuna dağıtmak yerine ayrı doğrulama bileşeni değerlendirilebilir. CNAME ile challenge adını başka TXT adına yönlendirmek ve NS kayıtlarıyla challenge alt bölgesini yetkili sunuculara devretmek farklı yöntemlerdir. Let’s Encrypt ikisini takip edebilir, ancak istemcinin hedef zone’a yazma desteği ayrıca gerekir. _acme-challenge.example.com devri, _acme-challenge.app.example.com adını otomatik kapsamaz; gereken her sahibi doğrulayın. Geçici API hatalarında sınırlı geri çekilme ve jitter, kota hatasında bildirilen Retry-After uygulanmalıdır.
Yenilenen Sertifikayı Sunucuda Doğrulama
Yeni sertifika dosyasının bulunması sunucunun onu kullandığını kanıtlamaz. Anahtar eşleşmesini, SAN’ları, zinciri ve süreleri doğrulayıp kullanılan sunucunun yapılandırma testini çalıştırın; ardından desteklenen yeniden yükleme yöntemini kullanın ve yeni bağlantılarda sunulan sertifikayı kontrol edin. Uygulama sağlık testlerini ve geri dönüş yolunu da doğrulayın; kesintisizlik ölçülmeden garanti edilmez. Nginx/Apache’de RSA ve ECDSA ikili sertifika rehberi iki kimlik doğrulama yolunun ayrı sınanmasını açıklar; iki sertifika her eski istemciye uyum veya otomatik hız artışı sağlamaz.
DNS Önbelleği, CDN ve Doğrulama Hataları
TXT Kayıtları ve Negatif Önbellek
DNS TTL, sağlayıcının yetkili sunuculara kayıt yayma süresinden ayrıdır. TTL değiştirildiğinde daha önce önbelleğe alınmış yanıtlar eski süreleriyle kalabilir. NXDOMAIN veya NODATA gibi negatif yanıtların SOA üzerinden belirlenen ayrı önbellek ömrü vardır; yeni TXT kaydının TTL’sini düşürmek bunları temizlemez. Geçişi önceden planlayın. Eşzamanlı challenge değerlerini koruyun, yalnız tamamlanmış işlemlerin artık kullanılmayan TXT değerlerini temizleyin ve RRset’in tamamını düşünmeden silmeyin.
CDN ve WAF Arkasında HTTP-01
HTTP-01 yolunun kimlik doğrulama ekranına, uygulama ön denetleyicisine veya yanlış önbellek yanıtına takılmadığını kontrol edin. CDN/WAF istisnasını yalnız gereken challenge yoluna ve doğru içeriğe uygulayın; tüm site korumalarını kapatmayın. Dış ağlardan port 80 üzerinden bütün olası ön uçları kontrol edin. Sertifika yetkilisinin doğrulayıcı IP listesi sabit değildir; yalnız eldeki birkaç IP’ye izin vermek kalıcı bir çözüm değildir. DNS-01’e geçiş de kendi yetki ve yayılım gereksinimleriyle planlanmalıdır.
Başarısız Doğrulamalarda Retry-After
ACME hata türünü, ilgili isim/küme kapsamını ve Retry-After bilgisini kaydedin. DNS, yetki veya erişim hatasını düzeltmeden aynı doğrulamayı hızla yinelemeyin. Geçici hatalarda sınırlı exponential backoff ve jitter kullanın; bildirilen en erken tekrar zamanından önce denemeyin. Limit dolumu zaman içinde olur; sertifikayı iptal etmek kotayı geri getirmez. Gerçek bir kapasite gereksiniminde desteklenen limitler için önceden artış başvurusu yapın; bu, anlık kota sıfırlama yolu değildir.
Çok Kiracılı Sistemlerde İzleme ve Anahtar Yönetimi
Sertifika Sahipliği ve İşlem Kayıtları
Her sertifika için sorumlu ekip, isim kümesi, geçerlilik süresi, planlanan yenileme, son başarılı dağıtım ve hata durumu izlenebilir olmalıdır. Sipariş sayısındaki beklenmedik artış, uygulama başlatılırken tekrar sipariş verilmesi veya kaybolan istemci verisi gibi hatalara işaret edebilir. Koordinatör veya süreli sahiplik kilidi aynı kaydın eşzamanlı yenilenmesini azaltabilir; kilit süresi, başarısız işlem ve yeniden başlatma sonrası kurtarma da tasarlanmalıdır. Sırları ve özel anahtarları işlem loglarına yazmayın.
Özel Anahtarların Korunması ve Kurtarma
ACME hesap anahtarı, sertifika özel anahtarı ve DNS API kimlik bilgileri farklı yetkilerdir; erişimlerini ayrı yönetin. Özel anahtarları korunan depoda ve gerektiğinde şifreli yedekte tutun. Şüpheli anahtar sızıntısında yeni anahtarla gerekli adları kapsayan sertifika hazırlama, dağıtma ve etkilenen sertifikaları iptal etme sürecini birlikte yürütün; sızmış anahtara geri dönmeyin. Sertifikayı yenilemek eski sertifikayı kendiliğinden iptal etmez. Bu acil yolu olağan dönemde test edin; ilgisiz SAN eklemeyi kota sorununun varsayılan çözümü yapmayın.
Dağıtım ve Yenileme Kontrol Listesi
Önce gerekli host adlarını ve wildcard’ın gerçek kapsamını belirleyin. Her grubun ilk sipariş, değişen isim kümesi veya ARI’ye uygun yenileme olduğunu ayırın. Staging’de akışı doğrulayın; üretim için gerekli kota, erişim ve hesap koşullarını kontrol edin. DNS TXT değerleri, port erişimi ve bütün ön uçlar hazır olduktan sonra küçük kümelerle dağıtın. Sertifika alımı kadar serviste sunulan zincirin ve uygulama sağlığının doğrulanması da tamamlanma koşuludur.
Yenileme zamanını gerçek sertifika ömrü ve ARI bilgisiyle belirleyin; geçici hatalara tekrar payı bırakın. DNS önbelleğini, etkin challenge değerlerini ve Retry-After sürelerini koruyun. Değişiklik öncesinde güncel limitleri ve challenge gereksinimlerini yeniden okuyun. İyi gruplama ve koordinasyon gereksiz talepleri azaltır, ancak tek başına hiçbir kota hatası yaşanmayacağını garanti etmez.
