SSL sertifikası süresi neden 90 güne indi? Teknik nedenler

SSL (TLS) sertifikalarının süresinin kısalması, yalnızca “sertifika yenileme tarihi yaklaşıyor” gibi bir operasyon konusu değil. Aynı zamanda şifreleme güvenliği, anahtar yönetimi, otomasyon (ACME) ve ihlal sonrası etki alanını doğrudan etkiler. Bu yazıda, SSL sertifikası neden 90 güne düşürüldü sorusunu teknik ve pratik açıdan ele alıyoruz: Notların nerede yazdığını, sistemlerin nasıl çalıştığını ve sizin tarafınızda hangi kontrol maddelerinin önemli olduğunu net şekilde açıklıyoruz.

90 gün olayı neyi değiştiriyor?

Öncelikle “90 gün” ifadesi, özellikle ücretsiz otomatik sertifika sağlayıcılarında (çoğunlukla ACME tabanlı) yaygın bir standart haline gelen süreyi anlatır. Daha eski senaryolarda 180 gün gibi daha uzun süreler yaygındı. Sürenin kısalması şu iki hedefe hizmet eder:

• Güvenliği zamanla güncel tutmak: Sertifika/anahtar materyali ne kadar uzun süre kullanılırsa, olası bir zafiyet veya anahtarın sızması gibi risklerin etkisi o kadar uzar.
• Otomasyonu zorunlu hale getirmek: Yenilemeler düzenli aralıklarla yapılınca manuel süreçlerin hataya açık olması azalır; otomatik yenileme standarda dönüşür.

90 günün pratik etkisi

90 günlük döngü şu operasyonel sonuçları doğurur: - Sertifika yenileme yaklaşırken uyarı takibi gerekir. - Sunucu tarafında otomatik yenileme (ve otomatik web server reload) yoksa kesinti riski oluşur. - Kontrol paneli kullananlar için bile yenileme akışı net şekilde test edilmelidir.

NetKıyas gibi karşılaştırma platformlarında “hosting paketi” anlatılırken genelde performans ve kaynaklar öne çıkar. Ancak TLS süre yönetimi, site erişilebilirliği için doğrudan etkili bir başlıktır.

Neden 90 güne düşürüldü? (Teknik nedenler)

Sürecin arkasındaki motivasyonları üç ana başlıkta toplamak mümkün.

1) Sertifika süresi kısaldıkça ihlal etkisi azalır

Eğer bir sertifika özel anahtarı (private key) sızarsa veya belirli bir saldırı vektörü sertifika/anahtar kullanım dönemi boyunca avantaj sağlarsa, saldırganın “etkili pencere” süresi uzar. Süreyi kısaltmak, potansiyel kötüye kullanım penceresini daraltır.

Bu düşünce yalnızca “sertifika süresi kısalıyor” teorisi değildir. Güvenlik pratiğinde ana hedef, riskin etkisini zaman içinde minimize etmektir. Süre kısaldıkça, güvenlik olaylarında kurtarma/yenileme döngüsü daha sık gerçekleşir.

2) Otomatik yenileme (ACME) ekosistemi güçlendi

Günümüzde yaygın yaklaşım şu şekildedir: - Sertifika otomatik olarak ACME (ör. Let’s Encrypt tarzı) akışıyla üretilir. - Belirlenen aralıklarla istemci sertifikayı yeniler. - Web server yeniden yüklendiğinde (reload/restart) yeni sertifika aktif olur.

Manuel yenileme, 90 gün gibi kısa döngüde “insan hatası” riskini artırır. Bu yüzden sistemlerin varsayılan olarak otomatik yenilemeye uygun tasarlanması beklenir.

3) Daha hızlı algoritma ve politika uyarlaması gerekir

TLS ekosisteminde şifre takımları, sertifika doğrulama pratikleri ve uyumluluk kuralları zaman içinde değişir. Daha kısa sertifika ömrü: - Yeni politika/ayarların daha hızlı yayılmasını - Eski ve zayıf yapıların daha çabuk etkisiz hale gelmesini - Uyum kontrolünün daha düzenli yapılmasını sağlar

90 güne düşüş sizde neyi etkiler? (Kontrol listesi)

Bu bölüm “teknik neden”ten ziyade “siz ne yapmalısınız?” kısmıdır. Çünkü 90 gün, sadece bir takvim meselesi değildir; süre yönetimi yanlış kurgulanırsa erişim hatası üretir.

Hangi taraf yenilemeyi yönetiyor?

Yenileme sorumluluğu çoğu zaman şu katmanlardan birinde olur: - Paylaşımlı hosting / kontrol paneli: Genelde panel otomatik yenileme yapar; yine de etkinlik ve loglar kontrol edilmelidir. - VPS/VDS: Let’s Encrypt benzeri istemci (ör. certbot veya kontrol paneli istemcisi) üzerinde kurgulanır. - Dedicated sunucu: Sistem yöneticisi otomasyonu kurar.

Burada kritik soru şudur: Yenileme “gerçekten” otomatik mi, yoksa sadece bir butonla tetiklenince mi çalışıyor?

Kayıt ve uyarı mekanizması var mı?

Yenileme otomatik olsa bile kontrolsüz süreçler sorun çıkarabilir. Net kontrol noktaları: - Sertifika bitiş tarihi yaklaşınca e-posta uyarısı geliyor mu? - Sertifikanın otomatik yenilemesi bir cron/planlanmış görev ile mi yapılıyor? - Yenileme başarılı/başarısız bilgisi loglarda görünüyor mu?

Web server sertifikayı gerçekten yeniden yüklüyor mu?

Birçok senaryoda en yaygın hata şudur: - Sertifika yenilenir, ancak nginx/apache yeni sertifikayı yüklemez.

Örneğin otomasyon “sertifika dosyalarını güncelliyor” ama reload/restart yapmıyorsa, site hâlâ eski sertifikayla çalışmaya devam edebilir. Bu durum özellikle 90 günlük döngüde daha sık fark edilir.

VDS/VPS üzerinde 90 gün için pratik doğrulama

Eğer VDS/VPS kullanıyorsanız, aşağıdaki testleri yapmak “riskleri erken görmenizi” sağlar.

1) Sertifika bitiş tarihini sistemden kontrol edin

Tarayıcı her zaman yeterli sinyal vermez; doğrudan sunucu doğrulaması daha net olur. openssl ile kontrol şu şekilde yapılır:

openssl s_client -connect domain.com:443 -servername domain.com 2>/dev/null | openssl x509 -noout -dates

Burada özellikle notAfter değerinin 90 gün bandında ilerlediğini ve beklenen gün/saatte değiştiğini görmek gerekir.

2) Otomasyon zamanlamasını kontrol edin

Otomasyon genelde şu bileşenlerle çalışır: - cron (Linux) - systemd timer - kontrol paneli task scheduler

Net kontrol: Yenileme denemesi ne zaman yapılıyor? Sertifika bitişinden önce yeterli “buffer” var mı? Tipik olarak yenileme bitişe çok yakın değil, öncesinde yapılmalıdır.

3) Reload davranışını test edin

Sertifika dosyası yenilendiğinde reload otomatik mi? Bunu doğrulamak için: - Sertifika dosyası güncellendiğinde nginx/apache durumunu kontrol edin. - Reload loglarına bakın.

Paylaşımlı hostingte 90 gün: Operasyonel risk nerede?

Paylaşımlı hosting kullanıcıları için yenileme genelde otomatik olur. Yine de 90 günün etkisi “süreyi kaçırırsam ne olur?” sorusuyla gelir.

Net risk noktaları: - Kontrol paneli otomatik yenileme yapmıyor olabilir (bazı kurulumlarda sadece talep üzerine çalışır). - Sitede kullanılan alan adı DNS tarafında farklı bir yere işaret ediyorsa doğrulama (domain validation) başarısız olabilir. - E-posta doğrulama veya DNS doğrulama (DNS-01 gibi) gereksinimleri panelde doğru ayarlanmadıysa yenileme başarısız olur.

Bu yüzden paylaşımlı hostingte bile şu iki kontrol yapılmalıdır: - Sertifika “durumu” ekranında otomatik yenileme bilgisi görünüyor mu? - Sertifika yenileme denemelerinde hata logları/panel bildirimleri var mı?

90 güne düşüşle birlikte “en iyi uygulamalar” değişti

90 gün standartlaştıkça, iyi pratikler de netleşti.

1) Hangi domain/alt domain kapsanıyor?

Sertifika türü belirleyicidir: - Tek domain sertifikası - Wildcard sertifika (ör. *.domain.com) - Multi-domain (SAN) sertifikalar

Alt domain sayısı arttıkça yenileme doğrulaması ve DNS bağımlılıkları büyür. Net plan: Sertifika kapsamını minimumda tutun. Gereksiz alt domainleri kapsama eklemeyin.

2) Sertifika zinciri ve ara sertifikalar

Yanlış kurulum bazen tarayıcıda uyarı üretir. Yenileme sonrası zincir dosyaları doğru bağlanıyor mu kontrol edin. Kontrol paneli kullanıyorsanız panelin bu kısmı genelde yönetir; ancak özel kurulumlarda siz yönetirsiniz.

3) “Sadece sertifikayı yenilemek” yetmez

Yenileme sonrası şu kontroller önemlidir: - Site hâlâ HTTPS üzerinden mi açılıyor? - Yönlendirme (HTTP → HTTPS) doğru mu? - HSTS (HTTP Strict Transport Security) kullanılıyorsa ayarlar doğru mu?

SSL süresi 90 güne indiğinde NetKıyas’ta hangi kriterler öne çıkmalı?

Bu bölüm karşılaştırma mantığıyla ilgilidir. Hosting seçerken sadece CPU/RAM değil, TLS operasyonlarının sorunsuz çalışması gerekir.

Aşağıdaki kriterleri paket karşılaştırırken arayın:

Sonuç: 90 gün standart oldu, aksiyon da standartlaşmalı

SSL/TLS sertifikalarının 90 güne düşürülmesi; güvenlik riskini zaman içinde sınırlamak, otomatik yenilemeyi standartlaştırmak ve değişen TLS politikalarına hızlı uyum sağlamak için yapılan bir güvenlik tasarımıdır. Sizin tarafınızda kritik olan, otomatik yenilemenin gerçekten çalıştığını ve yenileme sonrası web server reload’un yapıldığını doğrulamak; bitiş tarihini takip edip hata loglarını düzenli kontrol etmektir.

Bugün yapmanız gereken net aksiyon: Sunucunuzun (veya kontrol panelinizin) sertifika yenileme yöntemini belirleyin, bitiş tarihini openssl ile kontrol edin ve yenilemenin planlı şekilde çalıştığını log/uyarı üzerinden test edin. Böylece 90 günlük döngü bir sürpriz olmaktan çıkar, yönetilebilir bir rutine dönüşür.