Cron Job ile SSL Sertifikası Otomatik Yenileme

Let's Encrypt SSL/TLS sertifikaları, modern web sitelerinin güvenliğini sağlayan ve HTTPS şifrelemesini ücretsiz olarak sunan en yaygın endüstri standardıdır. Bu rehberde ele alınan classic profilli sertifikaların geçerlilik süresi 90 gündür; diğer profillerde süre farklı olabilir. Sertifika süresi dolduğu anda web tarayıcıları kullanıcıların karşısına güvensiz bağlantı uyarısı çıkarır, ziyaretçilerin siteye erişimi aksayabilir. Bu riskin önüne geçmek için sertifikaların süresi dolmadan önce arka planda sessizce ve düzenli bir şekilde yenilenmesi gerekir.

Sertifika yenileme otomasyonunda Electronic Frontier Foundation (EFF) tarafından geliştirilen Certbot yazılımı standart istemcidir. Certbot, ACME (Automated Certificate Management Environment) protokolü aracılığıyla alan adı sahipliğini teyit eder, yeni anahtar çiftlerini üretir ve web sunucusu yapılandırmasına işler. Ancak bu sürecin aksamadan çalışması için doğru bir Linux cron job zamanlaması yapılması, web sunucusunu yeniden yükleme kancalarının doğru ayarlanması ve yetki sınırlarının kusursuz biçimde tanımlanması gerekir.

Bu rehberde; Let's Encrypt 90 günlük yaşam döngüsünü, systemd timer ile crontab arasındaki çalışma farklarını, adım adım crontab üzerinden Certbot yapılandırmasını, Nginx ve Apache servislerinin kesintisiz biçimde yeni sertifikayı yüklemesini ve karşılaşılan yaygın doğrulama hatalarının kesin çözümlerini ele alıyoruz.

Let's Encrypt ve Otomatik SSL Yenileme Mantığı (90 Günlük Döngü)

Let's Encrypt sertifikalarının 90 gün gibi görece kısa bir süreyle sınırlandırılmasının iki temel nedeni vardır: Olası anahtar sızıntılarının veya güvenlik açıklarının etki süresini minimumda tutmak ve web yöneticilerini sertifika yönetimini mutlaka otomatikleştirmeye zorlamaktır. Elle yapılan 1 yıllık sertifika yenileme süreçleri unutulmaya mahkumdur; ancak otomatik çalışan zamanlanmış görevler sistemin sürekli güncel kalmasını sağlar.

Certbot 4.0.0 ve sonrasında, kalan geçerlilik süresi sertifika ömrünün üçte birinden azsa yenileme başlar; ömrü en fazla 10 gün olan sertifikalarda eşik yarı süredir. Eski sürümlerde sabit 30 günlük eşik kullanılır. Eğer sertifikanın bitimine 45 gün varsa, terminalden veya cron üzerinden certbot renew çalıştırsanız bile Certbot bu sertifikayı atlar ve işlem yapmaz. Bu akıllı eşik mekanizması, sunucunuzun her gün Let's Encrypt sunucularını lüzumsuz yere meşgul etmesini ve oran sınırlarına (rate limits) takılmasını önler.

Yenileme sırasında Certbot genellikle HTTP-01 challenge yöntemini uygular. Bu yöntemde Let's Encrypt sunucusu, sitenizin /.well-known/acme-challenge/ dizini altında geçici bir doğrulama dosyasının varlığını 80 portu üzerinden HTTP ile denetler. Dosya içeriği doğruysa yeni sertifika dosyaları /etc/letsencrypt/live/alanadiniz/ dizinine yazılır ve eski sembolik bağlar güncellenir.

Systemd Timer vs Crontab: Hangisi Kullanılmalı?

Modern Linux işletim sistemlerinde, özellikle Ubuntu cron job altyapılarında (Ubuntu 20.04, 22.04, 24.04) ve Debian sistemlerde Certbot paket yöneticisi (apt veya snap) ile kurulduğunda arka planda otomatik olarak bir systemd timer oluşturur. Bu timer genellikle günde iki kez rastgele zamanlarda çalışarak sertifikaların süresini yoklar.

Mevcut certbot.timer Durum Kontrolü

Sunucunuza yeni bir crontab kuralı eklemeden önce sisteminizde halihazırda çalışan bir timer olup olmadığını kontrol etmeniz gerekir. Aşağıdaki komutla servis durumunu sorgulayabilirsiniz:

systemctl list-timers --all | grep -i certbot

Eğer çıktıda etkin bir Certbot zamanlayıcısı ve sonraki çalışma zamanı görünüyorsa, sisteminizde zaten otomatik bir yenileme mekanizması devrededir. Bu durumda crontab içine ikinci bir görev eklemek iki farklı servisin aynı anda /etc/letsencrypt dizini üzerinde kilit (lock) oluşturmaya çalışmasına yol açabilir. Zamanlayıcı mimarilerinin detaylı karşılaştırması için cron vs systemd timer incelememizi okuyabilirsiniz. Eğer crontab üzerinden tam denetime sahip olmak istiyorsanız, kurulumunuza ait zamanlayıcıyı devre dışı bırakabilirsiniz (aşağıdaki ad apt kurulumu içindir; snap kurulumunda birim adı farklıdır):

sudo systemctl stop certbot.timer
sudo systemctl disable certbot.timer

Adım Adım Crontab ile Certbot Yapılandırması

Crontab üzerinden Certbot ile güvenli bir otomatik yenileme mekanizması kurmak için aşağıdaki sıralı adımları izleyin:

1. Certbot Çalıştırılabilir Dosyasının Yolunu Belirleyin: Cron ortamları dar bir $PATH değişkenine sahip olduğundan ikili dosyanın tam yolu verilmelidir. Terminalde which certbot komutunu çalıştırarak yolu (genellikle /usr/bin/certbot veya /snap/bin/certbot) öğrenin.
2. Root Crontab Tablosunu Açın: Sertifika dosyaları ve /etc/letsencrypt dizini yalnızca kök kullanıcı (root) erişimine açıktır. Standart kullanıcı hesabı sertifikaları yenileyemez. Bu yüzden sudo crontab -e komutunu kullanın. Yetki sınırları hakkında bilgi almak için cron permission denied rehberimize göz atabilirsiniz.
3. Yenileme Komutunu ve Zamanlamasını Ekleyin: Certbot'un her gün veya haftada iki kez sabaha karşı çalışması önerilir. Bu saatlerde sunucu trafiği genellikle en düşük seviyededir.
4. Web Sunucusunu Yeniden Yükleme Kancasını (Hook) Tanımlayın: Sertifika yenilendiğinde Nginx veya Apache servislerinin bellekteki eski sertifikayı bırakıp yeni dosyaları okuması için reload sinyali alması zorunludur.

certbot renew Komutu ve Güvenli Çalıştırma Bayrakları

Crontab içinde Certbot çalıştırılırken iki temel parametreye mutlaka yer verilmelidir:

• --quiet: Bu bayrak, Certbot'un yalnızca bir hata oluştuğunda çıktı üretmesini sağlar. Başarılı yenilemelerde veya kontrol atlamalarında terminale hiçbir şey yazdırmayarak cron servisinin gereksiz e-posta bildirimleri oluşturmasını engeller.
• --random-sleep-on-renew: İsteklerin aynı anda yığılmasını azaltmak için yenileme öncesine rastgele bekleme ekler; bekleme aralığı Certbot sürümüne bağlıdır.

Yenileme Sonrası Web Sunucusunu Tetikleme (--deploy-hook)

Çoğu web yöneticisinin yaptığı en büyük hata --post-hook ile --deploy-hook arasındaki farkı bilmemektir. --post-hook komutu, yalnızca yenileme zamanı gelen bir sertifika için girişim yapıldığında, girişim başarılı olsun ya da olmasın çalışır. Oysa --deploy-hook parametresi yalnızca en az bir sertifika başarıyla yenilendiğinde devreye girer:

--deploy-hook "systemctl reload nginx"

Bu sayede Nginx yalnızca diske gerçekten yeni bir SSL sertifikası indiğinde konfigürasyonunu yeniler ve aktif bağlantılar kesintiye uğramaz.

Gerçek Kod Örnekleri

Farklı sunucu senaryolarına uygun çalışan ve test edilmiş crontab yapılandırmaları aşağıdadır.

Senaryo 1: Nginx İçin Haftada İki Kez Çalışan Güvenli Crontab Satırı

Pazartesi ve Perşembe günleri sabaha karşı saat 03:30'da çalışır, rastgele bekleme süresi uygular ve yalnızca yenileme başarılı olursa Nginx servisini yeniden yükler:

# Root crontab (sudo crontab -e)
30 3 * * 1,4 /usr/bin/certbot renew --quiet --random-sleep-on-renew --deploy-hook "systemctl reload nginx"

Senaryo 2: Apache Sunucusu İçin Günlük Kontrol ve Detaylı Loglama

Her gece saat 02:15'te çalışır, standart hataları ve yenileme kayıtlarını özel bir günlük dosyasına ekler:

# Apache web sunucusu için günlük SSL yenileme
15 2 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload apache2" >> /var/log/certbot-cron.log 2>&1

Senaryo 3: Yenileme ve Kanca Mekanizmasını Simüle Eden Test Komutu

Gerçek bir yenileme yapmadan ve Let's Encrypt kotanızı harcamadan tüm kancaların ve izinlerin düzgün çalıştığını doğrulamak için --dry-run ile birlikte --run-deploy-hooks parametresini kullanabilirsiniz:

sudo certbot renew --dry-run --run-deploy-hooks

Bu komut başarılı şekilde tamamlanırsa ve ekranda Simulating renewal of an existing certificate ile birlikte Nginx'in yeniden yüklendiği bildirilirse doğrulama ve kanca mekanizması test ortamında çalışmış demektir; cron ortamını ayrıca kontrol etmelisiniz.

Sık Karşılaşılan Hatalar ve Çözümleri

SSL otomatik yenileme süreçlerinde karşılaşılan yaygın problemler, kök nedenleri ve çözüm yöntemleri aşağıda listelenmiştir:

location /.well-known/acme-challenge/ {
    root /var/www/html;
    allow all;
}

cronjob.com.tr ile HTTP Tabanlı Alternatif Kurulum (SSL Bağlantı Kontrolü)

Sunucu içi Certbot ve crontab mekanizmaları güçlü olsa da tamamen bağımsız bir güvenlik katmanı değildir. Sunucunun diski dolduğunda, işletim sistemi kilitlendiğinde ya da Nginx hatalı bir güncelleme sonrası başlayamadığında Certbot yenileme yapamaz ve SSL süresi sessizce dolabilir. Dışarıdan bağımsız bir gözlemci olmadan bu çöküşü ancak müşterileriniz siteye giremediğinde fark edersiniz.

cronjob.com.tr platformu, web sitenizi ve SSL sertifikanızı harici bir HTTP katmanından periyodik olarak denetleyen bulut tabanlı bir zamanlama ve izleme servisidir. Platformumuz TLS protokolünü sıkı biçimde doğrular: Yapılan her istekte sunucunuzun sunduğu SSL sertifikasının geçerliliği, alan adı eşleşmesi ve bitiş tarihi kontrol edilir. Eğer sunucunuz süresi dolmuş veya geçersiz bir sertifika sunarsa istek anında bağlantı hatası olarak işaretlenir.

Kullanım için sunucunuzda crontab yapılandırmak zorunda değilsiniz. cronjob.com.tr kontrol panelinden ücretsiz hesap oluşturarak (kredi kartı gerekmez) sitenizin ana sayfasına veya özel bir kontrol uç noktasına (örneğin https://alanadiniz.com/api/health) periyodik istek tanımlayabilirsiniz:

• Zamanlama Seçenekleri: Görevinizi en kısa aralık olan 60 saniyeden (1 dakika) başlatarak çalıştırabilir ya da standart 5 alanlı cron ifadesi (örneğin her gün sabah 0 9 * * *) ile yapılandırabilirsiniz. Saat dilimi iş bazında seçilebilir (varsayılan Europe/Istanbul).
• HTTP Yapılandırması: GET, POST, PUT, PATCH, DELETE, HEAD veya OPTIONS metotlarını seçebilir, yetkilendirme için özel HTTP başlıkları (örneğin X-Monitoring-Key: gizli-token) ekleyebilirsiniz.
• Kesinti Bildirimleri: Ardışık hata sayısı eşiği (varsayılan 3, 1–20 arası ayarlanabilir) aşıldığında cronjob.com.tr sistem yöneticisine "erişim sorunu" e-postası gönderir. SSL sorunu giderildiğinde ise toplam kesinti süresini belirten "düzeldi" bildirimi iletilir. Aynı iş için bildirimler arasında en az 60 dakika bulunur.
• Log İnceleme: Her kontrolün HTTP durum kodu, yanıt süresi ve gövdenin ilk ~64 KB'lık kısmı 7 gün boyunca sistemde saklanır. Böylece Certbot çalışmasa da HTTPS erişim hatalarını seçtiğiniz kontrol aralığı ve bildirim eşiğiyle izleyebilirsiniz.

Sıkça Sorulan Sorular (SSS)

Certbot sertifikayı süresi dolmadan ne zaman yeniler?

Certbot 4.0.0 ve sonrasında kalan ömür üçte birin altına düştüğünde yenileme yapılır; ömrü en fazla 10 gün olan sertifikalarda eşik yarıdır. Önceki sürümlerde eşik sabit 30 gündür. Yenileme zamanı gelmeyen sertifikalar atlanır.

Crontab'a her gün çalıştırma eklersem Let's Encrypt limitlerine takılır mıyım?

Hayır, crontab üzerinden günde bir veya iki kez certbot renew çalıştırmak Let's Encrypt oran sınırlarına (rate limits) takılmaz. Komut yalnızca yenileme eşiğine gelen sertifikalar için ACME sunucularına istek gönderir; günü gelmeyen sertifikalar yerel kontrolde elenir.

--deploy-hook ile --post-hook arasındaki fark nedir?

--deploy-hook parametresi yalnızca en az bir sertifika başarıyla yenilendiğinde çalışır ve web sunucusunu gereksiz yere reload etmekten kaçınır. --post-hook ise yalnızca yenileme zamanı gelen sertifikalar için bir girişim yapıldıktan sonra, girişim başarılı olsun ya da olmasın çalışır.

Web sunucusunu reload etmezsem ne olur?

Yeni sertifika dosyaları diske indirilse bile Nginx veya Apache gibi web sunucuları bellekteki eski sertifikayı kullanmaya devam eder. Bu durum sertifikanın süresi dolduğunda sitenizin tarayıcılarda güvenlik uyarısı vermesine yol açar.

İlgili Rehberler