Let's Encrypt "Too Many Certificates" Limit Hatası ve Bekleme Süresi

Sunucuyu yeniden kurdunuz, yapılandırmayı birkaç kez düzelttiniz, aradan certbot komutunu beş altı kez çalıştırdınız. Sonunda her şey yerine oturdu ve son bir kez sertifika almak için komutu verdiğinizde ekranda şu satır belirdi:

Error creating new order :: too many certificates (5) already issued for this exact
set of identifiers in the last 168h0m0s, retry after 2026-08-21 09:14:52 UTC

Site hâlâ HTTPS'siz, üretim ortamına geçilecek ve hata mesajı yedi gün beklemekten söz ediyor. İlk refleks genellikle aynıdır: komutu farklı bayraklarla tekrar denemek, sertifikayı silip yeniden almayı denemek, hatta yeni bir hesap oluşturmak. Bunların hepsi durumu kötüleştirir, çünkü her deneme aynı sayacı bir tık daha ileri iter.

Bu yazıda önce hata metninden hangi limite takıldığınızı okumayı, sonra ne zaman serbest kalacağınızı dakika hassasiyetinde hesaplamayı göstereceğim. Yaygın inanışın aksine çoğu durumda tam yedi gün beklemeniz gerekmez; limitler bir gün belirli bir saatte topluca sıfırlanmaz, kapasite kademeli olarak geri gelir. Yazının ikinci yarısı ise asıl kıymetli olan tarafta: bu hatayı bir daha hiç görmemek için denemeleri nerede yapmanız, ne zaman yeni sertifika alıp ne zaman yenilemeniz ve alan adlarını nasıl gruplamanız gerektiğinde.

Hata Metninden Hangi Limite Takıldığınızı Okumak#

Let's Encrypt'in tek bir "limit"i yoktur; birbirinden bağımsız çalışan ve farklı sürelerde serbest kalan birkaç kuralı vardır. Hata metnindeki ifade, hangisine çarptığınızı kesin olarak söyler. Yanlış limiti varsayıp yanlış çözümü uygulamak, bu konuda kaybedilen zamanın büyük kısmını açıklar.

En sık karşılaşılan ilk satırdır ve mesajdaki exact set of identifiers ifadesi kritiktir: sınır, alan adının kendisine değil, sertifikadaki alan adı kümesinin tamamına uygulanır. ornek.com + www.ornek.com içeren bir sertifika ile yalnızca ornek.com içeren bir sertifika, bu limit açısından iki farklı kümedir. Bu ayrım hem sizi kilide sokan hem de aynı zamanda kilitten çıkaran şeydir; birazdan buna döneceğiz.

Let's Encrypt Limitleri ve Gerçek Değerleri#

Aşağıdaki tablo, üretim ortamındaki güncel sınırları ve — asıl önemlisi — kapasitenin hangi hızda geri geldiğini gösterir:

İki satırın "tüm hesaplar ortak" olması önemli bir ayrıntıdır: yeni bir ACME hesabı açarak ya da başka bir sunucudan deneyerek bu iki limiti aşamazsınız. Limit alan adına bağlıdır, hesabınıza değil. Yeni hesap açma denemesi yalnızca IP başına hesap limitine takılmanıza yol açar.

"Kayıtlı alan adı" (registered domain) kavramı da yanlış anlaşılır. blog.ornek.com, panel.ornek.com ve ornek.com için ayrı ayrı sertifika alsanız bile, üçü de aynı kayıtlı alan adı olan ornek.com sayacından düşer. Yüzlerce alt alan adı barındıran bir panelde 50'lik sınıra çarpmanın yolu budur.

"Yedi Gün Bekleyeceğim" Yanlış: Kova Kademeli Dolar#

Bu konudaki en yaygın yanlış bilgi, limitin "haftada bir sıfırlandığı" ve dolayısıyla yedi gün beklemek gerektiğidir. Gerçekte sistem bir jeton kovası gibi çalışır: kova belirli bir kapasiteye sahiptir ve sabit bir hızla sürekli dolar. Her sertifika bir jeton harcar; kova boşaldığında hata alırsınız, ama bir sonraki jeton düştüğü anda tekrar deneyebilirsiniz.

Tablodaki geri dönüş hızları tam olarak bunu ifade eder. Aynı alan adı kümesi için 7 günde 5 sertifika sınırı, kabaca 34 saatte bir sertifikalık kapasite demektir. Yani beş sertifikayı arka arkaya bir saat içinde tükettiyseniz:

• Bir sonraki sertifikayı yaklaşık 34 saat sonra alabilirsiniz, yedi gün sonra değil.
• Yedi günün sonunda kova tamamen dolar ve yeniden beş sertifikalık hakkınız olur.

Kayıtlı alan adı limitinde durum daha da rahattır: 202 dakikada bir kapasite geri gelir, yani yaklaşık üç buçuk saatte bir yeni sertifika. Elli sertifikayı tüketmiş bir panelde bile ertesi sabah birkaç sertifikalık alan açılmış olur.

Buradan çıkan pratik sonuç şudur: hata mesajındaki retry after tarihi mutlak bir hüküm değil, o anki kova durumuna göre hesaplanmış bir tahmindir. O tarihi beklemek her zaman doğru sonucu verir, ama çoğu durumda gereğinden uzundur. Acil bir üretim ihtiyacınız varsa, bir sonraki jetonun düşeceği saati hesaplayıp o saatte tek bir deneme yapmak daha akılcıdır. Tek bir deneme diyorum, çünkü döngüye giren bir betik kova dolar dolmaz jetonu yiyip sizi aynı yerde tutar.

Ne Zaman Serbest Kalacağınızı Hesaplamak#

Bekleme süresini hesaplamak için son sertifikalarınızın hangi saatlerde üretildiğini bilmeniz gerekir. Bunun iki kaynağı vardır.

Birincisi kendi sunucunuzdaki Certbot günlükleridir:

# Limit hatalarını ve zamanlarını çıkar
sudo grep -i "rateLimited\|too many" /var/log/letsencrypt/letsencrypt.log

# Sunucudaki mevcut sertifikaları ve bitiş tarihlerini listele
sudo certbot certificates

İkincisi ve daha güvenilir olanı, sertifika şeffaflık kayıtlarıdır. Sunucuyu yeniden kurduysanız yerel günlükler silinmiş olabilir, ama üretilen her sertifika genel kayıtlara işlenir:

# Son üretilen sertifikaları tarihleriyle listele
curl -s 'https://crt.sh/?q=ornek.com&output=json' \
  | jq -r '.[] | "\(.not_before)  \(.name_value)"' | sort -r | head -20

Çıktıdaki ilk beş satırın tarihine bakın. Aynı alan adı kümesi için üretilmiş en eski sertifikanın üzerinden 34 saatten fazla geçmişse bir jetonunuz hazır demektir. Bu sorgu ayrıca çok sık gözden kaçan bir şeyi de gösterir: bazen sınırı tüketen sizin denemeleriniz değil, aynı alan adı için sertifika üreten ikinci bir sistemdir. Panel üzerinden otomatik SSL kuran bir barındırma hesabı, eski bir sunucuda hâlâ çalışan bir zamanlayıcı ya da bir CDN entegrasyonu aynı kümeyi paylaşıyorsa, siz hiçbir şey yapmasanız bile kova boşalır.

Doğrulama Hatası Limiti: Asıl Sizi Kilitleyen Bu#

Deneyimde en sık kilit yaratan kural, sertifika sayısı değil doğrulama hatası limitidir: alan adı başına saatte 5 başarısız doğrulama. Bir yapılandırma hatasını düzeltmeye çalışırken komutu üst üste altı kez çalıştırmak yeterlidir.

Bu limitin iyi tarafı hızlı geri dönmesidir: yaklaşık 12 dakikada bir yeni deneme hakkı açılır. Kötü tarafı ise, doğrulama başarısız olduğu sürece sertifika sayacına hiç dokunmadan sizi ilerlemekten alıkoymasıdır. Tipik nedenler şunlardır:

1. 80 portu kapalı ya da başka bir servis dinliyor. HTTP-01 doğrulaması, Let's Encrypt sunucularının alan adınıza 80 portundan ulaşabilmesini gerektirir. Güvenlik duvarı, yalnızca 443'e izin veren bir kural ya da yanlış bir yönlendirme bu adımı bozar.
2. DNS henüz yayılmamış. Alan adı hâlâ eski IP'yi gösteriyorsa doğrulama dosyası yanlış sunucuda aranır.
3. DNS-01'de TXT kaydı erken sorgulanıyor. Kayıt eklenmiş ama yayılmamışken doğrulama tetiklenirse hata alırsınız. Bu, joker sertifikalarda en sık görülen sorundur.
4. Webroot dizini yanlış. .well-known/acme-challenge altındaki dosyaya web sunucusu üzerinden erişilemiyordur.

Doğrulamanın gerçekten çalışıp çalışmadığını, sertifika sayacını hiç harcamadan sınayabilirsiniz:

# Doğrulama zincirini uçtan uca dener, gerçek sertifika üretmez
sudo certbot certonly --dry-run --webroot -w /var/www/html -d ornek.com -d www.ornek.com

Doğrulama mekanizmasının arka planda nasıl işlediğini merak ediyorsanız ACME protokolü nedir yazısı, hangi adımda hangi kontrolün yapıldığını ayrıntılı anlatıyor.

Denemeleri Staging Ortamında Yapın#

Bu hatayı bir daha yaşamamanın en etkili yolu tek bir alışkanlıktır: üretim ortamına yalnızca çalıştığından emin olduğunuz komutu gönderin. Let's Encrypt bunun için ayrı bir test ortamı sunar ve bu ortamın limitleri üretim ortamının kat kat üzerindedir; pratikte deneme yaparken takılmanız neredeyse imkânsızdır.

# En pratik yol: Certbot'un prova modu (staging'e gider, dosya yazmaz)
sudo certbot certonly --dry-run --nginx -d ornek.com -d www.ornek.com

# Staging'den gerçek dosya üretip yapılandırmayı test etmek için
sudo certbot certonly --test-cert --nginx -d ornek.com -d www.ornek.com

# Sunucu adresini elle vermek isterseniz
sudo certbot certonly \
  --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --nginx -d ornek.com

--dry-run ile --test-cert arasındaki farkı bilmek işinizi kolaylaştırır. --dry-run süreci baştan sona simüle eder ama diske hiçbir sertifika yazmaz; "doğrulama geçiyor mu" sorusunun cevabıdır. --test-cert ise gerçek dosyalar üretir, böylece Nginx yapılandırmanızı, izinleri ve yeniden yükleme kancalarını sınayabilirsiniz.

Staging sertifikalarının hiçbir tarayıcı tarafından güvenilir kabul edilmediğini unutmayın; bu ortamın kök sertifikaları (STAGING) Pretend Pear X1 gibi bilinçli olarak şakacı adlar taşır ve hiçbir güven deposunda bulunmaz. Tarayıcıda uyarı görürseniz bu bir arıza değil, beklenen davranıştır. Test bittiğinde staging sertifikasını silip üretim ortamından gerçek sertifikayı alın:

sudo certbot delete --cert-name ornek.com
sudo certbot certonly --nginx -d ornek.com -d www.ornek.com

Yeni Sertifika Almak Yerine Yenileyin#

Limite takılan kullanıcıların büyük kısmı, aslında ihtiyaç duymadıkları bir işlemi yapmaktadır: mevcut sertifika hâlâ geçerliyken sıfırdan yenisini almak. Bir dizin yolu değiştiğinde, Nginx yeniden yapılandırıldığında ya da sunucu taşındığında refleks olarak certbot certonly çalıştırmak sayacı hızla tüketir.

Aradaki fark şudur: aynı alan adı kümesi için yapılan yenilemeler, kayıtlı alan adı ve yeni sipariş limitlerinden muaftır. Yani doğru komutu kullandığınızda 50'lik sayaç hiç azalmaz. Üstelik modern Certbot sürümlerinin kullandığı yenileme bilgisi mekanizması (ARI) üzerinden yapılan yenilemeler bütün limitlerden muaf tutulur.

# Süresi yaklaşan tüm sertifikaları yeniler, yaklaşmayanlara dokunmaz
sudo certbot renew

# Zamanlayıcının gerçekten çalıştığını doğrulayın
systemctl list-timers | grep certbot

Üç davranıştan kaçının:

• certbot delete ile silip yeniden almak. Silmek sayacı geri getirmez; yalnızca yeni bir sertifika daha üretip sayacı bir tık daha ilerletirsiniz.
• --force-renewal bayrağını rutin hâline getirmek. Bu bayrak, sertifika daha 60 gün geçerli olsa bile yenisini üretir ve aynı kümeyi kullandığı için doğrudan 5'lik limite yürür. Yalnızca özel anahtarın sızması gibi gerçek bir gerekçe varsa kullanın.
• Yapılandırma denerken üretim ortamında döngüye girmek. Bir betik hata alıp yeniden deniyorsa, saatler içinde hem sipariş hem doğrulama limitini tüketir.

Yenileme sürecinin ayrıntıları ve kancalarla otomasyonu için certbot ileri kullanım ve SSL otomatik yenileme yazıları iyi bir devam noktası.

Alan Adlarını Tek Sertifikada Toplayın#

Limitlere takılmanın yapısal çözümü, sertifika sayısını azaltacak biçimde alan adlarını gruplamaktır. Bir sertifika 100 kimliğe kadar taşıyabilir, dolayısıyla çoğu kurulumda tek bir sertifika fazlasıyla yeterlidir.

# Kötü: her ad için ayrı sertifika, üç ayrı küme, üç kat tüketim
sudo certbot certonly --nginx -d ornek.com
sudo certbot certonly --nginx -d www.ornek.com
sudo certbot certonly --nginx -d blog.ornek.com

# İyi: tek sertifika, tek küme
sudo certbot certonly --nginx -d ornek.com -d www.ornek.com -d blog.ornek.com

Burada bir noktaya dikkat edin: alan adı listesini her değiştirdiğinizde yeni bir kimlik kümesi oluşur ve o küme için sayaç sıfırdan başlar. Bu, limite takıldığınızda işinize yarayan bir kaçış yoludur — listeye meşru bir alt alan adı ekleyerek yeni bir küme oluşturup sertifika alabilirsiniz. Ama bu yolu bilinçli kullanın; her seferinde listeyi oynatmak, sonunda kayıtlı alan adı başına düşen 50'lik sınıra çarpmanıza yol açar.

Çok sayıda alt alan adı üreten yapılarda — müşteri panelleri, önizleme ortamları, çok kiracılı uygulamalar — doğru araç joker sertifikadır. Tek bir *.ornek.com sertifikası sınırsız sayıda alt alan adını karşılar ve sayaçta yalnızca bir yer tutar; karşılığında DNS-01 doğrulaması yapmanız gerekir. Ayrıntılar için wildcard SSL nedir ve birden çok alan adını tek sertifikada birleştirmek için SAN multi-domain SSL yazılarına bakabilirsiniz.

Limite Takıldıysanız Site Nasıl Ayakta Kalır?#

Beklerken siteyi kapalı bırakmak zorunda değilsiniz. Sırasıyla şunları kontrol edin.

Mevcut sertifikanız hâlâ geçerli olabilir. Limit yalnızca yeni sertifika üretimini engeller; daha önce alınmış ve süresi dolmamış bir sertifika çalışmaya devam eder. Sunucuda duran dosyalara bakın:

sudo ls -l /etc/letsencrypt/live/
echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null \
  | openssl x509 -noout -dates

notAfter tarihi gelecekteyse yapmanız gereken tek şey, web sunucusunun bu dosyaları göstermesini sağlamaktır.

Sunucuyu sıfırdan kurarken eski sertifikaları taşıyın. Limit hatasının en can sıkıcı senaryosu, taşıma sırasında /etc/letsencrypt dizinini yedeklemeden yeni sunucuda sıfırdan sertifika almaya çalışmaktır. Bu dizinin tamamını (live, archive ve renewal alt dizinleriyle birlikte) kopyalarsanız yeni sunucu hiç sertifika üretmeden çalışmaya başlar.

Gerekirse geçici olarak başka bir sertifika otoritesi kullanın. Let's Encrypt'in limitleri yalnızca kendisine özeldir; ACME protokolünü konuşan başka ücretsiz otoriteler de vardır ve Certbot bunlarla --server parametresi üzerinden çalışabilir. Bu, bir günlük bir kesintiyi kapatmak için makul bir köprüdür.

Son olarak, bu hatayı yaşadıktan sonra yapılacak en değerli iş, nedenini not almaktır. Sertifika limitine takılmak neredeyse hiçbir zaman tek başına bir sorun değildir; genellikle "yenileme otomasyonu düzgün kurulmamış" ya da "iki ayrı sistem aynı alan adına sertifika üretiyor" gibi daha büyük bir aksaklığın belirtisidir. Temel kurulumu gözden geçirmek isterseniz Let's Encrypt ile ücretsiz SSL kurulumu yazısı, doğru yapılandırmanın tamamını adım adım anlatıyor.

Sıkça Sorulan Sorular#

Let's Encrypt limit hatasında tam olarak ne kadar beklemem gerekir?#

Hangi limite takıldığınıza bağlıdır. Aynı alan adı kümesi için 5 sertifika sınırında kapasite yaklaşık 34 saatte bir geri gelir; kayıtlı alan adı başına 50'lik sınırda ise yaklaşık 3,5 saatte bir. Doğrulama hatası limiti çok daha hızlıdır, 12 dakikada bir yeni deneme hakkı açılır. Yani çoğu durumda tam yedi gün beklemeniz gerekmez.

Limit hatası aldım, sitem tamamen kapandı mı?#

Hayır. Limit yalnızca yeni sertifika üretimini engeller, mevcut sertifikanızı geçersiz kılmaz. Daha önce alınmış ve süresi dolmamış bir sertifikanız varsa site HTTPS üzerinden çalışmaya devam eder. Sorun, sertifikanız zaten dolmuşken limite takılırsanız çıkar; bu durumda mevcut sertifikayı yedekten geri yüklemek ya da geçici olarak başka bir otoriteden sertifika almak gerekir.

Yeni bir Let's Encrypt hesabı açarak limiti aşabilir miyim?#

Hayır. Sertifika sayısıyla ilgili iki ana limit alan adına bağlıdır ve tüm hesaplar için ortaktır; yeni hesap açmak bunları sıfırlamaz. Üstelik IP başına 3 saatte 10 hesap sınırı olduğu için, art arda hesap açma denemeleri sizi ikinci bir limite daha takar. Aynı şey farklı bir sunucudan denemek için de geçerlidir.

Staging ortamından aldığım sertifikayı canlıda kullanabilir miyim?#

Kullanamazsınız. Staging sertifikaları, hiçbir tarayıcının güven deposunda bulunmayan test kökleri tarafından imzalanır ve ziyaretçilere güvenlik uyarısı gösterir. Bu ortamın amacı yapılandırmanızı ve doğrulama sürecinizi sınamaktır. Test başarılı olduğunda staging sertifikasını silip aynı komutu prova bayrağı olmadan çalıştırarak üretim sertifikasını alırsınız.

Sertifikayı silersem limit sayacı sıfırlanır mı?#

Sıfırlanmaz. Sayaç, sunucunuzda duran dosyalara göre değil, sertifika otoritesinin ürettiği kayıtlara göre işler. Silmek yalnızca yerel dosyaları kaldırır; ardından yeni bir sertifika istediğinizde sayaç bir kez daha artar. Bu yüzden limite takıldığınızda silip yeniden denemek, durumu düzeltmek yerine bekleme süresini uzatır.

www ve alt alan adlarını neden tek sertifikada toplamalıyım?#

Çünkü limit, sertifikadaki alan adı kümesinin tamamına uygulanır ve her ayrı sertifika sayaçtan ayrıca düşer. Üç ad için üç sertifika almak, tek sertifika almaya göre üç kat kapasite tüketir. Bir sertifika 100 kimliğe kadar taşıyabildiği için çoğu kurulumda tek sertifika yeterlidir; alt alan adı sayısı sürekli artıyorsa joker sertifikaya geçmek daha sağlıklıdır.