Rehber 12 Ağustos 2026 · 6 dakika okuma

SSL süresi neden 90 güne düşürüldü? Teknik ve pratik rehber

SSL/TLS sertifikalarında 90 günlük süreye geçişin teknik gerekçelerini, güvenlik etkilerini ve NetKıyas kullanıcıları için yönetim planını öğrenin.

SSL/TLS sertifikası neden 90 güne düşürüldü?

12.08.2026 itibarıyla TLS (Transport Layer Security) sertifikalarında yaygın uygulama, sertifika yaşam süresinin 90 gün ile sınırlanması yönünde ilerledi. Bu değişiklik haber niteliğinden çok operasyonel bir konudur: Sertifikanın ne zaman biteceğini planlamak, otomatik yenileme (auto-renewal) kurmak ve güvenli anahtar yönetimini doğru yapmak gerekir.

Bu yazıda şu soruları net cevaplayacağız:

  • 90 güne düşürme kararı güvenliği hangi yollarla artırıyor?
  • 90 gün ile “güvenlik artar” iddiası hangi teknik mekanizmalarla destekleniyor?
  • 90 günlük sertifikayı kullanan bir web sitesi/uygulama yöneticisi hangi somut adımları atmalı?

90 gün politikası güvenliği nasıl artırıyor?

TLS sertifikası, web tarayıcılarının sunucuya güvenmesini sağlayan kimlik doğrulama aracıdır. Sertifikanın içinde sertifika süresi, imza zinciri ve kriptografik anahtar bilgileri bulunur. Sertifika süresi uzadığında, bir saldırı ya da anahtar sızıntısı olasılığında saldırganın elindeki “kötü niyetli sertifikayı” daha uzun süre kötüye kullanma şansı artar.

90 güne düşürmenin temel güvenlik etkileri şunlardır:

1) Sızma/yanlış kullanım risk penceresini daraltır

Sertifikalar daha uzun süre geçerli olursa, saldırgan bir anahtarı ele geçirdiğinde ya da bir sertifika yanlışlıkla uzun süre açık kaldığında etkisi uzar. 90 gün yaklaşımı, “etkisi olabilecek süreyi” kısaltır. Bu doğrudan şu mantığa dayanır: Sertifikanın faydalı/zararlı etkisi, geçerlilik bitince otomatik olarak sona erer.

2) Anahtar rotasyonu (key rotation) pratik hale gelir

90 günlük süre, servis sahiplerini düzenli yenilemeye zorlar. Bu da anahtar rotasyonu disiplinini güçlendirir. Anahtar rotasyonu, kriptografik bileşenlerin uzun süre aynı kalmamasını hedefler.

3) Kripto kuralları ve algoritmalar daha hızlı güncellenir

TLS ekosisteminde algoritmalar ve kabul edilen kripto yöntemleri zamanla değişir. Sertifika yenileme döngüsü kısaldıkça, daha güncel konfigürasyonları uygulama şansı artar.

4) “Güncellemeleri kaçırma” hatasını azaltmayı hedefler

Operasyonlarda en sık hata, son kullanma tarihlerini kaçırmaktır. 90 günlük döngü, bu hatayı daha sık kontrol etmeyi teşvik eder; ancak bu aynı zamanda otomasyon gerektirir. Yani güvenlik artışı, otomasyon yapılmazsa tersine dönebilir.

90 gün kime yük getirir? En sık görülen sorunlar

90 günlük sertifika, teknik olarak “kurulum değişti” anlamına gelir; fakat pratikte sorunlar kurulumdan çok yenileme süreçlerinde çıkar.

En sık yaşanan 5 problem

  • Otomatik yenileme yoksa sertifika sonlanır ve site tarayıcıda uyarı vermeye başlar.
  • Kontrol paneli/CI/CD üzerinde sertifika yenileme akışı eksik kalır.
  • Load balancer (LB) veya reverse proxy (Nginx/Apache) katmanında sertifikayı farklı yerden kullanma nedeniyle uyumsuzluk oluşur.
  • Çoklu ortam (staging/production) için yenileme ayrı planlanmadığı için staging yenilenir, production yenilenmez.
  • Yenileme sonrası zincir (chain) doğru servis edilmez; bazı tarayıcılar ara sertifikaları eksik gördüğü için uyarı üretebilir.

Otomatik yenilemeyi nasıl planlamalısınız? (Net kontrol listesi)

Aşağıdaki kontrol listesi, sertifika süresi 90 gün olsa da yönetilebilirlik sağlar. Odak, “sertifika bitecek mi?” sorusunu “bitecekse bile sistemim bunu otomatik toparlayacak mı?” seviyesine taşımaktır.

1) Otomasyon var mı? (Auto-renewal kontrolü)

Sertifika kaynağına göre yöntem değişir:

  • ACME tabanlı sağlayıcılar (Let’s Encrypt gibi) için tipik yaklaşım: cron/systemd timer ile yenileme komutu.
  • Bulut/hosting kontrol panellerinde: genellikle “SSL yönetimi” veya “Auto-SSL” benzeri seçenek.

NetKıyas tarafında kullanıcıların en çok düştüğü hata: Yenileme var sanmak. Bu nedenle mutlaka şunları doğrulayın:

  • Yenileme işlemi günlük/haftalık tetikleniyor mu?
  • Yenilenen sertifikayı servis katmanı (Nginx/Apache) yeniden yüklüyor mu? (reload)
  • Yenileme başarısız olursa bir bildirim mekanizması var mı? (mail/Slack/webhook)

2) Yenileme penceresini gözünüz önünde tutun

90 gün, tek seferlik bir takvim olayı değildir. Sertifikanın yenilenmesi için pratikte sağlayıcıların belirlediği “erken yenileme” kuralları vardır. Planlamayı şu hedefle yapın:

  • Sertifika bitiş tarihinden önce, en azından birkaç gün (ve tercihen daha erken) yenilenmiş olsun.
  • Yenileme başarısız olursa ikinci bir deneme şansı doğsun.

3) Sunucuda doğru dosyaların kullanıldığını teyit edin

Reverse proxy kullanan kurulumlarda sertifika dosyası farklı dizinlerde tutulabilir. Örneğin:

  • Nginx ssl_certificate ve ssl_certificate_key yolları.
  • Apache’de SSLCertificateFile ve SSLCertificateKeyFile.
  • Container kullanılıyorsa volume mount doğru mu?

Bu kontrol, yenileme başarılı olsa bile “servis eski sertifikayı okumaya devam ediyor” hatasını engeller.

4) Zinciri (chain) doğru servis edin

Bazı kurulumlarda sadece “server certificate” yüklenir; ara sertifikeler eksik kalır. Bu durumda bazı istemciler uyarı görebilir.

Kontrol için hedef, tarayıcıdan öteye geçip bağlantı doğrulamasıdır. Örnek doğrulama komutları ortamınıza göre değişse de temel amaç şudur:

  • Sertifika zinciri eksiksiz mi?
  • Tarihler doğru mu?
  • Sunucu doğru sertifikayı sunuyor mu?

5) Monitör + alarm kurun

Sertifikanın bitiş tarihine göre alarm kurulumu yapılabilir. Bitiş tarihinden birkaç gün önce bildirim almak, “son gün” problemini bitirir.

Pratik alarm eşiği örnekleri: - 14 gün kala uyarı - 7 gün kala kritik - 24 saat kala tekrar deneme/bildirim

Hosting ve sunucu tarafında 90 gün etkisi: sağlayıcı seçerken neye bakmalısınız?

SSL sertifikasının 90 güne düşmesi, altyapı kararlarını etkiler. Çünkü otomasyon kapasitesi ve yenileme yönetimi, kullanıcı deneyimini doğrudan belirler.

Hangi özellikler kritik? (kontrol listesi)

  • Otomatik yenileme: Kurulumdan sonra müdahale gerektiriyor mu?
  • Kontrol paneli entegrasyonu: cPanel/Plesk tarzı panellerde SSL yönetimi otomatik mi?
  • Yük dengeleme desteği: TLS/SSL LB seviyesinde mi, uygulama seviyesinde mi yönetiliyor?
  • Kural ve sınırlar: Sertifika başına limit, domain sayısı, tarifeye bağlı kısıtlar.
  • İstatistik ve log erişimi: Yenileme başarısız olunca log görebiliyor musunuz?

NetKıyas’ta karşılaştırma mantığı: “sertifika yönetimi hangi katmanda?”

Aşağıdaki tablo, farklı kurulum tiplerinde sertifika yönetiminin nerede olduğuna odaklanır.

Kurulum tipi Sertifika yönetim katmanı 90 gün riski En doğru çözüm
Paylaşımlı hosting + panel Sağlayıcı/Panel Düşük (panel otomatikse) Auto-SSL açık mı kontrol et
VPS/VDS + Nginx/Apache Sunucu (siz) Orta-yüksek (otomasyon yoksa) cron/systemd + reload
Dedicated sunucu + reverse proxy Sunucu (siz) Orta Yenileme sonrası proxy reload
Load balancer / CDN ile Dış katman Düşük-orta Sertifika kaynağı doğru mu izlenir
Container/kubernetes Uygulama platformu Orta-yüksek secret/volume ve otomasyon akışı

“90 gün düşürüldü” demek neyi değiştirdi? Domain ve uygulama için etkiler

Bu değişiklik, sertifika yenileme sıklığını artırır. Bu da şu operasyonel sonuçları doğurur:

Domain bazlı süreçler daha düzenli olmalı

Domain üzerinde DNS yönetimi ve doğrulama süreçleri yenilemede tekrar kullanılır. Bu yüzden:

  • DNS kayıtları değişmiyor mu (özellikle CNAME/ALIAS gerektiren doğrulamalar)?
  • DNS yönlendirmeleri yenileme sırasında doğrulama başarısını etkiliyor mu?

Uygulama tarafında TLS bitince ne olur?

Sertifika geçerliliği bittiğinde tarayıcılar HTTPS’i doğrulamaz. Sonuçlar nettir: - Kullanıcı uyarısı - Bazı botlar/SEO etkisi - API entegrasyonlarında TLS hataları

Bu nedenle hedef otomasyondur. “Biterse manuel yenilerim” yaklaşımı 90 günle pratikte yönetilemez hale gelir.

Performans etkisi: asıl fark sertifikanın süresinde değil, yenileme kalitesinde

Sertifika süresinin 90 güne düşmesi, tek başına bir performans problemi yaratmaz. Performans etkisi genellikle şu hatalardan gelir: - Yenileme sonrası yanlış dosya yüklenmesiyle handshake sorunları - Reload sırasında servis kesintisi - Zincir hataları nedeniyle ekstra doğrulama/uyarı süreçleri

Somut uygulama örnekleri: Yenilemeyi güvenceye alın

Aşağıda “90 gün nedeniyle sorun yaşamamak” için pratik bir uygulama çerçevesi bulacaksınız. Kod örneğini vermek yerine, kritik adımları somutlaştırıyoruz.

Hedef mimari

  1. Sertifikayı otomatik yenile.
  2. Yenilendiğinde Nginx/Apache veya ilgili servis katmanını reload et.
  3. Başarı/başarısızlık durumunu logla.
  4. Bitişe yaklaşınca alarm üret.

Kontrol testleri (minimum set)

  • Yenileme tamamlandıktan sonra HTTPS zinciri doğru mu?
  • Tarayıcıda uyarı var mı?
  • HTTP/2 veya modern TLS özellikleri beklenen gibi mi?

Sonuç: 90 günle uyum için tek aksiyon planı

SSL sertifikası süresinin 90 güne düşürülmesi, güvenlik risk penceresini kısaltma hedefiyle ilerliyor; ancak bunun pratik karşılığı otomasyon zorunluluğu. Yapmanız gereken tek aksiyon planı şudur: Sertifikanızın yenilemesinin gerçekten otomatik çalıştığını doğrulayın, yenileme sonrası servis reload akışını garanti altına alın ve bitiş tarihine göre alarm kurun.

NetKıyas’ta hosting karşılaştırması yaparken de “SSL yönetimi kimde ve nasıl otomatikleşiyor?” sorusunu merkez alın. Bu yaklaşım, 90 gün politikasına rağmen kesintisiz HTTPS sağlar ve manuel son dakika müdahalelerini ortadan kaldırır.

Etiketler: #ssl #tls #sertifika #vds #vps #hosting #güvenlik #otomatik yenileme

Hosting karşılaştırması yapmaya hazır mısın?

100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.

Hosting Karşılaştır →

İlgili Yazılar

0 ürün seçildi
NetKıyas AI
Hosting danışmanınız
Merhaba! Ben NetKıyas yapay zekâ asistanı. Hosting, VDS, VPS veya sunucu seçiminde size yardımcı olabilirim. Ne arıyorsunuz?