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_certificatevessl_certificate_keyyolları. - Apache’de
SSLCertificateFileveSSLCertificateKeyFile. - 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
- Sertifikayı otomatik yenile.
- Yenilendiğinde Nginx/Apache veya ilgili servis katmanını reload et.
- Başarı/başarısızlık durumunu logla.
- 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.
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
Sıfırdan SSH ile Sunucuya Bağlanma Rehberi
Bu rehberde VDS/VPS, Linux ve Windows’tan SSH ile giriş yapmayı sıfırdan öğrenin. Anahtar, port, güvenlik ve test adımları net anlatılır.
WAF nedir, ne işe yarar? Web sitenizi nasıl korur?
WAF (Web Application Firewall) web uygulamalarını saldırılara karşı katmanlı korur. Bu rehberde nasıl çalıştığını ve doğru seçim kriterlerini bul.
SSL sertifikası süresi neden 90 güne indi? Teknik nedenler
SSL/TLS sertifikası 90 güne düşürüldü. ACME otomasyonu, güvenlik iyileştirmeleri ve operasyonel riskler açısından net nedenleri öğrenin.
İnternet nasıl çalışır? Domain’den sayfaya net yolculuk
Domain kaydından sayfanın açılmasına kadar DNS, CDN, TCP/TLS ve HTTP akışını net adımlarla öğren. Sorunların nerede çıktığını ayır.