SSL sertifikasının süresi doldu: beş dakikada teşhis, kalıcı çözüm

"Bu bağlantı gizli değil", NET::ERR_CERT_DATE_INVALID, "sertifikanın süresi dolmuş". Bu uyarılardan biri sitenizde çıktıysa iki iş var: önce siteyi hızla düzeltmek, sonra bunun neden olduğunu bulup kalıcı olarak kapatmak. Otomatik yenileme çağında süresi dolan sertifika neredeyse her zaman bir otomasyon arızasıdır; arızayı bulmadan yapılan elle yenileme, aynı sabaha üç ay sonra tekrar uyanmak demektir.

Önce emin olun: sorun gerçekten sertifikada mı?

Hata yalnız sizin bilgisayarınızda mı, yoksa herkeste mi? Tek bir cihazda görülen tarih hatasının en sık sebebi o cihazın saatidir. Telefonunuzdan ve başka bir ağdan da açmayı deneyin. Herkeste görülüyorsa sunucunun gönderdiği sertifikanın bitiş tarihine doğrudan bakın:

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

notAfter satırı bitiş tarihidir ve UTC ile yazılır. Komut satırına erişiminiz yoksa aynı bilgiyi SSL sertifika kontrolü aracıyla da görebilirsiniz. Bu adımın önemi şudur: sunucunun gönderdiği tarih ile diskteki sertifikanın tarihi farklı olabilir. Aşağıdaki teşhisin yarısı bu farka dayanır.

Acil çözüm: şimdi yenileyin

Let's Encrypt ve certbot kullanan bir sunucuda önce durumu görün:

certbot certificates

Deneme sunucumuzda çıktı şöyleydi:

  Certificate Name: 45-131-198-151.sslip.io
    Expiry Date: 2027-01-15 15:16:47+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/45-131-198-151.sslip.io/fullchain.pem

Süresi dolmuşsa VALID yerine EXPIRED görürsünüz. Yenilemeyi elle tetikleyin:

certbot renew --cert-name ornek.com

Komut başarılı olursa site birkaç saniye içinde düzelir. Başarısız olursa çıktıdaki hata mesajı, aşağıdaki dört halkadan hangisinin koptuğunu söyler. Paneli olan bir paylaşımlı hostingdeyseniz bu işi panelin SSL bölümündeki yeniden çalıştır düğmesi yapar; yine de aşağıdaki sebepler sizin için de geçerlidir.

Otomatik yenileme dört halkadan oluşur

Yenileme tek bir olay değil, art arda çalışması gereken dört adımdır. Sertifikanın süresi dolduysa bunlardan biri kopmuştur:

1. Zamanlayıcı çalışıyor mu? Certbot'u bir şeyin düzenli çağırması gerekir.
2. Doğrulama geçiyor mu? Sertifika otoritesi alan adının hâlâ sizde olduğunu sınar.
3. Yeni sertifika diske yazılıyor mu?
4. Web sunucusu yeni sertifikayı yüklüyor mu?

1. Zamanlayıcı

Ubuntu paketinden kurulan certbot, systemd zamanlayıcısı getirir. Çalıştığını ve bir sonraki çalışma zamanını görün:

systemctl list-timers --no-pager | grep -i certbot
systemctl cat certbot.timer | grep -E 'OnCalendar|Randomized'

Bizim kurulumumuzda zamanlayıcı günde iki kez (00:00 ve 12:00) tetikleniyor ve RandomizedDelaySec=43200 ile bu saatlere 12 saate kadar rastgele gecikme ekliyor; böylece dünyadaki tüm sunucular aynı anda sertifika otoritesine yüklenmiyor. Snap ile kurulan certbot'ta zamanlayıcının adı snap.certbot.renew.timer olur. Sunucu yıllar önce kurulduysa ve yenileme bir cron satırına bırakıldıysa, crontab -l ve /etc/cron.d/ altına da bakın; taşıma sırasında kaybolan cron satırları süresi dolan sertifikaların klasik sebebidir.

2. Doğrulama: en sık kopan halka

HTTP-01 doğrulamasında sertifika otoritesi internetten sunucunuzun 80 portuna bağlanıp geçici bir dosyayı okur. Sunucuyu ilk kurduğunuzda 80 açıktı; sonra güvenlik duvarını "yalnız HTTPS" diye sıkılaştırdıysanız ilk yenileme 60 gün sonra sessizce başarısız olur. Bunu deneme sunucumuzda bilerek yaptık: 80 portunu kapatıp yenilemeyi prova ettik. Certbot'un cevabı açıktı:

  Domain: 45-131-198-151.sslip.io
  Type:   connection
  Detail: 45.131.198.151: Fetching http://45-131-198-151.sslip.io/.well-known/acme-challenge/...:
          Timeout during connect (likely firewall problem)
Failed to renew certificate 45-131-198-151.sslip.io with error: Some challenges have failed.

Type satırını okuyun, çünkü sebebi o söyler:

• connection / Timeout during connect — 80 portuna ulaşılamıyor. Güvenlik duvarında 80'i açın; HTTP'den HTTPS'e yönlendirme yapıyorsanız bu sorun değildir, ama /.well-known/acme-challenge/ yolunun bir uygulama kuralıyla engellenmediğinden emin olun.
• dns — alan adının DNS kaydı bu sunucuyu göstermiyor. Sunucu taşındıysa ya da IP değiştiyse A ve AAAA kayıtlarını kontrol edin. AAAA kaydı olup da IPv6'sı çalışmayan sunucular, sertifika otoritesi IPv6'yı tercih ettiği için sık takılır.
• unauthorized — doğrulama dosyası okunmuş ama içerik yanlış. Genellikle istek başka bir sunucuya (eski sunucu, bir CDN) gidiyordur.

80 portunu tekrar açtığımızda aynı prova şu satırla bitti:

certbot renew --dry-run --no-random-sleep-on-renew
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/45-131-198-151.sslip.io/fullchain.pem (success)

3 ve 4. Yazıldı ama yüklenmedi

En kafa karıştırıcı durum şudur: certbot certificates sertifikanın geçerli olduğunu söyler, ama tarayıcı süresinin dolduğunu söyler. Sebep, yeni dosyanın diske yazılması ama web sunucusunun eski sertifikayı bellekte tutmaya devam etmesidir. Bunu yakalamak için iki tarihi yan yana koyun:

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

Deneme sunucumuzda iki tarih de 15 Ocak 2027'yi gösterdi; çünkü sertifika nginx eklentisiyle alınmıştı ve yenileme yapılandırmasında installer = nginx satırı vardı. Bu satır, yenilemeden sonra nginx'in kendiliğinden yeniden yüklenmesini sağlar. Sertifika --standalone ya da --webroot ile alındıysa yükleme kendiliğinden olmaz; bir kanca ekleyin:

printf '#!/bin/sh\nsystemctl reload nginx\n' > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx
chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx

deploy dizinindeki betikler yalnız sertifika gerçekten yenilendiğinde çalışır. Aynı sertifikayı bir posta sunucusu, bir veritabanı ya da bir yük dengeleyici de kullanıyorsa her birini bu betiğe ekleyin; web sitesi düzelir ama e-posta istemcileri sertifika hatası vermeye devam ederse sebep budur.

Sertifika Let's Encrypt değil, satın alınmışsa

Ücretli sertifikalar genellikle bir yıl geçerlidir ve otomatik yenilenmez. Yenileme üç adımdır: sağlayıcıdan yeni bir sertifika isteği (CSR) ile sertifikayı yeniden çıkarmak, gelen sertifikayı ve ara sertifika paketini sunucuya kurmak, servisi yeniden yüklemek. Yeni sertifikayı kurarken ara sertifikaları unutmak, süresi dolmuş sertifikadan sonra gelen ikinci en sık hatadır; kurulumdan sonra zinciri SSL sertifikası rehberindeki komutla kontrol edin.

CDN arkasındaki sitede süresi dolan sertifika

Siteniz bir CDN ya da koruma hizmetinin arkasındaysa ziyaretçi iki ayrı sertifikayla karşılaşır: CDN'in kenar sunucusunun gösterdiği sertifika ve CDN'in sizin sunucunuza bağlanırken gördüğü kaynak sertifikası. Kenar sertifikasını çoğu zaman CDN kendisi yeniler; süresi dolan genellikle kaynak sunucudaki sertifikadır. Bu durumda tarayıcı klasik "süresi dolmuş" uyarısını göstermez. Örneğin Cloudflare kendi hata sayfasında 526 (Invalid SSL certificate) kodunu gösterir; CDN kaynakla güvenli bağlantı kuramamıştır.

Teşhis için kaynağa CDN'i atlayarak doğrudan bağlanın. Sunucunun gerçek IP adresini kullanın ve alan adını SNI olarak verin:

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

Buradaki tarih geçmişteyse yukarıdaki dört halka bu sunucu için geçerlidir. Kaynak sunucu doğrulamasını HTTP-01 ile yapıyorsanız CDN'in /.well-known/acme-challenge/ isteklerini önbelleğe almadan kaynağa ilettiğinden de emin olun.

Bir daha yaşamamak için

Otomasyonun var olması yetmez; çalıştığının dışarıdan izlenmesi gerekir. Üç önlem yeterlidir:

• Kurulumdan hemen sonra prova. certbot renew --dry-run gerçek sertifikaya dokunmadan doğrulamayı ve yazmayı sınar. Güvenlik duvarını, sunucuyu ya da DNS'i her değiştirdiğinizde provayı tekrarlayın.
• Bitiş tarihini dışarıdan izleyin. Sunucunun kendisi değil, başka bir makine her gün sertifikanın kalan süresine baksın. OpenSSL bunu tek komutla yapar ve 30 günden az kaldıysa sıfırdan farklı kodla çıkar:

  echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null \
    | openssl x509 -noout -checkend 2592000 || echo "30 günden az kaldı"

  Let's Encrypt sertifikası 30 gün kala yenilendiği için bu uyarının hiç gelmemesi gerekir; gelirse yenileme çalışmıyor demektir ve önünüzde hâlâ bir ay vardır.
• Sunucu saatini eşitleyin. timedatectl çıktısında System clock synchronized: yes görmelisiniz. Saati kaymış bir sunucu, sertifika otoritesiyle konuşurken de, kendi sertifikasını değerlendirirken de yanlış karar verir.

Bu yazıdaki teşhisin özeti tek cümledir: önce sunucunun gönderdiği tarihe bakın, sonra dört halkayı sırayla kontrol edin. Sertifikanın kendisi neredeyse hiçbir zaman sorunlu değildir; kopan halka bulunduğunda sorun kalıcı olarak kapanır.

Sık sorulan sorular