Let's Encrypt Artık Uyarı Maili Atmıyor: SSL Süresini Kendiniz İzleme

Pazartesi sabahı ilk telefon müşteriden geliyor: "Site açılmıyor, kırmızı bir uyarı çıkıyor." Tarayıcıda NET::ERR_CERT_DATE_INVALID yazıyor. Sertifikanın süresi dün gece dolmuş. Refleks olarak gelen kutusunu açıp arıyorsunuz — yıllardır "sertifikanızın süresi 20 gün içinde doluyor" diye gelen o mail nerede? Yok. Spam klasöründe de yok. Çünkü Let's Encrypt o e-postaları göndermeyi 4 Haziran 2025'te bıraktı.

Bu, küçük bir servis değişikliği gibi görünür ama pratikte yıllardır ayakta duran son emniyet kemerinin çıkarılması demektir. Otomatik yenileme zaten çoğu sunucuda kuruluydu; uyarı maili ise otomasyon sessizce bozulduğunda devreye giren tek yedek mekanizmaydı. Şimdi otomasyon bozulduğunda hiçbir yerden ses çıkmıyor. Sertifikanız bittiği anı öğrenme şansınız, ziyaretçilerinizin sizi araması kadar.

Bu yazıda o boşluğu kendi izlemenizle kapatmayı anlatıyorum: yenilemenin gerçekten çalışacağını önceden kanıtlama, zamanlayıcının çalıştığını doğrulama, sunucunun fiilen sunduğu sertifikanın kalan gününü ölçen bir kontrol betiği, hiçbir uyarı kurgusunun yakalayamadığı "kontrol de durdu" durumunu yakalayan ölü adam anahtarı ve sunucudan tamamen bağımsız harici doğrulama. Yenilemeyi henüz kurmadıysanız önce SSL otomatik yenileme rehberine bakın; burada kurulanın çalışmaya devam ettiğini nasıl bileceğinize odaklanıyoruz.

Let's Encrypt Uyarı Maili Neden Artık Gelmiyor?#

Let's Encrypt, süre bitiş bildirimi servisini Ocak 2025'te duyurdu ve 4 Haziran 2025 itibarıyla tamamen sonlandırdı. Ardından sertifika veritabanında tuttuğu e-posta adreslerini de sildi. Gerekçeleri üç başlıktaydı: aboneliklerin büyük çoğunluğu artık otomasyonla yenileniyor, milyonlarca e-posta adresini sertifika kayıtlarına bağlı tutmak gizlilik ilkeleriyle çelişiyor ve bu servisin yıllık maliyeti altyapıya harcanabilecek ciddi bir bütçe tutuyordu.

Karar kendi içinde tutarlıdır, ama sizin tarafınızda bir sonucu vardır ve o sonuç net: ACME hesabınıza bir e-posta yazmış olmanız artık hiçbir koruma sağlamıyor. certbot update_account --email ... komutunu çalıştırmış olsanız bile o adrese süre uyarısı gelmez. İnternette hâlâ dolaşan "hesap e-postanızı güncel tutun, Let's Encrypt sizi uyarır" tavsiyesi bugün geçersizdir.

Bunun pratik anlamı şudur: sertifika izleme artık sağlayıcının değil, sizin sorumluluğunuzdadır. Ve bu sorumluluk "yenilemeyi kurdum" ile bitmez, çünkü asıl risk yenilemenin hiç kurulmamış olması değil, kurulduktan sonra bir gün sessizce çalışmayı bırakmasıdır.

Sertifika Ömürleri Kısalırken Hata Payı Nasıl Daraldı?#

İkinci değişiklik aynı yöne itiyor. CA/Browser Forum, azami sertifika geçerlilik süresini kademeli olarak düşürme kararı aldı ve takvim şöyle işliyor:

Let's Encrypt sertifikaları zaten 90 gündü ve bu takvimden şimdilik daha kısa. Ama tablo asıl şunu gösteriyor: yenileme olayı yılda bir kez yaşanan bir tören olmaktan çıkıp haftalık ritme yaklaşıyor. Bir mekanizma ne kadar sık çalışırsa, arızalanma fırsatı da o kadar artar. Aynı zamanda fark etme pencereniz daralır: 398 günlük bir sertifikada yenileme bozulsa aylarca vaktiniz olurdu; 47 günlükte bozulmayı iki hafta içinde yakalamazsanız site kapanır. Bu geçişin arka planı ve nedenleri için sertifika geçerlilik süreleri yazısına bakabilirsiniz.

Sonuç basit bir denklemdir: uyarı maili gitti, yenileme sıklığı arttı, tolerans penceresi daraldı. Üçü aynı anda olduğu için "certbot kurulu, gerisi kendi hâlleder" yaklaşımı artık yeterli değil.

Yenilemeyi Sessizce Bozan Beş Senaryo#

Otomatik yenilemenin tehlikeli tarafı, başarısız olduğunda genellikle hiçbir yere hata yazmamasıdır. Aşağıdakiler, hata mesajı üretmediği ya da ürettiği yeri kimsenin okumadığı için aylarca fark edilmeyen tiplerdir.

1. Yenilendi ama servis yeniden yüklenmedi. Certbot dosyayı diskte tazeler, Nginx ya da Postfix eski sertifikayı bellekte tutmaya devam eder. certbot certificates "geçerli, 80 gün" der; tarayıcı ise süresi dolmuş sertifika görür. Yenileme kayıtları tertemizdir, çünkü yenileme gerçekten başarılı olmuştur.

2. Zamanlayıcı işletim sistemi yükseltmesinde devre dışı kaldı. Dağıtım yükseltmelerinde, paketten snap'e geçişlerde ya da iki farklı certbot kurulumu bir arada kaldığında timer pasifleşebilir. Kimse systemctl list-timers çıktısına bakmadığı sürece bu görünmez.

3. Konteyner yeniden kuruldu, /etc/letsencrypt kalıcı değildi. Yeni imajda sertifika ve yenileme yapılandırması yok; konteyner ayakta, site çalışıyor, sertifika ise bir daha hiç yenilenmeyecek.

4. Cron çıktısı hiçbir yere gitmiyor. Klasik satır sonundaki > /dev/null 2>&1, hata mesajını da yutar. Yutmasa bile cron çıktısı yerel posta kutusuna düşer ve çoğu sunucuda o kutuyu okuyan kimse yoktur, hatta yerel posta teslimi hiç çalışmıyordur.

5. Sertifikadaki bir ad artık doğrulanamıyor. www kaydı silinmiş, bir alt alan adı başka sunucuya taşınmış olabilir. Certbot bu durumda yenilemenin tamamını başarısız sayar ve mevcut sertifika olduğu gibi kalır — yani her şey normal görünürken geri sayım işler. cPanel AutoSSL ise tersini yapar: sorunlu adı kapsamdan sessizce düşürür ve daralmış bir sertifika kurar; site açılır, ama mail ya da www bir sabah uyarı vermeye başlar.

Bu beşinin ortak yanı, hepsinin sessiz olmasıdır. Bu yüzden izleme kurgusu "hata olursa haber ver" üzerine değil, "sağlıklı olduğunu düzenli olarak kanıtla" üzerine kurulmalıdır.

Adım 1: Yenilemenin Çalışacağını Önceden Kanıtlayın#

En ucuz kontrol, gerçek yenileme gününü beklemeden provasını yapmaktır. --dry-run Let's Encrypt'in test ortamına gider, üretim hız limitlerini harcamaz ve gerçek sertifikanızı değiştirmez.

# Tüm sertifikalar için yenileme provası
sudo certbot renew --dry-run

# Yalnızca tek bir sertifikayı dene
sudo certbot renew --cert-name alanadiniz.com --dry-run

Çıktının sonundaki özet satırında her sertifika için success görmelisiniz. Bir tanesi bile failure diyorsa, gerçek yenileme günü de aynı şekilde başarısız olacak demektir; arada değişen hiçbir şey yok.

İkinci komut, sunucunun kayıtlı sertifikalarını ve kalan gün sayılarını listeler:

sudo certbot certificates

Her giriş için Expiry Date satırında (VALID: 61 days) gibi bir ifade görürsünüz. Sertifikanın kapsadığı adları (Domains: satırı) da mutlaka okuyun — beklediğiniz adlardan biri eksikse kapsam daralmış demektir. Bu iki komutu sunucuda büyük bir değişiklik yaptığınız her seferde çalıştırma alışkanlığı, sorunların yarısını daha doğmadan yakalar. Certbot'un ileri seçenekleri için Certbot ileri düzey kullanım yazısı iyi bir referanstır.

Adım 2: Zamanlayıcının Gerçekten Çalıştığını Doğrulayın#

Prova geçse bile, yenileme komutunu kimse çalıştırmıyorsa sonuç değişmez. Önce zamanlayıcının canlı olduğunu görün:

# Timer var mı, ne zaman çalışacak, en son ne zaman çalıştı
systemctl list-timers --all | grep -i certbot

# Timer etkin mi
systemctl is-enabled certbot.timer && systemctl is-active certbot.timer

# Son çalışmaların kayıtları
journalctl -u certbot.service --since "60 days ago" --no-pager | tail -40

list-timers çıktısında LAST sütunu boşsa ya da haftalar öncesini gösteriyorsa timer fiilen çalışmıyordur. Bunu ayda bir elle kontrol etmek yerine, başarısızlığı size ittirecek bir yapı kurmak daha sağlamdır. systemd'nin OnFailure mekanizması tam olarak bunun içindir.

Önce bildirimi gönderecek şablon birimi oluşturun:

# /etc/systemd/system/[email protected]
[Unit]
Description=%i birimi basarisiz oldu

[Service]
Type=oneshot
ExecStart=/usr/local/bin/uyari-gonder.sh "SUNUCU: %H — %i basarisiz oldu"

Sonra certbot servisine bir ek yapılandırma yazın:

sudo systemctl edit certbot.service

Açılan düzenleyiciye şunu ekleyin:

[Unit]
OnFailure=bildir@%n.service

uyari-gonder.sh betiği ne isterseniz o olabilir: bir Telegram bot çağrısı, bir webhook, bir curl isteği. Önemli olan, hedefin sunucunun kendi posta sistemi olmamasıdır — sunucuda bir sorun varken sunucudan mail beklemek çoğu zaman boşa çıkar.

Hâlâ cron kullanıyorsanız çıktıyı /dev/null'a atmayın; bir dosyaya düşürüp o dosyayı kontrol edilebilir hâle getirin:

# Gunde iki kez yenileme dene, ciktiyi sakla
17 3,15 * * * /usr/bin/certbot renew --quiet >> /var/log/certbot-cron.log 2>&1

Adım 3: Sunucunun Sunduğu Sertifikayı Ölçen Kontrol Betiği#

Şimdiye kadarki kontroller certbot'un kendi durumunu okur. Ama "yenilendi ama reload edilmedi" senaryosunda certbot'un durumu sağlıklıdır; hatalı olan, ziyaretçinin gördüğü şeydir. Bu yüzden ölçümü ağ üzerinden, tıpkı bir ziyaretçi gibi bağlanarak yapmak gerekir — ve tek bir adrese değil, tüm uç noktalara.

#!/usr/bin/env bash
# ssl-sure-kontrol.sh — birden cok uc noktanin kalan gun sayisini olcer
set -u
ESIK=${ESIK:-21}

# bicim: host:port:starttls_protokolu  (bos ise dogrudan TLS)
HEDEFLER=(
  "alanadiniz.com:443:"
  "www.alanadiniz.com:443:"
  "mail.alanadiniz.com:993:"
  "mail.alanadiniz.com:587:smtp"
  "panel.alanadiniz.com:2083:"
)

SORUN=0
for satir in "${HEDEFLER[@]}"; do
  HOST=${satir%%:*}; kalan=${satir#*:}
  PORT=${kalan%%:*}; PROTO=${kalan#*:}
  [ -n "$PROTO" ] && SC="-starttls $PROTO" || SC=""

  BITIS=$(echo | openssl s_client -connect "$HOST:$PORT" -servername "$HOST" $SC 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)

  if [ -z "$BITIS" ]; then
    printf '%-30s %-6s BAGLANILAMADI\n' "$HOST" "$PORT"; SORUN=1; continue
  fi

  GUN=$(( ( $(date -d "$BITIS" +%s) - $(date +%s) ) / 86400 ))
  printf '%-30s %-6s %4d gun\n' "$HOST" "$PORT" "$GUN"
  [ "$GUN" -lt "$ESIK" ] && SORUN=1
done

exit $SORUN

Betiği çalıştırılabilir yapıp elle bir kez deneyin, sonra günlük bir göreve bağlayın:

sudo install -m 755 ssl-sure-kontrol.sh /usr/local/bin/ssl-sure-kontrol.sh
/usr/local/bin/ssl-sure-kontrol.sh; echo "cikis kodu: $?"

İki tasarım tercihi bilinçlidir. Birincisi, betik çıkış kodu döndürür; böylece bir systemd birimine bağlandığında OnFailure kendiliğinden devreye girer ve bildirim mantığını tekrar yazmanız gerekmez. İkincisi, hedef listesi 443 ile sınırlı değildir; posta portları ve panel portu ayrı satırlardır, çünkü bu adresler farklı servisler tarafından sunulur ve biri yenilenirken diğeri geride kalabilir. openssl çıktısını yorumlama konusunda ayrıntı için OpenSSL komutları yazısına bakın.

Eşik değeri için 21 gün makul bir başlangıçtır: Let's Encrypt 30 gün kala yenilemeye başladığı için, 21 günün altına düşen bir sertifika en az bir yenileme turunun kaçırıldığı anlamına gelir. Sertifika ömürleri kısaldıkça bu eşiği ömrün dörtte biri civarına çekmeniz gerekecek.

Adım 4: "Haber Yoksa İyi Haber" Yanılgısı ve Ölü Adam Anahtarı#

Buraya kadar kurduğunuz her şeyin ortak bir zayıflığı var: hepsi sorun olduğunda haber vermek üzerine kurulu. Peki kontrol mekanizmasının kendisi çalışmayı bırakırsa? Cron servisi durdu, betik yanlışlıkla silindi, disk doldu, sunucu kapandı. Bu durumda hiçbir uyarı gelmez ve sessizlik "her şey yolunda" olarak okunur. Oysa gerçekte hiçbir şey kontrol edilmiyordur.

Bu sorunun standart çözümü ölü adam anahtarıdır (dead man's switch): mantığı tersine çevirirsiniz. Kontrol başarılı olduğunda dışarıdaki bir servise "ben yaşıyorum" sinyali gönderirsiniz. Sinyal beklenen sürede gelmezse o servis sizi uyarır. Böylece hem kontrolün bulduğu sorunlar hem de kontrolün kendisinin durması yakalanır.

# Kontrol gecerse dis servise nabiz gonder; gecmezse gonderme
0 7 * * * /usr/local/bin/ssl-sure-kontrol.sh >> /var/log/ssl-kontrol.log 2>&1 \
  && curl -fsS -m 10 https://izleme.ornek.com/ping/ANAHTAR > /dev/null

Buradaki && operatörü tasarımın kalbidir: nabız yalnızca betik sıfır dönerse gönderilir. Sertifikanın günü azaldıysa nabız kesilir, kontrol hiç çalışmadıysa da kesilir. İki farklı arıza tek bir sinyalle yakalanmış olur. Aynı nabız satırını yenileme sonrası --deploy-hook içine de ekleyerek "yenileme gerçekten oldu mu" sorusunu bağımsız olarak izleyebilirsiniz.

Bu servisi dışarıdan almak istemiyorsanız, aynı işi ikinci bir sunucudaki basit bir kontrol de görür. Kritik olan nokta teknoloji değil, nabzı dinleyenin izlenen makineden başka bir yerde olmasıdır.

Adım 5: Sunucudan Bağımsız Doğrulama ve Panel Raporları#

Son katman, sunucunuz tamamen kapalıyken bile çalışan harici bir izlemedir. Uptime Kuma gibi araçlar bir HTTP kontrolü tanımlarken sertifika süresi bildirimini de açmanıza izin verir: kalan gün eşiğini belirlersiniz, altına düştüğünde Telegram, e-posta ya da webhook üzerinden uyarı gelir. Aracın kurulumu ve bildirim tanımları Uptime Kuma rehberinde anlatılıyor. Bu izlemeyi izlediği sunucunun üzerine kurmayın; aynı makinede duran bir izleme, makine çöktüğünde susar.

Paylaşımlı hostingte durum biraz farklıdır, çünkü yenileme sizin elinizde değildir. Buna karşılık iki gösterge vardır:

• cPanel → SSL/TLS Status: hesabınızdaki her alan adının sertifika durumunu ve bitiş tarihini tek ekranda listeler. Kapsam dışı kalmış bir ad burada gerekçesiyle görünür.
• AutoSSL bildirimleri: cPanel'in bildirim tercihlerinde AutoSSL ile ilgili uyarıları açık tutun; bir alan adı için sertifika alınamadığında hesap e-postasına bilgi gider.

AutoSSL'in çalışma mantığı ve kapsam sorunlarının çözümü için cPanel AutoSSL rehberi işinizi görecektir. Kendi sunucusu olmayan kullanıcılar için bile Adım 3'teki betik faydalıdır: kendi bilgisayarınızdan ya da başka bir sunucudan çalıştırıp barındırma sağlayıcınızın işini yapıp yapmadığını bağımsız olarak doğrulayabilirsiniz.

İzleme Listesi: Hangi Adları ve Portları Takip Etmelisiniz?#

Yenileme çoğu zaman "her şey" için değil, tek bir ad için kırılır. Bu yüzden izleme listesi ana alan adıyla sınırlı kalmamalıdır.

Listeyi hazırlarken pratik bir yöntem: sunucudaki yapılandırmalarda geçen tüm sunucu adlarını toplayın ve hiçbirini elemeden betiğe ekleyin.

# Nginx yapilandirmalarindaki tum server_name degerlerini topla
grep -rhoP '^\s*server_name\s+\K[^;]+' /etc/nginx/ | tr ' ' '\n' | sort -u

# Yerel sertifika dosyalarinin kapsadigi adlar ve bitis tarihleri
for c in /etc/letsencrypt/live/*/cert.pem; do
  echo "--- $c"
  openssl x509 -noout -enddate -ext subjectAltName -in "$c"
done

İkinci komut ayrıca kaçırılması kolay bir kontrolü verir: diskteki dosyanın bitiş tarihi ile ağdan ölçtüğünüz bitiş tarihi aynı mı? Farklıysa yenileme çalışmış ama servis yeniden yüklenmemiştir — bu yazının başında saydığımız birinci sessiz arıza tam olarak budur ve iki tarihi yan yana koymadan görülmez.

Sıkça Sorulan Sorular#

Let's Encrypt gerçekten hiç uyarı maili göndermiyor mu?#

Evet. Süre bitiş bildirimi servisi 4 Haziran 2025'te sona erdi ve saklanan e-posta adresleri silindi. ACME hesabınızda kayıtlı bir adres olması artık süre uyarısı almanızı sağlamaz. İnternette bulacağınız "hesap e-postanızı güncelleyin, uyarı gelir" tavsiyeleri bu tarihten öncesine aittir. İzleme sorumluluğu tamamen sunucu sahibindedir.

Certbot kurulu ve otomatik yenileme çalışıyor, yine de izlemem gerekir mi?#

Gerekir. En sık yaşanan arızalar yenilemenin hiç kurulmamış olması değil, kurulduktan sonra sessizce durmasıdır: timer bir yükseltmede pasifleşir, konteyner kalıcı olmayan bir dizinle yeniden kurulur ya da yenileme başarılı olur ama servis yeniden yüklenmediği için eski sertifika sunulmaya devam eder. Bu üç durumda da hiçbir hata mesajı üretilmez.

Kaç gün kala uyarı almalıyım?#

Let's Encrypt yenilemeyi bitişe 30 gün kala başlattığı için 21 gün iyi bir eşiktir: bu seviyeye düşen bir sertifika en az bir yenileme turunun kaçırıldığını gösterir. Genel kural olarak eşiği sertifika ömrünün dörtte biri kadar seçin. Ömürler kısaldıkça bu değeri aşağı çekmeniz gerekecek; 47 günlük sertifikalarda 12 gün makul bir seviyedir.

İzlemeyi izlediğim sunucunun üzerine kurabilir miyim?#

Kurabilirsiniz ama tek katman olarak yetmez. Sunucu kapandığında, diski dolduğunda ya da cron durduğunda o izleme de susar ve sessizlik yanlışlıkla "her şey yolunda" diye okunur. En az bir katmanın sunucudan bağımsız olması gerekir: harici bir izleme servisi, ikinci bir sunucu ya da başarı sinyali beklendiğinde uyaran bir ölü adam anahtarı.

Paylaşımlı hosting kullanıyorum, yenilemeyi ben yapmıyorum. Ne yapmalıyım?#

Yenilemeyi sağlayıcı yapsa da sonucu doğrulamak yine faydalıdır. cPanel'deki SSL/TLS Status ekranından bitiş tarihlerini düzenli kontrol edin, AutoSSL bildirimlerini açık tutun ve kritik alan adlarınız için harici bir sertifika süresi izlemesi kurun. Bir sorun çıktığında destek talebini süre dolmadan önce açmış olursunuz; sonrasında açmak çok daha pahalıdır.

Yalnızca ana alan adımı izlemek yeterli değil mi?#

Yeterli değildir, çünkü yenileme çoğu zaman tek bir ad için kırılır. DNS kaydı silinmiş bir alt alan adı yüzünden certbot yenilemenin tamamını başarısız sayabilir; cPanel AutoSSL ise sorunlu adı sessizce kapsamdan düşürür. Her iki durumda da ana site sorunsuz görünürken www, posta sunucusu adı ya da panel adresi bir sabah uyarı vermeye başlar.