Let's Encrypt Cron Yenileme: Sessiz Başarısızlıkları Önleme

Let's Encrypt sertifikaları 90 günlük ömrüyle, standart ücretli sertifikalara kıyasla çok daha sık yenilenmek zorunda. Bu, otomasyonu zorunlu kılar — kimse her üç ayda bir manuel yenileme yapmak istemez. Asıl tehlike şu: cron job'u bir kez kurup unutmak, sertifikanın sorunsuz yenilendiğini sanmak. Oysa pek çok senaryoda yenileme sessizce başarısız olur ve 90. günde siteniz ziyaretçilere "Bağlantınız güvenli değil" uyarısı gösterir. Bu rehberde yenileme cron'unun neden başarısız olduğunu, bunu nasıl önceden tespit edeceğinizi ve basit bir izleme altyapısını nasıl kuracağınızı somut komutlarla ele alacağız.

Certbot Yenileme Mekanizması Nasıl Çalışır?

Certbot, certbot renew komutu her çalıştığında sistemdeki tüm sertifikaları tarar. Geçerlilik süresi 30 günden az kaldıysa yenileme girişiminde bulunur; aksi hâlde hiçbir şey yapmaz. Bu davranış kasıtlıdır — günlük cron çalışsa bile her gün yenileme olmaz.

Yenileme girişimi üç farklı HTTP-01 doğrulama yöntemiyle gerçekleşebilir:

• standalone: Certbot kendi geçici HTTP sunucusunu açar, 80 numaralı porta ihtiyaç duyar
• webroot: Sitenizin kök dizinine (document root) özel bir dosya yazar, mevcut web sunucusu üzerinden doğrulama yapar
• nginx / apache plugin: Web sunucusu yapılandırmasını otomatik düzenler ve yenileme sonrası yeniden yükler

Her yöntemin farklı başarısızlık noktaları vardır. Hangi yöntemi kullandığınızı bilmeden sorunu teşhis etmek güçleşir. Kurulum sırasında kullanılan yöntem /etc/letsencrypt/renewal/<domain>.conf dosyasındaki authenticator satırında yazar.

Yenileme geçmişini incelemek için:

cat /var/log/letsencrypt/letsencrypt.log | grep -E "renew|error|fail"

Cron'un Sessizce Başarısız Olduğu 5 Senaryo

1. Port 80 Meşgul (Standalone Plugin)

Standalone plugin, doğrulama sırasında 80 numaralı portu kendisi tutmak zorundadır. Nginx veya Apache zaten o portta çalışıyorsa certbot Address already in use hatası üretir. Bu hata yalnızca log dosyasına yazılır; terminalde kimse görmez, e-posta gönderilmez.

Çözüm: Nginx veya Apache kullananlar için standalone yerine webroot ya da nginx/apache plugin tercih edin. Standalone kullanmak zorundaysanız --pre-hook ve --post-hook ile web sunucusunu geçici olarak durdurun:

certbot renew \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

2. DNS Kaydı Artık Sunucuyu Göstermiyor

CDN geçişi, IP değişikliği veya yanlış DNS güncellemesi sonucunda alan adı farklı bir sunucuya işaret edebilir. Let's Encrypt HTTP-01 doğrulamasında /.well-known/acme-challenge/ dizinine dışarıdan erişmeye çalışır — DNS yanlışsa bu istek başka bir makineye gider ve doğrulama başarısız olur.

Hızlı kontrol:

dig +short A example.com
curl -I http://example.com/.well-known/acme-challenge/test

3. Rate Limit Aşımı

Let's Encrypt, aynı alan adı için haftada en fazla 5 yeni sertifika (duplicate certificate) izni tanır. Test ortamında veya hatalı yapılandırılmış cron'lar bu limiti hızla tüketebilir. Hata kodu log dosyasına yazılır ama kimseye bildirim gitmez.

grep -i "rate limit" /var/log/letsencrypt/letsencrypt.log

Rate limit aşıldıysa haftalık sıfırlanmasını beklemek zorundasınız. Test yaparken her zaman --dry-run kullanın — bu, staging ortamını hedefler ve limiti tüketmez.

4. Yetersiz İzin (Permission Denied)

Certbot sertifikaları /etc/letsencrypt/ altında saklar; bu dizine yazmak için root yetkisi gerekir. Cron job'u yanlış kullanıcı (örneğin www-data) altında çalışıyorsa yenileme sessizce başarısız olur.

Crontab satırı her zaman root kullanıcısı bağlamında olmalıdır. sudo crontab -e ile root crontab'ına eklendiğini teyit edin:

sudo crontab -l | grep certbot

5. Systemd Timer ile Crontab Çakışması

Certbot'u snap ile kurduysanız systemd timer otomatik gelir ve sertifika yenilemeyi üstlenir. Ek olarak /etc/cron.d/certbot dosyası da aktifse iki kaynak aynı anda yenileme girişiminde bulunabilir. Bu çakışma doğrudan hata üretmese de log karmaşasına ve ilerleyen dönemde beklenmedik davranışlara yol açar.

Aktif mekanizmaları kontrol edin:

systemctl list-timers | grep certbot
cat /etc/cron.d/certbot 2>/dev/null

İkisi de aktifse snap kurulumunda systemd timer'ı tutun, /etc/cron.d/certbot satırını yorum satırına (#) alın.

Doğru Cron Yapılandırması

Certbot'u apt ile kurduysanız ve systemd timer yoksa /etc/cron.d/certbot dosyası şu biçimde olmalıdır:

0 3 * * * root certbot renew --quiet 2>&1 | logger -t certbot

--quiet yalnızca başarılı çıktıyı bastırır; hata mesajları yine de üretilir. logger ile çıktıyı sistem günlüğüne (syslog) yönlendirirseniz journalctl -t certbot komutuyla istediğiniz zaman inceleyebilirsiniz.

Systemd timer kullananlar için en sağlıklı kontrol yöntemi:

Yenileme Sonuçlarını E-posta ile İzleme

MAILTO ile Cron Çıktısı

Crontab satırının üstüne MAILTO değişkeni ekleyerek her çalışma sonucunu e-posta ile alabilirsiniz (sunucuda sendmail veya postfix kurulu olmalıdır):

MAILTO="[email protected]"
0 3 * * * root certbot renew --quiet

Hata çıktısı varsa --quiet bunu bastırmaz; e-posta yalnızca bir şeyler ters gittiğinde gelir.

--deploy-hook ile Başarılı Yenileme Bildirimi

Yenileme başarılı olduğunda tetiklenen bir bildirim için:

certbot renew --deploy-hook "/usr/local/bin/notify-renewal.sh"

/usr/local/bin/notify-renewal.sh içeriği:

#!/bin/bash
echo "Yenilenen alan adı: $RENEWED_DOMAINS" \
  | mail -s "SSL Yenileme Basarili" [email protected]

Bu hook yalnızca gerçek yenileme gerçekleştiğinde çalışır; sertifika hâlâ geçerliyse ve bu çalışmada yenileme atlandıysa tetiklenmez. Bunun farkında olun: uzun süre bildirim gelmemesi her zaman iyi haber değildir, sertifika yenilenmeye gerek kalmadan sona da eriyor olabilir (yenileme girişimi kendisi başarısız olmuş olabilir).

Sertifika Son Kullanma Tarihini Proaktif Kontrol Etme

Cron'un çalışıp çalışmadığını doğrulamak yerine, sertifikanın son kullanma tarihini doğrudan sorgulayabilirsiniz.

Dışarıdan TLS bağlantısıyla kontrol:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

Sunucu içinden tüm sertifikaları listelemek için:

certbot certificates

Çıktıda kalan gün sayısı doğrudan görünür:

Expiry Date: 2026-05-30 (VALID: 13 days)

Bu değeri aylık cron ile izleyip eşiğin altına düştüğünde uyarı gönderebilirsiniz:

#!/bin/bash
DAYS=$(certbot certificates 2>/dev/null | grep -oP "VALID: \K\d+")
if [ -n "$DAYS" ] && [ "$DAYS" -lt 20 ]; then
  echo "UYARI: SSL sertifikasi $DAYS gun icinde sona eriyor!" \
    | mail -s "SSL Kritik Uyari" [email protected]
fi

Bu betik /etc/cron.d/ altına eklendiğinde, otomatik yenileme bir şekilde başarısız olsa bile 20 gün öncesinden haberdar olursunuz — sertifika sona ermeden önce müdahale için yeterli süre.

Dry-Run ile Periyodik Test

Sertifika gerçekten yenilenmeden önce tüm akışın çalışıp çalışmadığını test etmek için --dry-run kullanın:

certbot renew --dry-run

Bu komut Let's Encrypt'in staging (test) sunucusunu hedefler; gerçek sertifika üretmez, rate limit tüketmez. Başarılı çıktı şöyle görünür:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Dry-run'ı ayda bir çalıştırıp sonucu e-posta ile alın:

0 4 1 * * root certbot renew --dry-run 2>&1 | mail -s "Certbot Dry-Run Raporu" admin@example.com

Bu satır her ayın ilk günü saat 04:00'te çalışır. Başarılı olsa da başarısız olsa da rapor gelir; böylece "çalışıyor mu?" sorusuna her ay yazılı cevabınız olur.

Sonuç

Let's Encrypt cron kurulumu beş dakika sürer; asıl iş izleme altyapısını doğru kurmaktır. Yapmanız gereken minimum üç adım var: yenileme hatalarını e-posta ile almak, sertifika son kullanma tarihini proaktif izlemek ve ayda bir dry-run raporu göndermek. Bu üç adım uygulandığında 90. günde "Güvenli Değil" sayfasıyla karşılaşma ihtimali pratikte sıfıra iner. Şu an için hızlı teyit: certbot certificates çıktısında kalan gün sayısı 30'un üzerindeyse ve --dry-run başarılı geçiyorsa sisteminiz sağlıklıdır.