Let's Encrypt otomatik yenileme cron’u: Net kurulum rehberi

Giriş

Let's Encrypt sertifikaları 90 gün geçerli olduğu için yenileme sürecini otomatik kurmak operasyonel riski doğrudan azaltır. Doğru cron (zamanlayıcı) kurgusu; beklenmeyen süre aşımı, doğrulama hatası (http-01/dns-01), servis çakışması ve sessiz başarısızlıkları engeller. Bu rehberde; cron’un ne zaman çalıştırılacağı, hangi komutların kullanılacağı, logların nasıl okunacağı ve yenilemenin gerçekten gerçekleştiğini nasıl kontrol edeceğin anlatılır. Sonunda elindeki kurulum, “sertifika düştü mü?” sorusuna net bir yanıt verecek seviyeye gelir.

Hangi yenileme yöntemi kullanılmalı? (http-01 vs dns-01)

Let's Encrypt yenileme sırasında sertifikayı doğrulamak için bir challenge (doğrulama) yöntemi kullanır. Cron tarafında doğru kurgu için ilk karar bu olmalıdır.

HTTP-01 (webroot) — en sık kullanılan

Doğrulama, belirli bir URL üzerinden yapılır.
Genelde /.well-known/acme-challenge/ yolu web sunucunun (nginx/apache) servis edebildiği durumda tercih edilir.

Avantaj: Kurulum hızlıdır.

Risk: Yenileme anında web sunucuda yönlendirme, WAF engeli veya path bazlı kısıt varsa doğrulama başarısız olabilir.

DNS-01 — en stabil, CDN/WAF kısıtında daha uyumlu

Doğrulama DNS TXT kaydı üzerinden yapılır.
Wildcard sertifika (ör. *.domain.com) gerekiyorsa tek pratik yoldur.

Avantaj: HTTP trafiği gerektirmez; CDN/WAF etkileri azalır.

Risk: Sağlayıcı API ile DNS TXT kaydı otomasyonu doğru ayarlanmazsa yenileme durur.

Otomatik cron kurgusunda fark

Cron komutu değişmez; değişen şey certbot parametreleri ve doğrulama eklentisi/konfigürasyonudur. Yani cron’un doğru olması, doğrulamanın doğru kurgulanmasına bağlıdır.

Sistem hazırlığı: certbot komutu ve test çalışma mantığı

Cron’u gerçek yenileme işine geçmeden önce “dry run” ile test etmek gerekir. Bu, sunucunda doğrulama akışının bozuk olmadığına dair net kanıt sağlar.

1) certbot sürümü ve mevcut sertifikaların kontrolü

Önce sertbotun düzgün çalıştığını doğrula: - certbot --version - certbot certificates

Bu komutlar; sertifikaların adlarını (domain) ve yenileme durumunu gösterir.

2) Dry run (gerçek değiştirmeden) test

Dry run, Let’s Encrypt limitlerini zorlamadan akışın tamamını test eder. Mantık: - Yapılandırmanın doğru olduğunu doğrula. - Webroot/dns-01 doğrulama zincirinin çalıştığını gör.

Komut örneği (uygun eklenti/parametreleri kendine göre uyarla):

sudo certbot renew --dry-run

Bu test başarılı değilse cron bile olsa yenileme sonunda servis sertifika hatası verebilir. Önce dry-run düzelsin.

3) Yenileme sıklığı kararını netleştir

Let's Encrypt yenileme mantığı, sertifikanın yaklaşık 30 gün içinde dolmasına yaklaşınca yenileme tetikler. Bu yüzden cron’u her gün çalıştırmak teknik olarak yeterlidir. - Yenileme penceresi: 30 gün kala - Cron sıklığı: günde 1

Böylece sertifika düşmeden önce günler “tampon” olur.

Cron kurulumu: en güvenli zamanlama ve komut

Cron kurulumu, iki şeye odaklanmalıdır: 1) Cron çalıştığında doğru komutun çalışması 2) Hataların loglara düşmesi (sessiz başarısızlık olmaması)

Önerilen cron satırı (günde 1)

Genelde en pratik yaklaşım; her gün belirli bir saatte renew komutunu çalıştırmaktır. Önerilen kurgu: - Gündüz trafiği düşük saat - Çıktıyı log dosyasına yaz

Örnek cron:

0 03 * * * /usr/bin/certbot renew --quiet --no-self-upgrade --post-hook "systemctl reload nginx" >> /var/log/letsencrypt-renew.log 2>&1

Bu satırdaki kritik noktalar: - 0 03 * * *: Her gün 03:00 - --quiet: Gereksiz stdout’u azaltır - --no-self-upgrade: certbot’un kendini otomatik güncellemesini kapatır (kontrollü güncelleme daha öngörülebilir) - --post-hook: Yenileme gerçekleştiğinde web sunucuyu yeniden yükler - >> ... 2>&1: Hem standart çıktı hem hata loglanır

Nginx kullanmıyorsan systemctl reload nginx yerine kullandığın servisi koy (ör. apache2).

web sunucusu yoksa post-hook şart değil

Sertifika doğrulaması webroot/dns-01 üzerinden yapılıp sertifika dosyaları otomatik güncelleniyorsa, servis yeniden yüklenmeden bazı senaryolarda yeni sertifika dosyası etkin olmayabilir. En sağlam yöntem post-hook ile servisi reload etmektir.

systemd timer alternatifi (cron kadar net)

Bazı dağıtımlarda certbot zaten systemd timer ile çalışabilir. Eğer systemctl list-timers | grep certbot ile timer görüyorsan, ayrıca cron kurmak yerine mevcut mekanizmayı kullanmak daha az karmaşa yaratır.

Doğrulama doğruluğu: webroot ve servis path kontrolü

HTTP-01 (webroot) kullanıyorsan yenileme başarısızlıklarının önemli kısmı “doğrulama yolu” probleminden çıkar.

Kontrol listesi

Aşağıdaki kontroller net kanıt verir: - /.well-known/acme-challenge/ yolu web sunucuda erişilebilir mi? - location / altında engelleyici kural var mı? - CDN/WAF, challenge path’lerini yanlış yönlendiriyor mu? - HTTP -> HTTPS redirect kuralında challenge yoluna istisna var mı?

Pratik test

Dry run’dan sonra ayrıca şu mantıkla yaklaş: - Challenge URL’siyle beklenen içerik görüyor musun? - Reload sırasında web sunucunun düzgün çalıştığını doğrula.

Bu adım, cron’un sorunsuz görünse bile “renew aslında doğrulama alamıyor” senaryosunu bitirir.

DNS-01 kullanıyorsan: TXT kaydı otomasyonu ve zamanlama

DNS-01 en stabil seçeneklerden biridir ama otomasyonu bozuksa cron boşa çalışır.

Yapman gereken net şeyler

DNS sağlayıcı eklentisi (örn. Cloudflare vb.) doğru kimlik bilgileriyle konfigüre mi?
TXT kaydı oluşturma/okuma yetkisi var mı?
DNS TTL ayarı çok yüksek değil mi? (Öneri: ilk denemelerde daha düşük TTL)

Dry run nasıl yorumlanır?

DNS-01 dry run başarısızsa, cron’dan önce şu iki şeyi düzelt: - TXT kaydının oluştuğu yer/alan - ACME doğrulamasının TXT’yi okuyup okumadığı

Loglar ve hata ayıklama: “renew çalıştı mı?” sorusu

Cron sistemlerinde en yaygın problem, “komut çalıştı ama yenilemedi” ya da “çalıştı ama hata oluştu, fark edilmedi” durumudur. Log bunu çözer.

Önerilen log yaklaşımı

Yukarıdaki cron satırında log dosyasına yönlendirme yaptın. Ek olarak sistem loglarını da kontrol edebilirsin: - /var/log/letsencrypt-renew.log - (dağıtıma göre) journalctl -u ...

Ne zaman sorun var kabul edilir?

certbot renew loglarında hata satırları görüyorsan
Dry run başarısızsa
Cron loglarında son çalıştırma tarihinin olmadığını görüyorsan

Yenileme oldu mu kontrolü

Renew komutu yenileme yapmadığında bile “başarılı” görünebilir; çünkü sertifika yenilenmeye henüz girmemiştir. Bu yüzden şu net kontrol önemlidir: - Yenileme sonrası “hangi sertifika güncellendi” bilgisi loglarda görünür. - Sertifikanın notAfter (bitiş) tarihi uzuyor mu?

Net kontrol için: - certbot certificates çıktısındaki bitiş tarihlerini karşılaştır

Güvenlik ve operasyonel dayanıklılık

Cron kurgusu sadece teknik komut değil, güvenliğe de dayanmalıdır.

Yetki (permission)

cron komutu sudo ile çalıştırılmalı ya da root kullanıcısı altında planlanmalıdır.
sertifika dizinlerine erişim hatası olmamalı.

Gizli dosyalar

DNS-01 için kullanılan API anahtarları credentials dosyalarında tutuluyorsa dosya izinlerini sıkı yap:
sahip: root
sadece yetkili kullanıcı okuyabilir

Çakışma (conflict) önleme

Cron her gün çalışırken paralel iki renewal oluşmamalı. Çakışma riskini azaltmak için: - cron dakikayı sabitle - --quiet ve loglama ile tekrarlı hatayı hızlı yakala

Bazı kurulumlarda certbot kendini zaten seri çalıştırır; yine de en net yaklaşım logları izlemek ve cron zamanını sabit tutmaktır.

Uygulama senaryoları: nginx, apache ve reverse proxy

Birden fazla bileşen kullandığında sertifikanın nereye yüklendiği ve reload’un doğru servise uygulanması gerekir.

Nginx doğrudan terminasyon

post-hook nginx reload olmalı
Nginx config içinde ilgili server bloğu sertifikaları kullanmalı

Apache doğrudan terminasyon

post-hook systemctl reload apache2
Modüller doğru yüklü olmalı

Reverse proxy (ör. edge proxy + iç uygulama)

Sertifika genelde edge proxy’de tutulur. O durumda reload’u edge proxy servisine uygula; uygulama sunucusuna değil.

Net kontrol listesi (yayına almadan önce)

Aşağıdaki maddeler “tamamlandı” olmadan cron’u tek başına başarı sayma.

[ ] certbot --version çalışıyor
[ ] certbot certificates sertifikaları listeliyor
[ ] certbot renew --dry-run başarıyla tamamlanıyor
[ ] Cron günde 1 kez çalışıyor (saat sabit)
[ ] Cron çıktısı log dosyasına yazılıyor
[ ] post-hook yenilenen sertifika için doğru servisi reload ediyor
[ ] HTTP-01 kullanıyorsan challenge path erişilebilir
[ ] DNS-01 kullanıyorsan TXT kayıt otomasyonu doğrulanmış
[ ] Yenileme sonrası certbot certificates bitiş tarihi uzuyor

Sonuç

Let's Encrypt otomatik yenileme cron’u; doğru zamanlama, doğru doğrulama yöntemi ve loglanmış hata ayıklama ile “sertifika düştü” sürprizlerini ortadan kaldırır. En net aksiyon planı şudur: önce certbot renew --dry-run ile doğrulamayı kanıtla, ardından cron’u günde 1 kez çalıştır ve post-hook ile doğru web sunucuyu reload ettir. Son olarak /var/log/letsencrypt-renew.log üzerinden ilk birkaç çalıştırmayı izleyerek sistemin sessizce başarısız olmadığını garanti altına al.