SSL Sertifikası Otomatik Yenileme Nasıl Kurulur?

Bir SSL sertifikasını kurmak işin sadece yarısıdır; asıl mesele onu unutmadan yenilemektir. Let's Encrypt sertifikaları yalnızca 90 gün geçerli olduğu için, bir kere kurup elinizi çektiğinizde takvimde saatli bir bomba kurmuş olursunuz. Sertifikanın son gününde, çoğu zaman gece yarısı ya da bir tatil gününde tarayıcılar sitenize "Bağlantınız gizli değil" uyarısıyla karşılık verir, ziyaretçiler kaçar ve arama sıralamanız zarar görür. Oysa bu senaryonun tamamı otomasyonla ortadan kaldırılabilir: doğru kurulmuş bir yenileme mekanizması, siz hiç fark etmeden sertifikanızı süresi dolmadan haftalar önce tazeler.

Bu rehberde, Certbot'un modern kurulumlarla gelen systemd timer tabanlı otomatik yenilemesini, eski cron alternatifini ve ikisi arasındaki farkları ele alacağız. Ardından işin en sinir bozucu tarafına, yani yenilemenin neden sessizce başarısız olabileceğine ineceğiz: kapalı 80 portu, değişen webroot yolu, hız limitleri ve DNS sorunları gibi klasik tuzakları çözeceğiz. Son olarak yenileme sonrası web sunucusunu yeniden yükleyen deploy hook'unu ve sertifikanız süresi dolmadan sizi uyaracak bildirim e-postalarını nasıl kuracağınızı göstereceğiz. Let's Encrypt ve Certbot kurulumuna henüz hâkim değilseniz önce Let's Encrypt ile ücretsiz SSL kurulumu yazımızı okumanızı öneririz.

Sertifikalar Neden ve Ne Zaman Yenilenir?#

Let's Encrypt sertifikalarının kısa ömürlü olması bir kısıtlama gibi görünse de aslında güvenlik açısından bilinçli bir tercihtir. 90 günlük geçerlilik, sızdırılan bir özel anahtarın kötüye kullanılabileceği pencereyi daraltır ve herkesi otomasyona zorlar. İnsan eliyle üç ayda bir sertifika yenilemek sürdürülebilir değildir; bu yüzden Certbot en baştan otomatik çalışacak şekilde tasarlanmıştır.

Certbot, yenilemeyi son güne bırakmaz. certbot renew komutu çalıştığında, kurulu her sertifikayı tek tek kontrol eder ve yalnızca son kullanma tarihine 30 günden az kalanları yeniler. Yani 90 günlük bir sertifika pratikte 60. gününde tazelenir ve elinizde her zaman en az 30 günlük bir tampon kalır. Bu davranış sayesinde otomasyonunuz günde birkaç kez bile çalışsa gereksiz yere sunucuyu ya da Let's Encrypt sunucularını yormaz; süresi dolmaya yaklaşmayan sertifikalara dokunmaz.

Buradaki temel kural şudur: yenileme görevini günde iki kez çalışacak biçimde kurun, ama işin gerçekten "yenileme" kararını Certbot'a bırakın. Görev sık çalışır, sertifika ise yalnızca gerektiğinde değişir. Böylece bir gün sunucunuz kapalı olsa ya da bir yenileme başarısız olsa bile, kalan 30 günlük pencere içinde defalarca deneme şansınız olur.

Certbot systemd Timer ile Otomatik Yenileme#

Snap ile ya da güncel dağıtım depolarından kurulan Certbot, kurulum anında otomatik yenilemeyi sizin için zaten ayarlar. Modern sistemlerde bu iş bir systemd timer ile yapılır; ayrı bir cron satırı eklemenize gerek yoktur. Kurulumdan hemen sonra timer'ın etkin olup olmadığını kontrol edin:

sudo systemctl list-timers | grep certbot

Çıktıda certbot.timer satırını ve bir sonraki çalışma zamanını (NEXT) görüyorsanız otomasyon devrededir. Timer görünmüyorsa ya da devre dışıysa şu komutla etkinleştirin:

sudo systemctl enable --now certbot.timer
sudo systemctl status certbot.timer

Timer'ın hangi hizmeti tetiklediğini ve ne sıklıkta çalıştığını merak ediyorsanız birim dosyalarına bakabilirsiniz. Standart kurulumda timer günde iki kez, rastgele bir gecikmeyle çalışacak şekilde tanımlıdır:

# /lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

Buradaki RandomizedDelaySec=43200 satırı kritiktir: yenileme isteklerini 12 saatlik bir pencereye rastgele dağıtarak, dünyadaki tüm sunucuların aynı saniyede Let's Encrypt'e yüklenmesini engeller. Persistent=true ise sunucu planlanan çalışma anında kapalıydıysa, açılışta kaçırılan görevi telafi eder. Bu iki ayar, "gece 03.00'te yenilenmesi gerekiyordu ama sunucu kapalıydı" türü sorunları büyük ölçüde ortadan kaldırır.

Timer'ın tetiklediği hizmeti elle çalıştırıp gerçekten sorunsuz döndüğünü görmek için prova (dry run) modunu kullanın. Bu mod, gerçek bir sertifika üretmeden yenileme sürecinin tüm adımlarını canlıya birebir benzer şekilde dener:

sudo certbot renew --dry-run

Çıktının sonunda her alan adı için success ifadesini görüyorsanız otomatik yenileme sağlıklı çalışıyor demektir. Bu komutu yılda bir iki kez, özellikle sunucuda büyük değişikliklerden (web sunucusu yükseltmesi, port değişikliği, dizin taşıma) sonra çalıştırmayı alışkanlık hâline getirin.

Cron ile Yenileme (Alternatif)#

systemd kullanmayan eski sistemlerde ya da timer'ı devre dışı bırakıp yenilemeyi kendiniz yönetmek istediğinizde klasik cron yöntemine başvurabilirsiniz. Bunun için kök kullanıcının crontab'ına bir satır eklemeniz yeterlidir:

sudo crontab -e

Açılan dosyaya, yenilemeyi günde iki kez çalıştıracak ve tüm sunucuların aynı ana yığılmasını önlemek için rastgele bir gecikme ekleyecek şu satırı yazın:

# Certbot: her gün 03:17 ve 15:17'de, 0-3600 sn arası rastgele gecikmeyle yenile
17 3,15 * * * root sleep $((RANDOM \% 3600)) && certbot renew --quiet

--quiet bayrağı, yapacak bir iş olmadığında (yani hiçbir sertifikanın yenilenmesine gerek yokken) gereksiz e-posta ve çıktı üretilmesini engeller. Sadece gerçek bir hata olduğunda cron size mail gönderir. Cron'un mantığını, özel zamanlama ifadelerini ve sleep ile rastgele gecikme numaralarını daha derinlemesine öğrenmek isterseniz Linux cron görevleri rehberimiz konuyu baştan sona ele alıyor.

Önemli bir uyarı: systemd timer ile cron'u aynı anda çalıştırmayın. İkisi birden etkinse yenileme günde dört kez denenir; bu bir zarar vermez ama gereksizdir ve log okumayı karıştırır. Cron satırı ekliyorsanız önce sudo systemctl disable --now certbot.timer ile timer'ı kapatın. İki yöntem arasındaki farkları şöyle özetleyebiliriz:

Kısacası modern bir sunucuda özel bir nedeniniz yoksa systemd timer'ı olduğu gibi bırakın; cron'u yalnızca timer'ın bulunmadığı ortamlarda tercih edin.

Yenileme Neden Başarısız Olur?#

Otomatik yenilemenin en tehlikeli yanı, sessizce başarısız olabilmesidir. Görev her gün düzgün çalışıyor gibi görünür, ta ki bir gün sertifikanın süresi dolana kadar. Başarısızlıkların büyük çoğunluğu birkaç klasik nedenden kaynaklanır ve hepsinin somut bir çözümü vardır.

80 portunun kapalı olması. Let's Encrypt'in en yaygın doğrulama yöntemi olan HTTP-01, alan adının sizin kontrolünüzde olduğunu 80 portu üzerinden bir dosya sunarak kanıtlar. İlk kurulumdan sonra bir güvenlik duvarı kuralı ya da bir bulut sağlayıcı ayarı 80 portunu kapatırsa, siteniz 443 üzerinden çalışmaya devam ettiği için kimse fark etmez; ama yenileme sessizce çöker. Portun açık olduğunu doğrulayın:

sudo ufw status | grep 80
sudo ss -tlnp | grep ':80'

80 portu kapalıysa sudo ufw allow 80/tcp ile açın. Sunucuda gerçekten web sunucusu 80 portunu dinlemiyorsa (örneğin yalnızca HTTPS'e izin veren bir yapı), HTTP-01 yerine DNS-01 doğrulamasına geçmeniz gerekir.

Webroot dizininin değişmesi. --webroot yöntemiyle sertifika aldıysanız, Certbot doğrulama dosyasını belirttiğiniz dizinin altındaki .well-known/acme-challenge/ klasörüne bırakır. Zamanla siteyi başka bir dizine taşır, sanal sunucu (virtual host) kök yolunu değiştirir ya da uygulamayı yeni bir yola kurarsanız, kayıtlı webroot artık web sunucusunun servis ettiği dizinle örtüşmez ve doğrulama başarısız olur. Her sertifikanın kayıtlı yapılandırmasını inceleyin:

sudo cat /etc/letsencrypt/renewal/ornek.com.conf

Bu dosyadaki webroot_path satırı sitenizin gerçek kök diziniyle aynı olmalıdır. Yol değiştiyse dosyayı elle düzenlemek yerine, doğru yolu vererek bir kez yeniden alarak yapılandırmayı güncellemek daha güvenlidir:

sudo certbot certonly --webroot -w /var/www/yeni-dizin -d ornek.com -d www.ornek.com

Hız limitine takılmak. Let's Encrypt, kötüye kullanımı önlemek için haftalık sertifika üretim limitleri uygular. Bir hata yüzünden aynı alan adı için üst üste çok sayıda gerçek deneme yaparsanız geçici olarak engellenirsiniz. Bu yüzden bir sorunu ayıklarken her zaman --dry-run kullanın; prova modu hız limitlerini tüketmez. Ancak gerçek yenilemeye geçmeden önce sorunu prova modunda çözün.

DNS ve diğer nedenler. Alan adının A/AAAA kaydı sunucudan başka bir yeri gösteriyorsa (örneğin siteyi taşıdınız ama DNS'i eski IP'de bıraktınız) HTTP-01 doğrulaması yanlış sunucuya düşer. Yaygın başarısızlık nedenlerini ve çözümlerini şöyle toparlayabiliriz:

Bu tablodaki senaryoların çoğu tek bir alışkanlıkla önlenebilir: sunucuda web sunucusu, dizin ya da güvenlik duvarıyla ilgili büyük bir değişiklik yaptığınızda hemen sudo certbot renew --dry-run çalıştırıp yenilemenin hâlâ geçtiğinden emin olmak.

Yenileme Sonrası Reload Hook'u#

Certbot yenilemeyi başarıyla tamamladığında yeni sertifika dosyaları diske yazılır, ama web sunucusu belleğinde hâlâ eski sertifikayı tutmaya devam eder. Nginx ya da Apache yeniden yüklenmediği sürece ziyaretçilere hâlâ eski, hatta süresi dolmuş sertifika sunulur. Bu yüzden yenileme sonrası bir deploy hook ile web sunucusunu otomatik yeniden yüklemek şarttır.

En temiz yöntem, hook betiklerini Certbot'un özel dizinine koymaktır. /etc/letsencrypt/renewal-hooks/deploy/ altına konan her çalıştırılabilir betik, yalnızca gerçekten bir sertifika yenilendiğinde çalışır; boşuna her kontrol denemesinde değil. Nginx için:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'EOF'
#!/bin/sh
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Betiğin içindeki nginx -t kontrolü kritiktir: yapılandırmada bir hata varsa reload çalışmaz ve çalışan siteniz çökmez. Apache kullanıyorsanız aynı mantıkla apachectl configtest && systemctl reload apache2 satırını kullanabilirsiniz.

Alternatif olarak hook'u tek bir sertifikaya özgü kılmak isterseniz, ilk alma komutunda --deploy-hook bayrağını verebilirsiniz. Certbot bu değeri o sertifikanın renewal/*.conf dosyasına kaydeder ve her yenilemede otomatik uygular:

sudo certbot certonly --webroot -w /var/www/ornek -d ornek.com \
  --deploy-hook "systemctl reload nginx"

Nginx tarafında sertifika yollarının /etc/letsencrypt/live/ornek.com/ altındaki sembolik bağlantıları göstermesi de önemlidir. Bu live yolu her zaman en güncel sertifikaya işaret ettiği için, yenileme sonrası yapılandırmada hiçbir şey değiştirmenize gerek kalmaz; sadece reload yeterlidir:

server {
    listen 443 ssl;
    server_name ornek.com www.ornek.com;

    ssl_certificate     /etc/letsencrypt/live/ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ornek.com/privkey.pem;

    # ... uygulamanızın diğer ayarları ...
}

Deploy hook'unu kurduktan sonra bir kez sudo certbot renew --dry-run çalıştırın. Prova modu deploy hook'larını gerçek yenilemede olduğu gibi tetiklemez, ama hook betiğinin sözdiziminde bir hata varsa yine de erken uyarı alırsınız. En sağlam test, sertifikaya --force-renewal ile gerçekten dokunup reload'un çalıştığını görmektir; ancak bu gerçek bir yenileme sayıldığı için hız limitini göz önünde bulundurarak dikkatli kullanın.

Süre Uyarı E-postaları ve İzleme#

Otomasyon ne kadar sağlam olursa olsun, bir güvenlik ağına ihtiyacınız vardır: yenileme bir şekilde başarısız olursa, sertifika süresi dolmadan önce haberdar olmalısınız. Bunun birden fazla katmanı vardır.

Let's Encrypt'in kendi uyarıları. İlk sertifikayı alırken bir e-posta adresi verdiyseniz, Let's Encrypt sertifikanız süresi dolmaya yaklaşırken (yaklaşık 20 ve 10 gün kala) sizi otomatik olarak uyaran e-postalar gönderir. Bu adresi güncel tutun ve verdiğiniz kutuyu gerçekten takip ettiğinizden emin olun. Kayıtlı e-postayı değiştirmek için:

sudo certbot update_account --email [email protected]

Kendi izleme betiğiniz. Let's Encrypt'in e-postalarına tamamen bağımlı kalmak yerine, sunucuda çalışan basit bir kontrol betiği daha güvenlidir; çünkü hem süreyi hem de web sunucusunun gerçekten sunduğu sertifikayı denetler. Aşağıdaki betik, canlı bağlantı üzerinden sertifikanın kaç gün sonra biteceğini ölçer ve eşik altındaysa uyarır:

#!/bin/sh
# kalan-gun-kontrol.sh — SSL bitişine 20 günden az kaldıysa mail at
DOMAIN="ornek.com"
ESIK=20
BITIS=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
BITIS_TS=$(date -d "$BITIS" +%s)
SIMDI_TS=$(date +%s)
KALAN=$(( (BITIS_TS - SIMDI_TS) / 86400 ))
if [ "$KALAN" -lt "$ESIK" ]; then
  echo "$DOMAIN sertifikasina $KALAN gun kaldi!" | mail -s "SSL uyarisi: $DOMAIN" [email protected]
fi

Bu betiği günde bir kez cron ile çalıştırın; yenileme çalışırken ölçtüğü değer düşmüyorsa gerçek bir sorun var demektir:

# Her sabah 07:00'de SSL süre kontrolü
0 7 * * * /usr/local/bin/kalan-gun-kontrol.sh

Harici izleme. En sağlam katman, sunucu çökse bile çalışan sunucu dışı bir izlemedir. Uptime Kuma gibi bir araç sitenizin SSL süresini uzaktan izleyip Telegram ya da e-posta ile uyarır; yapılandırması basit bir bildirim tanımından ibarettir:

monitor:
  name: ornek.com SSL
  type: http
  url: https://ornek.com
  certExpiryNotification: true
  certExpiryDays: 21   # 21 gün kala uyar

Bu üç katman birlikte kullanıldığında, yenilemenin tek bir noktada sessizce başarısız olması bile fark edilir hâle gelir. Clou.TR paketlerinde barındırılan siteler için sürekli erişilebilirlik ve SSL süre takibini panelinizden yönetebilir, sunucu tarafında bu betikleri kurmak istemediğinizde sunucu yönetimi hizmetimizle işi bize bırakabilirsiniz.

Paylaşımlı Hosting'te Durum Farklı mı?#

Buraya kadar anlattığımız her şey, kök erişiminiz olan bir VPS ya da sunucu içindir. Paylaşımlı hosting ya da cPanel kullanıyorsanız işiniz çok daha kolaydır: sertifika yenileme zaten sizin adınıza sunucu tarafından yapılır. cPanel'in AutoSSL özelliği, hesabınızdaki alan adları için ücretsiz sertifikaları otomatik alır ve süresi dolmadan yeniler; sizin cron ya da timer kurmanıza gerek kalmaz.

Bu durumda size düşen tek şey, alan adının sunucuya doğru yönlendirildiğinden ve DNS kaydının doğru IP'yi gösterdiğinden emin olmaktır. AutoSSL yalnızca sunucuya çözümlenen alan adları için sertifika üretebilir; alan adı başka bir yeri gösteriyorsa doğrulama başarısız olur ve panelde "SSL yok" uyarısı görürsünüz. Clou.TR'nin paylaşımlı hosting paketlerinde SSL kurulum ve yenilemesi otomatik çalışır; WordPress kullanıcıları için WordPress hosting tarafında da aynı otomasyon geçerlidir. Kendi sunucunuzu yönetiyorsanız ve trafiğinizi ek olarak katmanlı korumaya almak istiyorsanız WAF ve SSL çözümlerimize göz atabilirsiniz.

Sıkça Sorulan Sorular#

Sertifikamın süresi doldu, ne yapmalıyım?#

Öncelikle paniğe kapılmadan sudo certbot renew --force-renewal komutunu çalıştırın; bu, süreye bakmadan hemen yeni bir sertifika almaya zorlar. Komut hata veriyorsa neredeyse her zaman 80 portu ya da webroot yolu kaynaklıdır; bu rehberdeki "Yenileme Neden Başarısız Olur?" bölümündeki kontrolleri sırasıyla uygulayın. Yeni sertifika alındıktan sonra web sunucusunu systemctl reload nginx ile yeniden yüklemeyi unutmayın, aksi halde tarayıcı hâlâ eski sertifikayı görür.

certbot renew çalışıyor ama sertifika neden yenilenmiyor?#

Bu aslında bir hata değildir. certbot renew yalnızca son kullanma tarihine 30 günden az kalan sertifikaları yeniler; henüz o eşiğe gelmemiş bir sertifika için "not yet due for renewal" mesajı vererek hiçbir şey yapmaz. Yenilemenin gerçekten çalışacağından emin olmak istiyorsanız sudo certbot renew --dry-run komutunu kullanın; bu prova modu, süreye bakmaksızın tüm süreci gerçek yenilemeye birebir benzer şekilde dener.

systemd timer mı cron mu kullanmalıyım?#

Modern bir Ubuntu, Debian ya da Rocky Linux sunucusunda özel bir nedeniniz yoksa systemd timer'ı kullanın; Certbot kurulumuyla birlikte hazır gelir, kaçırılan görevleri açılışta telafi eder ve loglaması merkezidir. Cron yalnızca systemd bulunmayan eski sistemlerde ya da yenileme zamanlamasını tamamen kendiniz kontrol etmek istediğinizde mantıklıdır. Her iki yöntemi aynı anda etkin bırakmayın; biri yeterlidir ve ikisi birden çalışırsa loglar gereksiz yere karışır.

Yenileme sonrası neden reload gerekiyor?#

Çünkü Nginx ve Apache, sertifikayı başlangıçta belleğe yükler ve çalışırken diskteki yeni dosyaları kendiliğinden okumaz. Certbot yeni sertifikayı diske yazsa bile, web sunucusu yeniden yüklenmediği sürece ziyaretçilere hâlâ eski sertifikayı sunmaya devam eder. Bu yüzden /etc/letsencrypt/renewal-hooks/deploy/ altına bir reload betiği koymak ya da alma komutunda --deploy-hook kullanmak zorunludur; aksi halde yenileme başarılı olur ama kullanıcılar bunu göremez.

Prova (dry run) modu hız limitini tüketir mi?#

Hayır, --dry-run tüm süreci Let's Encrypt'in test (staging) sunucularına karşı çalıştırır ve üretim hız limitlerinden hiçbirini tüketmez. Tam da bu yüzden bir sorunu ayıklarken her zaman önce prova modunu kullanmalısınız. Gerçek certbot renew komutunu bir hatayı çözmeden defalarca tekrarlarsanız haftalık üretim limitine takılır ve geçici olarak yeni sertifika alamaz hâle gelirsiniz; prova modu bu riski tamamen ortadan kaldırır.

DNS doğrulaması otomatik yenilenebilir mi?#

Evet, ancak 80 portunu kullanan HTTP-01'in aksine DNS-01 doğrulaması, yenileme anında alan adınızın TXT kaydını otomatik değiştirebilmeyi gerektirir. Bunun için DNS sağlayıcınızın API'sini destekleyen bir Certbot eklentisi (örneğin Cloudflare için certbot-dns-cloudflare) kurar ve kimlik bilgilerini bir dosyada saklarsınız. Böyle kurulduğunda systemd timer ya da cron, wildcard sertifikaları dahil her şeyi elle müdahale olmadan yeniler.

Kapanış#

SSL otomatik yenilemesi, bir kez doğru kurulduğunda yıllarca sizden habersiz çalışan, "kur ve unut" mantığında bir sistemdir; ama bu "unutma" ancak üç ayağı sağlam kurulduğunda güvenlidir. Birincisi, yenilemeyi çalıştıran bir mekanizma (tercihen systemd timer, alternatif olarak cron). İkincisi, yeni sertifikayı devreye alan bir deploy hook ile web sunucusunun otomatik yeniden yüklenmesi. Üçüncüsü ise bir şeyler ters gittiğinde sizi süre dolmadan uyaran bir bildirim katmanı. Bu üçünü birden kurduğunuzda, gece yarısı süresi dolan bir sertifikanın yol açtığı o klasik krizi bir daha yaşamazsınız.

Bu adımları kendiniz kurmak istiyorsanız VDS sunucu ve sunucu çözümlerimiz tam size göre. Bakım, izleme ve SSL yenilemeyi uzman bir ekibe bırakmayı tercih ederseniz sunucu yönetimi hizmetimiz devreye girer. SSL hiç düşünmeden otomatik çalışsın istiyorsanız da AutoSSL'in hazır geldiği Clou.TR hosting paketlerine göz atın; Clou.TR ile sertifikanız her zaman güncel, siteniz her zaman kilitli kalır.