SSL Sertifikasının Süresi Doldu: Certbot Yenileme Hatası Çözümü

Let's Encrypt sertifikanın süresi dolduysa yenileme dün bozulmadı. Certbot sertifikayı bitiş tarihinden epey önce yenilemeye çalışır; süresi dolmuş bir sertifika, yenilemenin haftalardır sessizce başarısız olduğunu ya da yeni sertifikanın alındığı ama web sunucusunun onu hiç yüklemediğini gösterir. Çözüm sırası neredeyse hep aynı: sunucunun gerçekte hangi sertifikayı sunduğuna bak, sudo certbot renew --dry-run çalıştır, neden başarısız olduğunu söyleyen tek satırı oku, onu düzelt, gerçek yenilemeyi yap ve web sunucusunu yeniden yükle.

Önce sunucunun gerçekte ne sunduğuna bak

Diskteki sertifikayla ziyaretçinin aldığı sertifika her zaman aynı değil. Sunucuya sor:

echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null | openssl x509 -noout -dates -issuer -ext subjectAltName

Sonra certbot'un elindekiyle karşılaştır:

sudo certbot certificates

Üç ihtimal var:

• İkisi de eski tarihi gösteriyor. Yenileme başarısız oluyor. Okumaya devam et.
• Certbot yeni tarihi, sunucu eskisini gösteriyor. Yenileme olmuş, web sunucusu yeniden yüklenmemiş. sudo systemctl reload nginx (ya da apache2) çalıştır ve bir dahakine kendiliğinden olsun diye deploy hook ekle (aşağıda Web sunucusu yeniden yüklenmemiş bölümünde).
• Sunulan sertifika Let's Encrypt'ten bile değil. Sunucunun önünde HTTPS'e cevap veren başka bir şey var: Cloudflare, hosting firmasının proxy'si ya da bir yük dengeleyici. Sunucuda yenilemek ziyaretçinin gördüğünü değiştirmez.

2026'da Let's Encrypt sertifikaları ne kadar geçerli?

Let's Encrypt'in sertifika ömrü sayfası şöyle diyor: "Since our initial launch in 2015, Let's Encrypt has offered certificates with 90-day lifetimes." Yani bugüne kadar 90 gün. Bu değişiyor. 2 Aralık 2025 tarihli Decreasing Certificate Lifetimes to 45 Days duyurusundaki takvim:

Tarih	Değişiklik
13 Mayıs 2026	İsteğe bağlı tlsserver profili 45 günlük sertifika veriyor
10 Şubat 2027	Varsayılan classic profil 64 günlük sertifikaya geçiyor
16 Şubat 2028	classic profil 45 günlük sertifikaya geçiyor

Aynı duyuru, "renewing at a hardcoded interval of 60 days will no longer be sufficient" diye uyarıyor: sabit 60 günde bir yenilemek artık yetmeyecek. Kendi yazdığın aylık bir cron satırıyla ya da iki ayda bir elle yeniliyorsan bu düzen Şubat 2027'de bozulur.

Güncel certbot bunu zaten hallediyor. Kullanıcı kılavuzuna göre Certbot 4.0.0'dan itibaren sertifika, ömrünün üçte birinden azı kaldığında yenilemeye hazır sayılıyor; 4.0.0 öncesinde bu sabit 30 gündü. Sürümünü certbot --version ile kontrol et.

Gözden kaçan bir değişiklik daha: Let's Encrypt süre dolumu hatırlatma e-postalarını 4 Haziran 2025'te bıraktı ("We will be ending this service on June 4, 2025"). Eski kurulumlar bu e-postaları güvenlik ağı olarak kullanıyordu. Kendin bir uyarı kurmadıysan artık haber gelmiyor.

adım: Yenileme hiç zamanlanmış mı?

Certbot kılavuzuna göre çoğu certbot kurulumu otomatik yenilemeyle hazır gelir ("Most Certbot installations come with automatic renewals preconfigured"). Seninkinde gerçekten öyle mi, bak:

systemctl list-timers | grep -i certbot
grep -rs certbot /etc/crontab /etc/cron.d/

Ubuntu ve Debian'da genelde certbot.timer (apt paketi) ya da snap.certbot.renew.timer (snap) görürsün. İkisi de olur. Burada systemd zamanlayıcısı ile cron aynı işi yapıyor; zamanlayıcının artısı, çıktısını journalctl'in saklaması:

journalctl -u certbot.service --since "-30 days" | tail -n 30
sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log

Hiçbir şey bulamazsan certbot kılavuzu eklenecek cron satırını veriyor. Günde iki kez, rastgele bir gecikmeyle çalışır; bu normal: "renew" sadece zamanı gelen sertifikalara dokunur, sık çalışması bir şeye mal olmaz.

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

Zaten bir zamanlama varsa ikincisini ekleme. Certbot ikisiyle de başa çıktığını söylüyor ama iki zamanlama hangi kaydın hangisinden geldiğini anlamayı zorlaştırır.

adım: Dry run çalıştır ve hatayı oku

sudo certbot renew --dry-run

--dry-run, Let's Encrypt'in test (staging) sunucusuyla konuşur; geçersiz test sertifikaları alır ve diske kaydetmez. Doğrulamayı gerçekten yaptığı için gerçek yenilemeyle aynı sebepten başarısız olur, ama canlı sertifikana ve istek limitlerine dokunmaz.

Önemli satırlar Domain:, Type: ve Detail:. En sık görülenler ve çözümleri aşağıda.

Sık görülen certbot yenileme hataları ve çözümleri

Port 80 kapalı

Type: connection, Detail: ... Timeout during connect (likely firewall problem).

nginx, Apache, webroot ve standalone eklentilerinin hepsi HTTP-01 doğrulamasını kullanır ve Let's Encrypt'in doğrulama türleri sayfası net: "The HTTP-01 challenge can only be done on port 80." HTTPS'e geçince port 80'i kapatanlar çok; yenileme 60 gün sonra ölür. Portu yeniden aç, http → https yönlendirmesini koru; Let's Encrypt HTTPS'e yönlendirmeleri takip ediyor.

sudo ufw allow 80/tcp

Bulut sağlayıcının güvenlik duvarına da bak (security group, paneldeki ağ güvenlik duvarı). İkisinin de port 80'e izin vermesi gerekiyor.

DNS başka yeri gösteriyor ya da eski bir AAAA kaydı var

Type: unauthorized ile Invalid response ... 404, ya da tanımadığın bir IPv6 adresinde zaman aşımı.

Sertifikadaki her ad için dig +short A ornek.com ve dig +short AAAA ornek.com çalıştır. Let's Encrypt'in IPv6 notlarına göre ilk bağlantıda her zaman IPv6 adresi tercih ediliyor ("will always prefer the IPv6 addresses for the initial connection"); IPv4'e sadece IPv6 bağlantısı zaman aşımına düşerse dönülüyor. Eski bir sunucuyu gösteren ve 404 dönen artık bir AAAA kaydı, A kaydı doğru olsa bile doğrulamayı bozar. Sil ya da düzelt.

Sunucunun önünde Cloudflare proxy'si var

Turuncu bulut açıkken Let's Encrypt'in /.well-known/acme-challenge/... isteği önce Cloudflare'e gelir, Cloudflare de sunucuna iletir. Bu çoğu zaman çalışır. Senin sunucun yerine Cloudflare'deki bir şey cevap verirse bozulur: isteği doğrulamaya sokan bir WAF ya da bot kuralı, "I'm Under Attack" modu, o yolda bir yönlendirme kuralı ya da Worker. O zaman Detail: satırında 403, 503 ya da bir HTML doğrulama sayfası görürsün.

Kalıcı iki çözüm:

• DNS-01'e geç. certbot-dns-cloudflare eklentisi TXT kaydını Cloudflare API'si üzerinden, "Zone:DNS:Edit" yetkili bir token'la oluşturur. Doğrulama artık port 80'e de proxy'ye de dokunmaz; joker (wildcard) sertifika da alabilirsin.
• Cloudflare ile sunucu arasında Cloudflare Origin CA sertifikası kullan, SSL/TLS modunu Full (strict) yap, herkese açık sertifikayı Cloudflare'e bırak. Cloudflare'in Origin CA belgeleri, Cloudflare'i duraklatırsan ya da proxy'yi kapatırsan ziyaretçilerin güvenilmeyen sertifika hatası göreceğini söylüyor; bunu sadece site proxy arkasında kalacaksa yap.

Sadece bugünü kurtarman gerekiyorsa güvenlik kuralını doğrulama yolu için durdurmak ya da kaydı geçici olarak DNS only yapmak bir yenilemeyi geçirir. Sonra yukarıdaki iki çözümden birine geç.

Webroot yolu yanlış

Type: unauthorized, Detail: ... Invalid response from http://ornek.com/.well-known/acme-challenge/...: 404 ve --webroot-path hakkında bir ipucu.

Certbot doğrulama dosyasını sertifika ilk alındığında kaydedilen klasöre yazar; sen de o arada siteyi taşımışsındır (yeni tema klasörü, Docker volume, html/ yerine public/). /etc/letsencrypt/renewal/ornek.com.conf dosyasında webroot_path satırına bak. Certbot kılavuzu güvenli değiştirme yolunu gösteriyor: önce yeni yolla dry run, sonra kalıcı yap.

sudo certbot renew --cert-name ornek.com --webroot-path /var/www/ornek/public --dry-run
sudo certbot renew --cert-name ornek.com --webroot-path /var/www/ornek/public --force-renewal

Certbot 2.3.0 ve sonrasında certbot reconfigure --cert-name ornek.com aynı işi daha temiz yapar. Yenileme dosyasını elle düzenleme; certbot belgeleri de bunu önermiyor.

Standalone eklentisi kullanılmış ama port 80'i nginx tutuyor

Could not bind TCP port 80 because it is already in use by another process. Sertifika ilk alındığında web sunucusu çalışmıyordu ve --standalone kullanıldı. Ya sertifikayı nginx ya da webroot eklentisine geçir, ya da certbot kılavuzundaki gibi /etc/letsencrypt/renewal-hooks/pre/ ve /post/ klasörlerine web sunucusunu durdurup başlatan hook dosyaları koy.

İstek limitine takıldın

too many certificates ya da too many failed authorizations. Let's Encrypt istek limitleri: aynı ad kümesi için 7 günde en fazla 5 sertifika ("Up to 5 certificates can be issued per exact same set of identifiers every 7 days") ve bir hesap için ad başına saatte en fazla 5 başarısız doğrulama ("Up to 5 authorization failures per identifier can be incurred by one account every hour"). Takılınan genelde ikincisi: port 80 hâlâ kapalıyken certbot --force-renewal'ı tekrar tekrar çalıştırmak. Geçene kadar --dry-run (staging) ile dene, sonra tek bir gerçek çalıştırma yap.

Web sunucusu yeniden yüklenmemiş

Yenileme kaydı başarılı diyor, certbot certificates yeni tarihi gösteriyor, tarayıcılar hâlâ eskisini görüyor. nginx ve Apache eklentileri yeniden yüklemeyi kendisi yapar; webroot ve standalone yapmaz. Sadece başarılı bir yenilemeden sonra çalışan bir deploy hook ekle:

sudo sh -c 'printf "#!/bin/sh\nsystemctl reload nginx\n" > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh'
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Sertifikayı okuyan başka her şey için de aynısı: posta sunucusu, dosyaları bağlanmış bir Docker konteyneri, kendi kopyasını tutan bir panel.

Sonra gerçek yenilemeyi yap

Dry run "Congratulations, all simulated renewals succeeded" dediğinde:

sudo certbot renew
sudo systemctl reload nginx

renew sadece zamanı gelen sertifikaları yeniler. Süresi dolmuş bir sertifikanın zamanı gelmiştir, bu yeter; --force-renewal gerekmez. En baştaki openssl s_client komutunu tekrar çalıştır, yeni notAfter tarihine ve iki ada (ornek.com ve www.ornek.com) bak.

cPanel AutoSSL ve Plesk (paylaşımlı hosting)

Paylaşımlı hostingde certbot'u sen çalıştırmazsın; yenilemeyi panel yapar. Başarısız olma sebepleri de aynı: alan adı sunucuyu göstermiyor ya da önündeki bir şey doğrulamaya cevap veriyor.

cPanel. Security » SSL/TLS Status sayfasını aç (Türkçe arayüzde Güvenlik bölümünde; cPanel belgeleri). "Has AutoSSL Problems" filtresini seç; cPanel'in kendi örneği "a domain that does not resolve to an IPv4 address on the internet", yani internette bir IPv4 adresine çözülmeyen alan adı. Sık sebepler: başka yeri gösteren bir www ya da mail kaydı, DNS'i proxy'si açık Cloudflare'de olan alan adı, ya da artık kullanmadığın bir ek alan adı. Çoğu hosting, sebep düzeldikten sonra bu sayfada Run AutoSSL düğmesi de gösterir. Düğme yoksa AutoSSL'i hosting kendi takviminde çalıştırıyordur; alan adını ve görünen hatayı yazıp destek talebi aç.

Plesk. Websites & Domains (Web Siteleri ve Alan Adları) > alan adın > SSL/TLS Certificates yolunu izle. Plesk'in SSL It! eklentisi, Plesk belgelerine göre Let's Encrypt ve DigiCert'in ücretsiz sertifikalarını bitişten 30 gün önce otomatik yeniliyor. Keep websites secured seçeneği, süresi dolmuş ücretli bir sertifikayı da ücretsiz biriyle değiştiriyor. Yenileme başarısız olursa hata aynı sayfada görünür; sebep yine çoğu zaman başka yeri gösteren DNS.

Süresi dolmuş sertifika AdSense'e ya da Google'a zarar verir mi?

Ziyaretçi açısından site fiilen kapalı: tarayıcı tam sayfa uyarı gösterir, çoğu kişi geri döner. AdSense'te Google'ın reklam göstermeye hazır olmayan site listesinde şu soru var: "Siteniz tanınmış bir sertifika yetkilisinden (kendinden imzalı sertifika değil) alınmış geçerli bir SSL Sertifikasına sahip mi ve HTTP'yi HTTPS'ye yönlendiriyor mu?" (Siteniz reklam göstermeye hazır olmadığında). İnceleme sırasında süresi dolmuş bir sertifika site kapalı veya kullanılamıyor reddiyle sonuçlanabilir. HTTPS'e yeni geçtiysen ve bazı görseller ya da betikler hâlâ http:// ile yükleniyorsa o ayrı bir sorun: HTTPS sonrası karışık içerik.

Süresi dolmadan haberin olsun

Yenileme otomatik ama hataları sessiz; 64 ve sonra 45 günlük sertifikalarla "yenileme başarısız" ile "site engellendi" arasındaki süre de kısalıyor. Ücretsiz SSL sertifika kontrolü şu an sunulan sertifikayı, kapsadığı adları ve kalan günü gösterir; site izleme bunu senin yerine takip eder, bitişe 14 ve 7 gün kala, sertifika geçersiz olursa da hemen e-posta atar.

Sık sorulan sorular

SSL sertifikamın ne zaman biteceğini nasıl görürüm?

sudo certbot certificates certbot'un diskte tuttuğunu gösterir. echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null | openssl x509 -noout -enddate sunucunun gerçekte sunduğunu gösterir. Ziyaretçinin gördüğü ikincisi.

Canlı sunucuda certbot renew --dry-run çalıştırmak güvenli mi?

Evet. Test sunucusunu kullanır, sertifika kaydetmez. Certbot belgeleri, yapılandırma dosyalarını geçici olarak değiştirip geri almak için web sunucusunu yeniden yükleyebileceğini belirtiyor; normal bir kurulumda zararsız.

--force-renewal kullanmalı mıyım?

Sadece sertifikayla ilgili bir şeyi değiştirdiğinde (yeni yol, yeni anahtar türü) ve certbot belgeleri bunu söylediğinde. Süresi dolmuş ya da dolmak üzere olan bir sertifikayı düz certbot renew zaten yeniler; tekrar tekrar zorlamak istek limitlerine takılır.

Certbot "not yet due for renewal" diyor. Daha erken yenilemesini nasıl sağlarım?

Gerek yok. Sunulan sertifika eski, certbot'unki yeniyse web sunucusunu yeniden yükle. Gerçekten şimdi yenisi lazımsa (mesela yeni bir ad ekledin) bir kez certbot certonly ya da --force-renewal kullan.

Hosting SSL otomatik yenileniyor diyor ama yine de süresi doldu. Ne oldu?

Panel denedi ve başarısız oldu; neredeyse her zaman yenileme anında alan adı (ya da www) başka bir yeri, sıklıkla Cloudflare proxy'sini gösterdiği için. DNS'i düzelt, sonra hostingden AutoSSL'i çalıştırmasını ya da panelden yeniden sertifika almasını iste.