Let's Encrypt Sertifikasının Otomatik Yenilenmesi ve Hataların Giderilmesi

Site açılıyor, ancak tarayıcı kırmızı bir sayfa gösteriyor ve sertifikanın süresinin dolduğunu söylüyor. Düne kadar her şey yolundaysa ve kimse sunucuya manuel olarak dokunmadıysa, muhtemelen Let's Encrypt otomatik yenilemesi başarısız olmuş ve siz bunu süre bitiminden sadece birkaç saat sonra fark etmişsinizdir. Bu makale tam o an hakkında: otomatik yenileme neden çalışmıyor, wildcard sertifikası için DNS challenge nasıl yapılandırılır ve bugün neyi kontrol etmeniz gerekiyor.

Önce yenilemenin gerçekten çalışıp çalışmadığını anlayın

Herhangi bir değişiklik yapmadan önce logu okuyun. Certbot genellikle /var/log/letsencrypt/letsencrypt.log dosyasına yazar ve gerçek hata tam oradadır, cron çıktısında değil.

grep -i "error\|failed\|challenge" /var/log/letsencrypt/letsencrypt.log | tail -40

Timeout during connect veya Invalid response from http://example.com/.well-known/acme-challenge/... hatası görürseniz, sorun HTTP erişimindedir. DNS problem: NXDOMAIN görürseniz, sorun DNS kaydındadır. Bu iki yol tamamen farklıdır ve bunları karıştırmak çok zaman alır.

Her şeyden önce bir deneme testi de faydalıdır:

certbot renew --dry-run

Bu komut hiçbir sertifika vermez, sadece challenge yolunu sonuna kadar test eder. Dry-run başarılı olursa ama site hâlâ süresi dolmuş görünüyorsa, sorun yapılandırmada değil cron zamanlamasındadır.

Let's Encrypt yenileme başarısızlığının en yaygın nedeni

Deneyimlerime göre, başarısızlıkların çoğunun tek bir nedeni var: web sunucusu 80 numaralı portta HTTP-01 challenge'a yanıt vermiyor. Let's Encrypt dışarıdan http://your-domain/.well-known/acme-challenge/<token> adresine istek gönderir ve belirli bir dize bekler. Bu yol HTTPS'e yönlendirilirse, güvenlik duvarı 80 numaralı portu kapatmışsa veya sunucunun önünde bu yolu tanımayan bir reverse proxy varsa, challenge başarısız olur.

Üç durumu ayrı ayrı kontrol edin:

• nginx veya Apache'de /.well-known/acme-challenge/ yolunu da yutan zorunlu HTTP'den HTTPS'e yönlendirme.
• 443 açıkken 80 numaralı portu dışarıdan kapatan güvenlik duvarı veya bulut Security Group.
• Sitenin önündeki, challenge isteğini kaynağa iletmeyen CDN veya proxy.

Standart çözüm, challenge yolunu yönlendirmeden muaf tutmaktır. nginx'te genel yönlendirmeden önce bir location:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/html;
    default_type "text/plain";
    allow all;
}

Apache'de de eşdeğeri, yönlendirme kuralından önce RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/ ile yazılır. CDN arkasındaysanız, ya yolu önbellek ve proxyden muaf tutun ya da tamamen DNS challenge'a geçin.

Burada hata yapıyorlar

Yaygın hata, site yöneticisinin hatayı gördükten sonra manuel olarak certbot renew --force-renewal çalıştırıp sertifikayı yeniden vermesidir. Site açılır, herkes mutlu olur ve üç ay sonra tam olarak aynı şey tekrarlanır. Çünkü asıl neden, yani cron veya systemd timer, hiç düzeltilmemiştir. Bunun işareti de logda başarılı yenileme tarihlerinin her zaman süre bitiminden birkaç saat önce kaydedilmiş olmasıdır, ondan önceki otuz günlük aralıkta değil. Yenilemeler her zaman son dakikada yapılıyorsa, otomasyonunuz çalışmıyor demektir ve siz sadece manuel olarak kurtarıyorsunuz.

Wildcard sertifikası için DNS challenge

*.example.com gibi bir wildcard sertifikası HTTP-01 ile verilmez. DNS-01 kullanmanız gerekir, yani değeri ACME client tarafından üretilen token olan _acme-challenge.example.com adında bir TXT kaydı oluşturmanız gerekir. Bu yöntemin önemli bir avantajı vardır: 80 numaralı portun açık olmasına gerek yoktur ve yalnızca dahili olan sunucular için de çalışır.

Kayıt yapısı şu şekildedir:

_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

Birçok kişiyi alt eden nokta TTL'dir. TTL'yi 86400 yaparsanız ve sonradan token'ı değiştirmek isterseniz, resolver'lar bir güne kadar eski sürümü önbelleğe alabilir ve doğrulama başarısız olur. Challenge kaydı için TTL'yi 60 veya 120 saniye yapın ve verildikten sonra silin.

Otomasyon için DNS plugin'lerini kullanın. Örneğin Cloudflare ile:

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cf.ini \
  -d example.com -d "*.example.com"

Kimlik bilgileri dosyası 600 iznine sahip olmalıdır. Bu dosyayı varsayılan 644 izniyle bırakırsanız, sunucudaki herhangi bir kullanıcı API token'ınızı okuyabilir ve alan adının DNS kayıtlarını değiştirebilir. Bu, dosya iznindeki küçük bir hatanın alan adının tamamen ele geçirilmesine yol açtığı yerlerden biridir.

Hook'lar ve servis yeniden yükleme

Sertifika yenilenir ama web sunucusu onu yeniden okumaz. Sonuç, diskteki dosyanın yeni bir tarihe sahip olması ama tarayıcının hâlâ eski sertifikayı görmesidir. Her yenilemeden sonra servisi reload etmelisiniz:

certbot renew --deploy-hook "systemctl reload nginx"

HAProxy veya Postfix gibi sertifikayı bellekte tutan servisler için reload yeterli değildir ve restart etmeniz gerekir. Burada gerçek bir trade-off vardır: restart aktif bağlantıları keser, bu nedenle yoğun trafiğiniz varsa reload'u tercih edin ve yalnızca gerçekten ihtiyaç duyan servisler için restart yapın.

Sertifika sağlığını dışarıdan kontrol etme

Sunucu içinden her şey sağlıklı görünür, ama kullanıcı açısından değil. Her zaman dışarıdan kontrol edin:

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

notAfter çıktısını bugünün tarihiyle karşılaştırın. 15 günden az kaldıysa ve otomatik yenileme etkinse, otomasyonunuz başarısız olmuş demektir ve logu görmelisiniz. DNS kayıtlarını ve challenge yolunu kontrol etmek için DNS ve ağ kontrol araçları işi hızlandırır ve başka bir sunucudan test yapmanıza gerek kalmaz.

Sertifika zinciri hakkında bir not: Sunucunuz TLS yanıtında ara sertifikayı (intermediate) göndermiyorsa, bazı tarayıcılar ve çoğu mobil istemci, ana sertifika geçerli olsa bile zincir hatası verir. Yalnızca cert değil, fullchain dosyasını kullanın.

Otomasyonu doğru kurun

Certbot 0.21 sürümünden itibaren systemd timer'a sahiptir ve artık manuel cron'a gerek yoktur. Hem cron hem de timer etkinse, iki örnek aynı anda çalışır ve Let's Encrypt rate limit'ine takılabilirsiniz. Birini devre dışı bırakın:

systemctl list-timers | grep certbot
systemctl status certbot.timer

Timer etkinse, /etc/cron.d/certbot içindeki cron satırını silin. Let's Encrypt rate limit'i yinelenen alan adı için katıdır ve arka arkaya birkaç kez başarısız olursanız birkaç gün kilitlenirsiniz. Bu tam olarak site yöneticisinin ticari sertifikaya başvurduğu andır, oysa sorun yalnızca yinelenen bir timer'dır.

Load balancer arkasında birden fazla sunucunun olduğu yoğun trafikli ortamlar için, sertifikayı tek bir sunucuda yönetin ve dosyayı Ansible veya rsync gibi bir araçla diğerlerine dağıtın. Sertifikayı her sunucuda ayrı ayrı vermek, hem sizi rate limit'e yaklaştırır hem de yönetimi kâbusa çevirir. Aynı altyapı üzerinde daha fazla güvenlik katmanı arıyorsanız, ServerNet sunucu güvenliği hizmetleri yönetilen güvenlik duvarı ve izleme gibi tamamlayıcı seçenekleri kapsar.

Ve pratik bir uyarı: Sertifika süresi dolma izlemesini ciddiye alın. Her sabah notAfter değerini kontrol eden ve 20 günden az kaldıysa uyarı veren basit bir script, sizi gece saat ikiden ve kırmızı sayfadan kurtarır. Sistem loglarını da bozulmadan ve delil olarak kullanılabilir şekilde saklarsanız, olay incelemesi sırasında yenilemenin tam olarak ne zaman ve neden başarısız olduğunu söyleyebilirsiniz.

Sıkça sorulan sorular

Otomatik yenileme olmasına rağmen Let's Encrypt sertifikam neden süresi dolmuş durumda?

Çünkü otomatik yenileme gerçekten çalışmamış veya çalışırken başarısız olmuştur. En yaygın neden, 80 numaralı portun kapalı olması veya /.well-known/acme-challenge/ yolunun HTTPS'e yönlendirilmesidir. Kesin hatayı bulmak için /var/log/letsencrypt/letsencrypt.log dosyasına bakın.

İkinci neden, systemd timer veya cron'un devre dışı olmasıdır. systemctl status certbot.timer ile durumu kontrol edin.

Wildcard sertifikası için DNS challenge nasıl çalışır?

Bu yöntemde, değeri ACME client tarafından üretilen token olan _acme-challenge.example.com adında bir TXT kaydı oluşturursunuz. Let's Encrypt bu kaydı DNS üzerinden okur ve eşleşirse sertifikayı verir.

Avantajı, 80 numaralı portun açık olmasına gerek olmamasıdır ve dahili sunucular için de çalışır. Sadece TTL'yi kısa tutun ki token değişikliği hızlı yayılsın.

HTTP-01 mi yoksa DNS-01 mi kullanmalıyım?

Yalnızca basit bir alan adınız varsa ve 80 numaralı port açıksa, HTTP-01 daha basittir ve daha az yapılandırma gerektirir. Wildcard sertifikası istiyorsanız, sunucu güvenlik duvarı arkasındaysa veya CDN kullanıyorsanız, DNS-01 doğru seçimdir.

Birden fazla alt alan adı olan her şey için DNS-01'i tercih ederim; çünkü bir kez ayarlanır ve sonrasında portların ve proxylerin durumundan bağımsız olarak çalışır.

Sertifika yenilendikten sonra tarayıcı neden hâlâ eski sertifikayı gösteriyor?

Çünkü web sunucusu yeni sertifikayı yeniden okumamıştır. Yenilemeden sonra servisi reload etmelisiniz. --deploy-hook "systemctl reload nginx" ile bu otomatikleşir.

HAProxy veya Postfix kullanıyorsanız, reload yeterli değildir ve restart etmeniz gerekir. Restart'ın aktif bağlantıları kestiğini unutmayın.