Let’s Encrypt Rate Limit’lerine Takılmadan Çok Alan Adında SSL: SAN/Wildcard, ACME Challenge ve Tatlı Stratejiler

Giriş: Bir Pazartesi Sabahı, Bir Yığın Domain ve Kırmızı Çizgiler

Hiç başınıza geldi mi? Pazartesi sabahı kahvenizi alıp CI/CD hattından akacak o pırıl pırıl dağıtımı izlemeye niyetlenmişsiniz, ama ekranda turuncu bir uyarı: rate limit aşıldı. Benim başıma ilk kez çoklu müşteri kurulumunda geldi. Onlarca alt alan adını tek seferde yayına almak zorundaydık, her şey yolunda derken Let’s Encrypt “bir dakika” dedi. O an anladım ki iş sadece sertifikayı çekmekle bitmiyor; zamanlama, gruplaştırma, challenge seçimi ve otomasyon en az sertifikanın kendisi kadar önemli.

Bu yazıda tam da bunu konuşacağız. Let’s Encrypt’in rate limit mantığını günlük hayattan örneklerle açacağım. SAN ve wildcard sertifikaların nerede parladığını, nerede köşeye sıkıştırdığını paylaşacağım. ACME challenge seçeneklerine net bir göz atıp, çok alan adını güvenle ve sakin kalarak nasıl yönetebileceğinizi anlatacağım. Mesela şöyle düşünün: Elinizde yüzlerce küçük taş var ve onları tek bir sepete doldurmaya çalışıyorsunuz. Sepetin kapasitesini, taşların boyutunu ve taşıma hızınızı iyi planlarsanız, kimse “taştı” demeden varışa ulaşırsınız. Hadi birlikte sepeti hazırlayalım.

Rate Limit Nedir, Sadece “Çok İstemek” Mi Suç?

Gerçekte ne sınırlanıyor?

Rate limit, basitçe “bir süre içinde ne kadar sertifika talep edebilirsin?” sorusunun yanıtı. Let’s Encrypt bunu birkaç katmanda düşünür: Alan adı başına toplam sertifika limiti, aynı isim setiyle tekrar tekrar sertifika alma limiti ve başarısız doğrulama denemeleri gibi güvenlik odaklı frenler. Tam rakamları ezberlemeye gerek yok; esas olan mantık. Aynı hareketleri kısa aralıklarla çok tekrarlarsanız, sistem “bir soluklan” der. Bu soluklanma anı, üretim trafiğinde can sıkabilir.

Ben ilk takıldığımda fark ettim: Sorun sadece miktar değildi, zamanlama ve tekrar da belirleyici. Bir grup sertifikayı beş dakika içinde üst üste denerseniz, limit duvarını hızlıca görürsünüz. Oysa talebi parçalara bölüp zamana yaymak, başarısız denemeleri azaltmak ve önceden staging ortamında prova yapmak işi tatlılaştırıyor. Resmi dokümanları sakin bir akşam üstü okumak iyi geliyor; Let’s Encrypt’in rate limit açıklamaları anlaşılır bir çerçeve sunuyor.

Gündelik hayattan bir benzetme

Mesela şöyle düşünün: Popüler bir fırından yüz poğaça istiyorsunuz. Fırın “hemen yaparım” demez; tepsileri ardışık çıkarır, o arada siz de sırada kalırsınız. Sertifikalar da öyle. Tek tepside her şeyi pişirmek yerine, seri üretim ritmi kurmak gerekir. Üstelik bir tepsiyi yaktığınızda (başarısız doğrulama) diğer tepsilerin de gecikmesi kaçınılmaz olur. İşin püf noktası, tepsileri doğru boyutta ve doğru aralıklarla fırına vermek.

SAN mı Wildcard mı? Ne Zaman Hangisi İşe Yarar?

SAN sertifikaların tatlı yanı

SAN (Subject Alternative Name) sertifikalar, bir sertifikada birden fazla alan adını ve alt alan adını barındırmanızı sağlar. Bu, “tek taşla birkaç kuş” etkisi yaratır: Yönetim basitler, yenileme akışı sadeleşir. Mesela müşteri paneli, API, CDN uçları ve birkaç özel alt alanı tek SAN sertifikasında toplayabilirsiniz. Ama burada akılda tutmanız gereken iki şey var: Sertifikanıza eklediğiniz her isim onu yenileme ve dağıtım sırasında sorumluluğa dönüştürür ve pratik bir üst sınır bulunur. Yani her şeyi tek sepete doldurmak cazip dursa da, tüm yumurtaları aynı sepete koymanın günlük riskleri vardır.

Wildcard’ın gücü ve sınırı

Wildcard (*.example.com) ise adeta joker kartı gibi. Tek hamlede aynı kökün altındaki birçok alt alan adını kapsarsınız. Yeni bir alt alan adı açıldığında, çoğu durumda yeniden sertifika almadan işiniz yürür. Ama bir şartla: Wildcard almak için DNS-01 challenge gerekir. Bu da DNS sağlayıcınızla otomasyon kurmayı zorunlu kılar. Ayrıca wildcard, kök alan adını (example.com) otomatik kapsamaz; onu ayrıca eklemeyi unutursanız, beklenmedik bir 443 sürprizi yaşayabilirsiniz. Ben genellikle kök alan adı + wildcard kombinasyonunu aynı sertifikaya koyarım; pratikte hayat kurtarır.

Hibrit düşünmek çoğu zaman daha iyi

Gerçek dünyada en iyi sonuç, çoğu zaman hibrit yaklaşımdan gelir. Kritik servisleri (panel, ödeme, api) tek bir SAN altında toplayıp, dinamik ve çok sayıda alt alan adı kullanan bölümler için wildcard seçmek gibi. Böylece bir yandan yenileme trafiğini dengeler, diğer yandan iş birimlerinin bağımsız ritmini korursunuz. Unutmayın, amaç kolaylık kadar izlenebilirlik ve hata izolasyonu. Bir sertifika sorun çıkardığında tüm siteler yerine sadece ilgili küme etkilenmeli.

ACME Challenge’ları Sade Sade: HTTP-01, DNS-01 ve TLS-ALPN-01

HTTP-01: Dosyayı koy ve doğrulat

HTTP-01 gözünüzün önüne rahatça canlanır: Sunucuda .well-known/acme-challenge altında bir dosya yayınlarsınız ve Let’s Encrypt onu GET ile kontrol eder. Tek sunuculu, doğrudan internete açık kurulumlar için idealdir. CDN veya WAF arkasında ise bazen ekstra kural gerekir; çünkü istekler ters vekillerde kaybolabilir. Yük dengeleme altındaki çoklu sunucularda, dosyanın tüm nodelara erişmesini ya da akıllı yönlendirme yapmayı planlamak şart.

DNS-01: TXT ile kapıyı açmak

DNS-01 wildcard için mecburi ve dağıtık mimarilerde çoğu zaman en sağlam seçenek. Bir TXT kaydı üreterek alan adının kontrolünü kanıtlarsınız. Buradaki incelik, DNS sağlayıcınızın API’siyle otomasyonu iyi kurmak ve TTL/propagation gecikmelerine hazırlıklı olmak. Ben her zaman kayıt eklenince birkaç saniye bekleme, ardından birkaç bağımsız resolver ile doğrulama testi yapma alışkanlığını tavsiye ederim. Özellikle yoğun günlerde DNS’in bitiş çizgisine gelişini görmeden start’a basmayın.

TLS-ALPN-01: Daha spesifik durumlar

TLS-ALPN-01 443 portunda ALPN uzantısıyla çalışır. Bazı özel altyapılarda şık bir çözüm olabilir, ama çoğu ekip için HTTP-01 ve DNS-01 kombinasyonu yeterince pratik. Hangi challenge’ı ne zaman seçeceğinizi kararsızlıkta bırakırsanız, Let’s Encrypt’in challenge türlerine dair sayfası aklınızı netleştirir. Genel kural basit: CDN/WAF veya çoklu node karmaşanız varsa DNS-01, basit tek node’da hızlı kurulumsa HTTP-01.

Çok Alan Adı İçin Strateji: Kümeler, Zamanlama ve Staging ile Provalar

İsimleri mantıklı kümelere ayırmak

Ben önce projeyi küçük takımlara bölerim: çekirdek servisler bir küme, pazarlama alt alanları başka bir küme, müşteriye özel alt alanlar ayrı bir küme gibi. Her kümeye ayrı sertifika ritmi tanımlamak, yenileme gününüzü sakinleştirir. Bir kümeyi SAN ile, diğerini wildcard ile çözmekten çekinmeyin. Böylece limitlere tek yönden yüklenmez, manevra alanı açarsınız.

Zamanlamayı yaymak, yenilemeyi basamaklandırmak

Rate limitten kaçınmanın en tatlı yolu, sertifika taleplerini zamana yaymak. Otomasyonunuza jitter eklemek, yani yenileme saatini küçük rastgele sapmalarla kaydırmak, aynı dakikada yüzlerce isteğin yığılmasını önler. Sertifikaların hepsi 90 gün boyunca geçerli; bu pencereyi iyi kullanıp yenilemeyi kademeli hale getirmek stresi azaltır. Unutmayın, başarısız denemeler de sayaçları etkiler; bu yüzden önce prova, sonra sahne.

Staging ortamı ve kuru koşu

Benim en sevdiğim kural: Önce staging, sonra prod. Let’s Encrypt, limitleri farklı ama davranışı benzer bir staging ortamı sunuyor. Otomasyonunuzun challenge oluşturma, DNS/HTTP yayma, doğrulama ve sertifikayı depolama adımlarını burada koşun. Hatta “kuru koşu” yapıp, DNS kayıtlarının gerçekten göründüğünü birkaç resolver üzerinden teyit etmeden prod’a geçmeyin. Bu küçük ritüel, canlıda atacağınız yanlış adımların çoğunu perde arkasında eritir.

Otomasyonun İskeleti: ACME İstemcisi, DNS API ve Geri Basınç

İstemci seçimi ve sade boru hattı

İster Certbot kullanın, ister lego ya da acme.sh; önemli olan boru hattınızı sade tutmak. “Challenge üret → kanıtı yerleştir → doğrula → sertifikayı çek → gizli anahtarı ve zinciri güvenli sakla → servise sıfır kesintiyle yükle → sağlık kontrolü” zinciri net ve gözlemlenebilir olmalı. Her adımda anlamlı log üretmek, sorun çıktığında paniklemeden kuyrukları temizlemenizi sağlar.

DNS sağlayıcılarıyla konuşmak

DNS-01 kullanıyorsanız, sağlayıcınızın API’siyle güvenilir bir diyalog kurun. Başarısız isteklerde otomatik geri dönüş ve tekrar deneme mekanizması önemli. Rate limitleri tetiklememek için exponential backoff ile yeniden denemeyi, her denemede küçük bir jitter katmayı ihmal etmeyin. Propagation’ı beklerken doğrulama yapacak bağımsız resolver’ları elinizin altında tutmak da iyi bir alışkanlık.

Dağıtım sonrası küçük ama kritik dokunuşlar

Sertifikayı çekip sunucuya koyduktan sonra bitmiyor. Sunucu yazılımınızın yeniden yüklemesini kesintisiz yapmak, bağlantıları kırmadan yeni zinciri devreye almak, yine otomasyonun omzunda. Ekip içinde tarayıcı testleri, API smoke test’leri ve basit curl kontrolleri ile 2-3 dakikalık bir “yeşil ışık” töreni, geceleri rahat uyumanızı sağlar. Eğer tarayıcı uyumluluğu aklınızı kurcalıyorsa, Nginx/Apache’de ECDSA + RSA ikili SSL yaklaşımı hem hız hem uyumluluk tarafında güzel bir denge sunar.

Sık Düşülen Çukurlar: DNS TTL, CDN Katmanları ve Tekrar Denemeler

TTL’ler küçük, kayıtlar doğru mu?

Canlıda en sık gördüğüm aksilik, TTL’lerin yüksek olması ve eski TXT kayıtlarının gölgede kalması. Özellikle DNS-01’de, eski kayıt temizlenmeden yeni kayıt eklenince doğrulama takılır. Ben çözüm olarak “eskiyi temizle, yeniyi koy, birkaç bağımsız resolver ile görünürlüğü ölç, sonra doğrulat” ritmini öneriyorum. TTL’i makul seviyede tutmak ve kritik anlarda geçici olarak düşürmek de işe yarıyor.

CDN ve WAF arkası sürprizleri

HTTP-01’de CDN ya da WAF kullanıyorsanız, challenge yolunu bypass eden küçük bir kural hayat kurtarır. Bazı güvenlik duvarları .well-known yollarına alışkındır ama “bir şeyler” yine de önünü kesebilir. Trafigi kontrol eden her katmanın challenge isteğine saygı gösterdiğinden emin olun. Gözünüzün önünde olan engeller, canlıda en çok şaşırtanlardır.

Başarısız denemelerin dağ gibi büyümesi

Bir doğrulama başarısız olduğunda, refleks olarak tekrar tekrar denemek isteriz. Oysa bu davranış limit sayaçlarını davet eder. Sakin kalmak, log’u okuyup kök sebebi çözmek, sonra temiz bir denemeye geçmek en verimli yol. Otomasyon içinde “aynı ismi art arda hızla deneme”yi engelleyecek küçük bir fren, ansızın karşınıza çıkan duvarları inceltir.

Büyük Resim: Çok Kiracılı Düzenler, Audit ve İzlenebilirlik

Çok kiracılı (multi-tenant) senaryolarda akış

Bir platform onlarca müşteri alan adını yönettiğinde, hız caziptir ama izlenebilirlik daha değerlidir. Hangi alan adının hangi kümeye ait olduğunu, son yenilemenin ne zaman ve nasıl yapıldığını tek bakışta görmek isteyeceksiniz. Basit bir dashboard, hata oranları, doğrulama süreleri ve geri deneme sayılarıyla size ritmi fısıldar. Limit duvarına yaklaştığınızı önceden hissetmek, çoğu krizi başlamadan bitirir.

Güvenlikte makul çizgiler

Özel anahtarların saklandığı yer, erişim izinleri ve audit kayıtları göz ardı edilmemeli. Üretim ve staging anahtarlarını ayrı tutun, yedekleri şifreli saklayın, kimin neye dokunduğunu basitçe kaydedin. Sertifikanın sadece bir dosya değil, giriş anahtarı olduğunu ekip içinde sık sık hatırlatmak faydalı. Küçük kaçaklar büyük kapıları açabilir; bu yüzden kapı kolunu sağlamlaştırın.

Kapanış: Sakin Plan, Tatlı Otomasyon, Keyifli Yenilemeler

Toparlarsak: Let’s Encrypt’in rate limitleri; başvuru sayısını, tekrar denemeleri ve aynı isim setleriyle kurulan sertifikaları makul bir ritimde tutmak istiyor. Bizim işimiz, bu ritmi öğrenip akışımıza yedirmek. SAN ve wildcard’ı akıllıca harmanlayıp, alan adlarını işlevlerine göre kümelendirince yükünüz hafifliyor. ACME challenge seçiminde HTTP-01’in sadeliği ile DNS-01’in esnekliği arasında doğru dengeyi kurduğunuzda, karmaşık mimarilerde bile huzurla ilerliyorsunuz. Üstüne staging provası, jitter’lı yenileme ve sağlam loglama eklenince, o ürkütücü uyarılar bir anda sıradan bir bilgi notuna dönüşüyor.

Pratik bir tavsiye setiyle vedalaşalım: Sertifikaları kademeli yenileyin, başarısızlıklarda panik yerine kök sebebe gidin, DNS kayıtlarını iki farklı resolver ile kontrol edin, CDN/WAF arkasında challenge yollarını özel kural ile açık tutun. Ve mümkünse bir akşamüstü sakin kafayla rate limit dokümanını ve challenge türlerini gözden geçirin; küçük notlar büyük sürprizleri önler. Umarım bu yolculuk, sizin de sertifika rutinini bir “arkada tıkır tıkır işleyen” düzene dönüştürür. Bir dahaki yazıda görüşmek üzere; sertifikalarınız hep yeşil, log’larınız hep sakin kalsın.