Let’s Encrypt Sertifika Yenileme Süreçlerinde Sık Yapılan Hatalar ve Kesintisiz Otomasyon Mimarisi

Web sunucusu yönetirken karşılaşılan en talihsiz durumlardan biri, unutulan bir SSL/TLS sertifikası yüzünden kullanıcıların tarayıcılarında “Güvenli Değil” uyarısı alması veya doğrudan sertifika süresi doldu (ERR_CERT_DATE_INVALID) hatasıyla karşılaşmasıdır. Let’s Encrypt gibi ücretsiz ve otomasyona son derece uygun bir CA (Certificate Authority) yapısı hayatımıza girdiğinden beri bu tür kesintiler tamamen önlenebilir hale geldi. Ancak pratikte, temel kurulum yapılıp bırakılan sistemlerin bir süre sonra otomatik yenileme döngüsünde tıkanabildiğini sıkça görüyoruz.

Bu rehberde, Let’s Encrypt sertifikalarının yenilenme mekanizmalarını derinlemesine inceleyecek, sık yapılan hataları ele alacak ve üretim ortamlarında (production) sıfır kesinti sağlayacak sağlam bir otomasyon mimarisini adım adım kuracağız.

Let’s Encrypt Yenileme Mantığı Nasıl Çalışır?

Let’s Encrypt sertifikaları 90 günlük geçerlilik süresine sahiptir. Bu kısa süre, güvenlik açıklarını en aza indirmek ve otomasyonu zorunlu kılmak için kasıtlı olarak seçilmiştir. Certbot veya alternatif ACME (Automated Certificate Management Environment) istemcileri, genellikle sertifikanın süresinin dolmasına 30 gün kala yenileme işlemine izin verir.

Süreç temel olarak iki adımdan oluşur:

Doğrulama (Validation): ACME sunucusu, alan adının gerçekten sizin kontrolünüzde olduğunu doğrulamak için sunucunuza bir istek gönderir (HTTP-01 veya DNS-01 challenge).
İmzalama (Issuance): Doğrulama başarılı olursa yeni sertifika üretilir ve sunucunuza indirilir.

Sorun genellikle bu adımların manuel olarak ilk kurulumda çalışıp, zaman içinde değişen sunucu kuralları, firewall politikaları veya webroot yolları yüzünden arka planda sessizce başarısız olmasında baş gösterir.

Sık Yapılan Hatalar ve Kök Neden Analizi

1. Webroot Yolunun Değişmesi veya Yanlış Yapılandırılması

Eğer HTTP-01 doğrulama yöntemi kullanıyorsanız, Certbot alan adınıza ait .well-known/acme-challenge/ dizinine belirli bir dosya yazabilmeli ve Let’s Encrypt sunucuları bu dosyaya internet üzerinden erişebilmelidir. Web sitenizin dizin yapısını değiştirdiğinizde veya Nginx/Apache yapılandırmasında root direktifini güncellediğinizde, Certbot’un hedef dizini bulamaması kaçınılmazdır.

2. Web Sunucusunun Yeniden Başlatılmaması (Reload Eksikliği)

Sertifika başarıyla yenilense bile, Nginx veya Apache gibi servisler yeni sertifika dosyalarını belleğe yüklemediği sürece eski (süresi dolmak üzere olan) sertifikayı sunmaya devam eder. Yenileme sonrasında servislerin systemctl reload komutuyla yeniden yüklenmesi hayati önem taşır.

3. Cron Job Yerine Systemd Timer Tercih Etmemek

Geleneksel olarak cron tablosuna eklenen certbot renew komutları yaygındır. Ancak cron servisinin kendi içindeki loglama eksiklikleri ve sistem açılış zamanlamalarındaki uyumsuzluklar nedeniyle zaman zaman atlanabilir. Modern Linux dağıtımlarında systemd timer mekanizmaları çok daha güvenilir bir alternatif sunar.

Adım Adım Sağlam Otomasyon Kurulumu

Sistemimizde Certbot’un düzgün çalışıp çalışmadığını test etmek ve bunu kalıcı hale getirmek için aşağıdaki adımları izleyebiliriz.

Adım 1: Dry-Run (Kuru Sıkı) Testi

Sertifikanızı gerçekten yenilemeden önce sürecin hatasız çalışıp çalışmadığını test etmek için dry-run parametresi kullanılır. Bu komut Let’s Encrypt’in test sunucularına bağlanır ve tüm süreci simüle eder:

sudo certbot renew --dry-run

Eğer bu komut The dry run was successful çıktısını veriyorsa, doğrulama ve dosya yolları doğru yapılandırılmış demektir. Hata alıyorsanız, çıktıyı dikkatlice inceleyerek eksik portları (örn: Firewall üzerinde port 80 kapalı olabilir) veya yanlış dizin yollarını tespit edebilirsiniz.

Adım 2: Post-Renewal (Yenileme Sonrası) Hook Yapılandırması

Sertifika yenilendikten sonra web sunucusunun yapılandırmayı okuması gerekir. Bunu Certbot’un yapılandırma dosyasına (/etc/letsencrypt/renewal/sizin-alanadiniz.conf) ekleyebilir veya doğrudan komut satırında belirtebilirsiniz.

Örnek bir Nginx yeniden yükleme kancası (hook) şu şekildedir:

sudo certbot renew --post-hook "systemctl reload nginx"

Bu komut, yalnızca sertifika başarıyla yenilendiğinde Nginx servisini yeniden yükler. Gereksiz yere her kontrol döngüsünde servisi restart etmez.

Adım 3: Systemd Timer ile Güvenilir Zamanlama

Çoğu modern Linux paket yöneticisi Certbot’u kurarken otomatik olarak bir systemd timer (certbot.timer) tanımlar. Bunun aktif olup olmadığını ve düzgün çalışıp çalışmadığını kontrol etmek için şu komutu çalıştırın:

sudo systemctl status certbot.timer

Eğer aktif değilse etkinleştirmek için:

sudo systemctl enable --now certbot.timer

Sistemdeki timer’ların listesini ve sonraki tetiklenme zamanlarını görmek için ise:

sudo systemctl list-timers

komutunu kullanabilirsiniz. Bu yapılandırma, sistem her açıldığında ve günde iki kez arka planda rastgele bir zaman diliminde yenileme kontrolü yapar. Let’s Encrypt sunucularına aynı anda binlerce sunucunun istek atmasını önlemek için bu rastgele gecikme (jitter) mekanizması oldukça akıllıca tasarlanmıştır.

İleri Düzey Senaryo: HTTP-01 Yerine DNS-01 Challenge Kullanımı

Eğer sunucunuz dış dünyaya doğrudan 80 numaralı port üzerinden açık değilse (örneğin arkada çalışan bir iç servis veya güvenlik politikaları gereği port 80 kapalı tutuluyorsa), HTTP-01 doğrulaması başarısız olacaktır. Bu gibi senaryolarda DNS-01 challenge kullanılmalıdır.

DNS-01 doğrulaması, alan adınızın DNS sağlayıcısının API’sini kullanarak geçici bir TXT kaydı oluşturur ve Let’s Encrypt bu kaydı sorgulayarak sahipliği doğrular. Cloudflare, Route53 veya DigitalOcean gibi popüler DNS sağlayıcıları için Certbot eklentileri mevcuttur.

Örneğin, Cloudflare için DNS eklentisi kurulumu:

Eklentinin yüklenmesi (Debian/Ubuntu tabanlı sistemler için):
```
sudo apt install python3-certbot-dns-cloudflare
```
Cloudflare API anahtarınızı içeren güvenli bir kimlik bilgisi dosyası oluşturun (/etc/letsencrypt/cloudflare.ini):
```
dns_cloudflare_api_token = GIZLI_API_TOKENINIZ
```
Dosya izinlerini kısıtlayın (Kritik güvenlik adımı!):
```
sudo chmod 600 /etc/letsencrypt/cloudflare.ini
```

Sertifikayı DNS doğrulama yöntemiyle talep edin:

sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d ornek.com -d *.ornek.com

Bu yöntem sayesinde wildcard (*.ornek.com) sertifikalar üretebilir ve sunucunuzun dış dünyaya 80 numaralı portunu açmak zorunda kalmadan güvenli bir şekilde otomatik yenileme sağlayabilirsiniz.

Loglama ve Proaktif İzleme

Otomasyon kurmak harika bir adımdır ancak her otomasyonun sessizce hata yapma potansiyeli vardır. Bu yüzden log takibi operasyonel sürekliliğin anahtarıdır.

Certbot logları varsayılan olarak /var/log/letsencrypt/ dizini altında saklanır. Yenileme sürecinde bir sorun olup olmadığını düzenli olarak incelemek veya bir izleme aracıyla (Zabbix, Prometheus vb.) bu logları taramak mümkündür.

Ayrıca, sertifikanın bitiş tarihlerini bash betikleriyle kontrol edip süछeye yaklaşan sertifikalar için uyarı mekanizmaları kurabilirsiniz. Örnek basit bir OpenSSL komutu ile sertifikanın kalan gün sayısını terminalden görebilirsiniz:

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

Sonuç

Let’s Encrypt sertifika yönetimi, doğru yapılandırıldığında sistem yöneticisinin unuttuğu ve arkada sorunsuz çalışan bir yapı haline gelir. Ancak “kur ve unut” yaklaşımı yerine, kullanılan doğrulama yönteminin (HTTP-01 vs DNS-01) güncelliğini koruması, servis yeniden başlatma kancalarının tanımlı olması ve systemd timer durumlarının periyodik olarak kontrol edilmesi üretim ortamlarının sağlığı için elzemdir.

Küçük bir yapılandırma hatasının büyük kesintilere yol açabileceğini unutmayın; otomasyonunuzu her zaman dry-run ile test edin ve loglarınızı izlenebilir kılın.

Bu yazı Gemini ile otomatik oluşturulmuştur.