EN
← Bloga dönRehberler

SSL Sertifikası Süresi Doldu: Ne Yapmalı, Nasıl Önlenir?

SSL sertifikası süresi doldu uyarısı ne yapmalı? openssl ile teşhis, yenileme, zincirin doğru kurulması, sunucunun yeniden yüklenmesi ve otomatik yenileme.

Yayınlanma: · 5 dk okuma

Süresi dolmuş bir sertifika, bir siteyi çökmüş bir sunucu kadar etkili biçimde erişilmez kılar. Tarayıcılar tam sayfa uyarı gösterir (Chrome'da NET::ERR_CERT_DATE_INVALID, Firefox'ta SEC_ERROR_EXPIRED_CERTIFICATE); site HSTS kullanıyorsa "yine de devam et" bağlantısı bile çıkmaz. API istemcileri, mobil uygulamalar, webhook'lar ve ödeme geri çağrıları ise doğrudan hata verir. Bu rehber, SSL sertifikası süresi dolduğunda ilk yarım saatte ne yapmanız gerektiğini ve aynı şeyin tekrar yaşanmaması için neleri kurmanız gerektiğini anlatıyor.

1. adım — Sorunun gerçekten ne olduğunu doğrulayın

Her tarih hatası, sunucunuzdaki sertifikanın süresinin dolduğu anlamına gelmez. Saatine güvendiğiniz bir makineden kontrol edin:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
subject=CN = example.com
issuer=C = XX, O = Example CA, CN = Example CA R3
notBefore=Jun 20 08:00:00 2026 GMT
notAfter=Sep 18 08:00:00 2026 GMT

notAfter geçmişteyse teşhis doğrudur. Benzer görünen ama farklı olan durumlar:

  • İstemcinin saati yanlış. Pili bitmiş, kendini 2019'da sanan bir dizüstü her sertifikayı reddeder. Hatayı tek bir ziyaretçi bildiriyorsa önce saatini sorun.
  • Yaprak sertifika sağlamken sunucunun gönderdiği zincirdeki ara sertifikanın süresi dolmuş.
  • Birkaç sunucudan yalnızca birinde eski sertifika kalmış. Yük dengeleyici ya da CDN arkasında her düğümü, ayrıca kenar (edge) ile kaynak sunucuyu ayrı ayrı kontrol edin.
  • Aynı addaki başka bir hizmet. 443 yenilenmiş ama posta tarafı (:465, :993, STARTTLS ile :587) hâlâ eski dosyayı kullanıyor:
$ openssl s_client -connect mail.example.com:587 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

-servername seçeneği önemlidir: SNI olmadan birçok sunucu, tarayıcıların gördüğünden farklı bir varsayılan sertifika döndürür.

2. adım — Sertifikayı nasıl aldıysanız öyle yenileyin

ACME (Let's Encrypt ve benzerleri)

Sertifikanın kendiliğinden yenilenmiş olması gerekirdi; neden yenilenmediğini bulun.

$ sudo certbot certificates          # certbot'un bildiği sertifikalar ve bitiş tarihleri
$ sudo certbot renew --dry-run       # yenileme yolunu test et
$ sudo certbot renew                 # zamanı gelenleri yenile
$ systemctl list-timers | grep -i certbot

Olağan nedenler: sunucu taşındıktan sonra zamanlayıcı ya da cron görevi kurulmamıştır; 80 numaralı port kapalıdır ya da HTTP-01 doğrulamasını bozan bir yönlendirme vardır; DNS-01 için kullanılan API anahtarı değiştirilmiştir; bir AAAA kaydı doğrulamaya yanıt vermeyen bir makineyi gösteriyordur; kısıtlayıcı bir CAA kaydı ilgili CA'yı içermiyordur; ya da alan adı artık bambaşka bir sunucuya bakıyordur.

Ticari bir CA'dan alınmış sertifika

  1. Yeni bir anahtar ve CSR üretin. Alışkanlıkla eski anahtarı kullanmayın.
$ openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.com.key -out example.com.csr \
    -subj "/CN=example.com" \
    -addext "subjectAltName=DNS:example.com,DNS:www.example.com"
  1. CSR'ı gönderin, alan adı doğrulamasını (e-posta, DNS kaydı ya da HTTP dosyası) tamamlayın, sertifikayı ara sertifika zinciriyle birlikte indirin.
  2. İhtiyacınız olan her adı SAN alanına yazın. example.com, www.example.com adını kapsamaz; *.example.com joker sertifikası da ne çıplak alan adını ne a.b.example.com adını kapsar.

Hosting firması, CDN ya da yük dengeleyici yönetiyorsa

Sağlayıcının paneline bakın. Yönetilen sertifikalar genellikle tek bir nedenle yenilenemez: alan adı artık doğrulanamıyordur. Sağlayıcıya bakan DNS kaydı değiştirilmiş, doğrulama için gereken CNAME silinmiş ya da bir CAA kaydı sağlayıcının CA'sını engelliyordur.

3. adım — Tam zincirle kurun

Sunucu, yaprak sertifikayı ve ardından ara sertifika(ları) göndermelidir; kök sertifika gönderilmez. Certbot'ta bu fullchain.pem dosyasıdır:

# nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Eksik ara sertifika sinsidir: masaüstü tarayıcılar ara sertifikaları kendileri indirerek ya da önbellekten tamamlayarak sorunu örtebilir; curl, Android uygulamaları ve diğer sunucular ise hata verir. Katı bir istemciyle sınayın:

$ curl -sSI https://example.com >/dev/null && echo zincir tamam

Sertifika ile anahtarın birbirine ait olduğunu doğrulayın:

$ openssl x509 -noout -pubkey -in fullchain.pem | openssl sha256
$ openssl pkey -pubout -in privkey.pem | openssl sha256

İki özet birebir aynı olmalıdır.

4. adım — Hizmeti yeniden yükleyin

"Yeniledim ama hâlâ süresi dolmuş görünüyor" şikâyetinin en yaygın nedeni: web sunucusu eski sertifikayı bellekte tutuyordur.

$ sudo nginx -t && sudo systemctl reload nginx
$ sudo apachectl configtest && sudo systemctl reload apache2

ACME istemcilerinde yeniden yüklemeyi yenilemenin parçası yapın: certbot renew --deploy-hook "systemctl reload nginx". Aynısını Postfix, Dovecot, HAProxy ve dosyayı okuyan diğer her şey için de kurun.

5. adım — Dışarıdan doğrulayın

  1. adımdaki openssl s_client komutunu tekrarlayıp yeni notAfter değerine bakın. Ardından şunları kontrol edin:
  • hem example.com hem www.example.com, kullanılan diğer adlar
  • ikisini de yayınlıyorsanız IPv4 ve IPv6 ayrı ayrı (openssl s_client -4 / -6)
  • yük dengeleyicinin arkasındaki her düğüm
  • posta ve diğer TLS portları

Tarayıcılar açık bağlantıyı bir süre tutabilir; "olmadı" demeden önce yeni bir gizli pencerede deneyin.

Bu neden sürekli yaşanıyor? Sertifika ömürleri kısalıyor

Herkese açık güvenilir sertifikaların ömrü Eylül 2020'den beri en fazla 398 gün; Let's Encrypt ise baştan beri 90 günlük sertifika veriyor. CA/Browser Forum, Nisan 2025'te azami süreyi daha da düşüren bir takvimi kabul etti: 15 Mart 2026'dan itibaren 200 gün, 15 Mart 2027'den itibaren 100 gün, 15 Mart 2029'dan itibaren 47 gün. Tamamlanmış bir alan adı doğrulamasının yeniden kullanılabildiği süre de kısalıyor.

Pratik anlamı şu: takvime not alıp yılda bir kez elle yenilemek, son kullanma tarihi olan bir yöntemdir. 47 günlük sertifikaları kimse elle yenilemez. Ayrıca Let's Encrypt 2025'te bitiş uyarısı e-postalarını göndermeyi bıraktı; o güvenlik ağı da artık yok.

Önleme listesi

  • Platformun izin verdiği her yerde düzenlemeyi ve yenilemeyi ACME ile otomatikleştirin. Birçok ticari CA da ACME destekliyor.
  • Erken yenileyin. ACME istemcileri varsayılan olarak ömrün yaklaşık üçte biri kala yeniler; bu, bir hatayı fark etmek için haftalar bırakır.
  • Yenileme mekanizmasından bağımsız olarak dışarıdan izleyin. Kontrol, diskteki dosyaya değil, sunucunun sunduğu sertifikaya bakmalıdır. 21, 14 ve 7 gün kala uyarı alın.
  • Her uç noktanın envanterini çıkarın: alt alan adları, posta sunucuları, VPN geçitleri, iç araçlar, CDN'in arkasındaki kaynak sunucu. Süresi dolan, hep unutulan olur.
  • Deploy hook'u test edin. Yeniden yükleme olmadan yapılan yenileme, yalnızca ertelenmiş bir kesintidir.
  • Doğrulamayı çalışır tutun: HTTP-01 için 80 numaralı port erişilebilir, DNS-01 için API anahtarı geçerli, CAA kayıtları kullandığınız CA'ları içeriyor olsun.
  • Uyarılar tek kişinin posta kutusuna değil, ekip adresine gitsin.

Sık yapılan hatalar

  • Sertifikayı yenileyip sunucuyu yeniden yüklememek.
  • Yaprak sertifikayı ara sertifika olmadan kurmak.
  • SAN listesinde www adını ya da çıplak alan adını unutmak.
  • CDN'deki sertifikayı yenilerken kaynak sunucudaki sertifikanın sessizce dolması; CDN'in çalışma biçimine göre bu, tarayıcı uyarısı yerine kenardan dönen 5xx hataları olarak görünür.
  • Kullanıcılara uyarıyı geçmelerini söylemek. Bu, saldırganların güvendiği alışkanlığın ta kendisini öğretir.
  • Bir API istemcisinde sertifika doğrulamasını "geçici olarak" kapatmak.
  • Asıl neden kullanıcıları başka bir sunucuya gönderen bir DNS değişikliğiyken sertifika sorunu sanmak. Sunulan sertifika başkasına aitse önce adın nereyi gösterdiğine bakın.

OrbitProbe ile kontrol edin

OrbitProbe SSL sorgulama aracı sunucunuza bağlanır ve gerçekten sunulan sertifikayı raporlar: düzenleyen kurum, geçerlilik tarihleri ve kalan gün, kapsanan adlar, anlaşılan TLS protokolü, zincirin güvenilir olup olmadığı ve HSTS. Her yenilemeden sonra bir kez çıplak alan adı, bir kez www için çalıştırın. Aynı olayda e-posta da etkilendiyse mailler spam'e düşüyor: DNS kontrol listesi yazısı posta teslimatının TLS ve DNS tarafını anlatıyor.