Let’s Encrypt Otomatik SSL Yenileme Sorunları: Net Teşhis ve Çözüm

Let’s Encrypt’te otomatik SSL (ACME) yenileme başarısız olduğunda en sık görülen sonuç: siteye gelen HTTPS trafiğinin kısa sürede uyarı sayfalarına düşmesi veya bazı istemcilerde güven zinciri hatası görülmesidir. Bu yazıda, yenilemenin neden bozulduğunu hızlıca daraltmak için izlenecek teşhis hattını veriyoruz. Hedef; “nerede takıldı” sorusunu loglardan başlayıp sertifika zincirini doğrulamaya kadar net adımlarla cevaplamak.

Aşağıdaki senaryolara odaklanacağız: - Yenileme komutu çalışıyor ama sertifika güncellenmiyor. - ACME doğrulaması (HTTP-01/DNS-01) başarısız oluyor. - Tarih/sağlayıcı zinciri hatası yüzünden istemciler sertifikayı reddediyor. - Otomasyon (systemd timer/cron) düzgün tetiklenmiyor. - Nginx/Apache yeni sertifikayı kullanmıyor (reload eksikliği).

1) Sorunu önce “türüne” ayırın: doğrulama mı, kurulum mu?

Yenileme problemlerini teşhis ederken ilk kritik ayrım, ACME sunucusunun yeni sertifikayı üretmesine kadar olan süreçte mi yoksa sertifikanın sunucuya uygulanması aşamasında mı sorun olduğudur.

Hızlı sınıflandırma matrisi

Aşağıdaki belirtiye göre hangi katmanda arıza arayacağınızı net seçin:

• Belirti: Sertifika tarihleri dolmak üzere/korunmuş ama tarayıcı hata veriyor.
• Muhtemel katman: Sertifika zinciri (chain) veya yanlış sertifika dosyası kullanım.
• Belirti: Let’s Encrypt kayıtlarında “authorization failed / incorrect response” gibi mesajlar.
• Muhtemel katman: ACME doğrulama (HTTP-01/DNS-01) başarısız.
• Belirti: “No renewal due” veya hiç log oluşmuyor.
• Muhtemel katman: Zamanlama (timer/cron), config veya domain eşleme.
• Belirti: Sertifika yenileniyor görünüyor ama site hâlâ eski sertifikayla açılıyor.
• Muhtemel katman: Web sunucusu reload edilmiyor ya da yanlış ssl_certificate dosyası işaretli.

ACME yenilemenin standart akışı

Çoğu kurulumda süreç şu sırayla akar: 1. Otomasyon tetiklenir (örn. certbot renew) 2. ACME doğrulama yöntemi çalışır (HTTP-01 veya DNS-01) 3. Sertifika üretilir, dosyalara yazılır 4. Gerekirse web sunucusu reload edilir (hook)

Bu akışta hangi adımın başarısız olduğuna loglardan bakarak karar verin.

2) En hızlı teşhis: certbot/log ve otomasyon zamanlaması

Loglar, sorunun kök nedenini genellikle ilk 5 dakikada ortaya çıkarır. Aşağıdaki kontrolleri sırasıyla yapın.

a) Systemd timer / cron çalışıyor mu?

Önce otomasyonun gerçekten tetiklenip tetiklenmediğini doğrulayın.

• Systemd timer kullanıyorsanız:
• systemctl list-timers --all | grep -i cert

• systemctl status certbot.timer

• Cron kullanıyorsanız:

• crontab -l
• ayrıca sistem cron dosyaları: /etc/cron.*

Net kontrol: Son 30 günde yenileme tetiklenmiyorsa “yenileme başarısız” aramak boşa zaman kaybettirir. Önce tetiklenmeyi düzeltin.

b) Certbot yenileme loglarını inceleyin

Genelde log konumları şunlardır: - /var/log/letsencrypt/letsencrypt.log - /var/log/letsencrypt/letsencrypt.log.* - journalctl (systemd ile çalışanlarda)

Örnek teşhis komutları: - journalctl -u certbot --since "30 days ago" - /var/log/letsencrypt/letsencrypt.log dosyasında tarih aralığı tarama

Loglarda aranan ifadeler (tam eşleşme şart değil) şunlar olur: - Doğrulama hataları: urn:ietf:params:acme:error, authorization failed, incorrect response, NXDOMAIN - Doğrulama yöntemi kaynaklı: http-01, dns-01, TXT record, challenge - Yenileme durumu: not yet due, no renewal due - Hook hataları: An error occurred while running the --deploy-hook

c) DNS/HTTP doğrulama başarısızlıklarını logdan tek hamlede tanıyın

ACME doğrulama hatası olduğunda log, hangi yöntemle (HTTP-01 mi DNS-01 mi) denendiğini yazar.

• HTTP-01 başarısız: Genelde 80 portu / yönlendirme / CDN katmanı devrededir.
• DNS-01 başarısız: Genelde TXT kaydı yayılım gecikmesi, yanlış zone veya sağlayıcı API sorunu.

3) Zincir kontrolü: Yenilendi sanılan sertifika gerçekten doğru mu?

Yenileme başarıyla tamamlanmış görünse bile tarayıcıda “tam güven” hatası görülebilir. Bunun iki ana nedeni vardır: 1. Sunucu yanlış dosyayı kullanıyordur (ör. intermediate/chain eksik) 2. Sertifika zinciri değişmiştir ve chain doğru yapılandırılmamıştır

a) Sunucudan görünen sertifikayı doğrulayın

Yerinde doğrulama için openssl en pratik araçtır.

• İstemciye sunulan sertifikayı kontrol:
• openssl s_client -connect domain.tld:443 -servername domain.tld -showcerts

Buradan şunları kontrol edin: - Sertifikanın Not After (bitiş tarihi) - Sertifika sahibinin (CN/SAN) doğru domain olup olmadığı - Intermediate/chain sunuluyor mu

Not: Bazı sistemlerde openssl s_client yerine openssl s_client benzeri komut varyasyonları olabilir; kullandığınız OS’ye göre doğrulayın.

b) Chain dosyaları doğru mu?

Nginx/Apache tarafında genelde iki dosya düşünün: - Sertifika (leaf) - Chain (intermediate)

Nginx’te örnek mantık: - ssl_certificate leaf’i - ssl_certificate_key özel anahtarı - ssl_trusted_certificate çoğu kurulumda chain için kullanılır (kullanım şekli dağıtıma göre değişir)

Apache’da ise benzer şekilde SSLCertificateFile ve SSLCertificateChainFile mantığı bulunur (yapılandırma sürüme göre farklıdır).

Net kontrol: “Yenilendi” dediğiniz dosyalar ile web sunucunun okumakta olduğu dosya yolları birebir aynı olmalı. Yenileme dosyaları genelde /etc/letsencrypt/live/<domain>/ altında güncellenir; web sunucunun config’i farklı bir path’e bakıyorsa sorun devam eder.

c) Çekirdek teşhis: Sertifika dosya hash’i ve zaman damgası

Aşağıdaki yaklaşım, “sertifika güncellendi mi?” sorusunu hızlı yanıtlar: - Yenileme sonrası /etc/letsencrypt/live/<domain>/ altındaki dosyaların mtime (değişim zamanı) değişti mi? - Web sunucunun kullandığı dosyaların mtime değişti mi?

Değişmiyorsa ya yenileme aslında gerçekleşmemiştir ya da sunucu farklı dosyaya bağlıdır.

4) HTTP-01 mi DNS-01 mi? Doğrulama katmanı için net checklist

Loglardan yöntem belirlendikten sonra doğrulama hatasını tek tek daraltın.

H3: HTTP-01 doğrulama sorunları (80 portu ve yönlendirme)

HTTP-01, ACME doğrulama isteğini belirli bir URL’e yönlendirir. Bu isteğin doğru yere ulaşması gerekir.

Kontrol listesi (HTTP-01): - 80 portu açık mı (security group / firewall / NAT)? - Site, 80’den 443’e zorunlu redirect yapıyor mu? - Redirect genelde çalışır; ancak bazı CDN/WAF kuralları doğrulama path’ini engeller. - Nginx/Apache doğru location veya Alias kuralını içeriyor mu? - /.well-known/acme-challenge/ yoluna karşı özel bir blok var mı? - CDN varsa doğrulama path’i cache/redirect/WAF tarafından etkileniyor mu?

Pratik doğrulama: - Birden fazla yerden (kendi internetiniz + farklı mobil hat) http://domain.tld/.well-known/acme-challenge/test tarzı test yapın.

H3: DNS-01 doğrulama sorunları (TXT kaydı ve TTL)

DNS-01 doğrulamada TXT kaydı gerekir. Sorun çoğunlukla “TXT kaydı ekleniyor ama ACME görmüyor” şeklinde çıkar.

Kontrol listesi (DNS-01): - Doğru zone dosyasına kayıt ekleniyor mu? - TXT kaydının adı doğru mu (subdomain kullanımı)? - Yayılım süresi tamamlanmadan yenileme deneniyor mu? - Dinamik DNS veya CDN “DNS cache” etkisi var mı?

Net teşhis ipucu: - Logda NXDOMAIN veya no TXT record görürseniz, doğru zone/rekot türünü hedefleyin. - timeout görürseniz yayılım/propagasyon süresini ve DNS sağlayıcı tarafındaki gecikmeyi ölçün.

5) Yenilendi ama site hâlâ eski: web sunucusu reload ve hook doğrulaması

Sertifika dosyaları güncellenmiş olabilir; ancak web sunucusu reload edilmediği için istemciler hâlâ eski leaf’i görür.

a) Deploy hook çalışıyor mu?

Certbot yenileme sırasında genellikle bir --deploy-hook veya dağıtıma özgü otomasyon kullanılır.

Net kontrol: - Yenileme loglarında “deploy hook” ile ilgili satırlar var mı? - Web sunucusu reload komutu (örn. nginx -s reload veya systemctl reload nginx) tetikleniyor mu?

Örneğin Nginx için tipik reload: - systemctl reload nginx

b) Nginx/Apache config’inde kullanılan sertifika yollarını eşleştirin

Web sunucunun config’inde şu hatalar sık görülür: - ssl_certificate başka bir path’i gösteriyor (eski kopya) - Symlink yerine kopya dosya kullanılmış - Chain dosyası hiç bağlanmamış

Net kontrol: Web sunucunun config’inde geçen dosya yolları ile /etc/letsencrypt/live/<domain>/ altındaki dosyalar uyumlu olmalı.

c) Çoklu site / SNI / sanal host karmaşası

Bir sunucuda birden fazla domain varsa, SNI (Server Name Indication) ve vhost eşleşmesi kritik olur.

Belirti: openssl s_client -servername domain.tld ile baktığınızda doğru sertifika görünmüyor.

Bu durumda: - İlgili vhost bloğunun server_name kısmı tam domain’i kapsıyor mu? - Varsayılan vhost yanlış domain’e leaf sertifika servis ediyor mu?

6) Çözüm stratejisi: sorunu “tek adımda” düzeltmek için çalışma planı

Bu bölümde, loglardan zincir kontrolüne uzanan pratik bir aksiyon planı veriyoruz. Amacımız rastgele deneme yapmak yerine, belirli sırayla hatayı kapatmaktır.

1) Otomasyon tetikleniyor mu?

• certbot.timer veya cron son çalışmayı gösteriyor mu?
• Son 30 günde yenileme denemesi var mı?

2) Yenileme denemesi gerçekten ACME’e ulaşıyor mu?

• Logda http-01/dns-01 ve authorization failed gibi ifadeler var mı?
• Hangi domain/alias için başarısız?

3) Doğrulama yöntemi kaynaklı problemi düzeltin

• HTTP-01 ise: 80 erişimi, redirect kuralları, WAF/CDN istisnaları
• DNS-01 ise: TXT kayıt adı ve zone doğruluğu, yayılım süresi

4) Sertifika dosyası güncellendi mi?

• /etc/letsencrypt/live/<domain>/ dosya zamanları değişti mi?

5) Sunucu gerçekten yeni leaf’i servis ediyor mu?

• openssl s_client -connect domain.tld:443 -servername domain.tld -showcerts
• Leaf + chain tam mı?

6) Web sunucuyu reload/hook ile senkronize edin

• Deploy hook loglarını doğrulayın
• Gerekirse manuel reload yapın ve config yol eşleşmesini kontrol edin

7) Son adım: yenilemeyi simüle edin

Gerçek yenileme zamanı gelmeden test etmek isterseniz “dry-run” yaklaşımı kullanın. - Örneğin certbot sürümünüze göre --dry-run ile yapılandırmayı test edin.

Dry-run, doğrulama hatalarını erken yakalamak için kullanılır; zincir/chain ve reload senaryosunu da aynı mantıkla doğrulayın.

Sonuç: 15 dakikalık net teşhis hattını uygulayın

Let’s Encrypt yenileme sorunlarını çözmenin en hızlı yolu “otomasyon çalışıyor mu → ACME doğrulama geçti mi → sertifika dosyaları gerçekten güncellendi mi → sunucu yeni sertifikayı servise mi aldı → zincir tam mı?” sorularını sırayla yanıtlamaktır. Aksiyonu hemen başlatın: önce timer/cron tetiklerini kontrol edin, ardından certbot loglarında doğrulama hatasını yakalayın, en son openssl ile sunulan sertifika zincirini doğrulayın ve web sunucuyu reload/hook ile senkronize edin. Bu sıra bozulduğunda teşhis uzar; bu sıra korunduğunda ise sorun çoğu durumda aynı gün içinde kapatılır.