SSL süresi neden 90 güne düştü? Teknik ve operasyonel etkiler

SSL sertifikalarının geçmişte yaygın olan 1 yıllık sürelerinden kısalıp 90 güne düşmesi, yalnızca bir “kural değişikliği” değildir. Bu karar; şifreleme altyapısının güvenliğini artırmak, yanlış yapılandırma ve kaçak (compromise) senaryolarının etkisini azaltmak ve sertifika yenileme süreçlerini otomasyona yaklaştırmak gibi hedeflere dayanır. Bu yazıda 90 gün kararının teknik arka planını, hosting/VDS tarafında pratik etkilerini ve net bir kontrol listesi ile ne yapmanız gerektiğini öğreneceksiniz.

90 güne düşürülmenin ana gerekçeleri

1) Kaçak (compromise) olasılığında “etki süresi” kısalır

Bir sertifikanın özel anahtarı ele geçirilirse veya bir CA (Certificate Authority) tarafında sorun yaşanırsa, saldırganın kullanabileceği zaman penceresi uzadıkça risk büyür. Sertifika süresini kısaltmak, saldırganın faydalanma süresini daraltır. 90 gün, “güvenliği artırmak” hedefiyle uyumlu bir ara değerdir: yönetilebilir, fakat unutma/ihmal kaynaklı uzun süreli açık bırakmayı zorlaştırır.

2) Yanlış kurulumlar daha erken yakalanır

Örneğin: - Yanlış ara CA zinciri (chain) gönderilmesi, - Sertifikanın farklı bir domaine/kaynağa yanlış eşlenmesi, - Eski zincirin tarayıcı cache’lenmesi, - Yanlış yenileme adımı nedeniyle “son kullanma yaklaşımı”nın fark edilmemesi,

Bu tür hatalar, uzun süreli sertifikalarda gecikebiliyor. 90 gün yaklaşınca yenileme ekranları, loglar ve izleme sistemleri daha erken devreye giriyor.

3) Otomasyon teşvik edilir (özellikle ücretsiz/standart akışlarda)

Modern ekosistemde Let’s Encrypt gibi otomatik yenileme akışları yaygındır. Süre kısaldıkça otomasyonun standart hale gelmesi beklenir: “manuel yenileme” değil, otomatik yenileme (renewal) ve servis reload/publish işlemleri daha kritik hale gelir.

4) Devre dışı bırakma ve revocation süreçleri tek başına yeterli olmayabilir

Sertifika iptali (revocation) her zaman anlık yayılmayabilir. Süre kısaldığında, revocation altyapısı kusursuz olmasa bile genel risk süresi düşer.

90 gün kararı hosting ve VDS/VPS operasyonlarını nasıl etkiler?

Sertifikanın “bitmesine” rağmen servis ayakta kalmamalı

SSL bitmeden yenileme yapılır; yenileme başarısız olursa servis tarafında “expired cert” ile çalışmak istemezsiniz. Bu nedenle şu mantık değişir: Sertifika süresini beklemek yerine yenilemeyi takip etmek gerekir.

Otomatik yenileme yoksa iş yükü artar

Eğer bir sistemde sertifika yenileme: - cron ile tetiklenmiyor, - kontrol paneli (cPanel/Plesk/Web panel) otomatik yenilemeyi yönetmiyor, - container ortamında renew mekanizması yok,

o zaman 90 gün, daha sık müdahale anlamına gelir. Net hedef: yenileme görevlerinin başarı/başarısızlık durumunu izlemek.

Hosting altyapısında “reload” veya “restart” planlaması şart

Sertifika dosyaları güncellendiğinde web sunucusu (Nginx/Apache/Caddy) ve reverse proxy (ör. Cloudflare Tunnel hariç, doğrudan proxy) yeniden yüklenmeli. Aksi halde: - Yenilenen dosya disk üzerinde durur ama Nginx eski sertifikayı kullanmaya devam eder, - Load balancer/katman doğru dosyaya işaret etmez, - Güncelleme gecikir ve son kullanma sonrası kesinti görülebilir.

HSTS, OCSP stapling ve chain doğruluğu daha sık kontrol edilir

Kısa süre yaklaşınca kalite denetimi artar: - HSTS politikasında max-age uzun ise, tarayıcı eski davranışa daha uzun süre bağlı kalabilir. - OCSP stapling doğru konfigüre edilmezse bazı istemciler ek sorgu yapar. - Chain yanlış kurulursa tarayıcı doğrulaması başarısız olur.

90 günle birlikte sertifika yenileme stratejisi: doğru plan

Aşağıdaki karar ağacı, hangi yöntemi kullanacağınızı netleştirir.

Hangi senaryoda hangi yenileme yaklaşımı? (karşılaştırma tablosu)

Minimum hedef: “yenileme başarıyla tamamlandı” sinyali

Net ölçüm noktaları: - Sertifika yenilendi mi? (dosya değişti mi, not before/not after güncellendi mi) - Web sunucusu yeni sertifikayı yüklendi mi? (reload/restart başarılı mı) - Zincir doğruluğu tarayıcıda ve test aracıyla doğrulandı mı? - Monitoring alarmı var mı? (ör. bitişe 14 gün kala)

NetKıyas bakışıyla pratik kontrol listesi

Aşağıdaki kontrol maddeleri, özellikle VDS/VPS kullananlar için “bitiş geldiğinde panik yaşanmaması” odaklıdır.

1) Sunucuda sertifika yenileme yöntemini netleştirin

Şunlardan hangisini kullanıyorsunuz? - Kontrol paneli otomasyonu - ACME istemcisi (cron + script) - Ingress/managed çözüm

Eğer hangisi olduğunu bilmiyorsanız, sunucuda şu soruların cevabını üretin: - Sertifika dosyaları nerede saklanıyor? (ör. /etc/ssl/...) - Yenileme işi hangi kullanıcıyla çalışıyor? - Web server hangi path’i kullanıyor?

2) Web server reload akışını test edin

Sertifika dosyası değişince web sunucusu otomatik reload oluyor mu? Uygun yaklaşım: - yenileme sonrası reload komutu (ör. Nginx reload), - hata olursa loglama, - deneme zamanı: sertifika bitişinden günler önce bir “dry run” (mümkünse) veya kısa test.

3) Bitime alarm kurun (minimum 14 gün kuralı)

90 gün rejiminde “bitmeye 1-2 gün kala fark etmek” geç kalır. Net öneri: - 14 gün kala alarm, - 7 gün kala kritik alarm, - yenileme başarısızsa anında alarm.

4) Çoklu domain ve alt domainlerde eşlemeyi doğrulayın

Birden fazla alan adınız varsa iki hata çok görülür: - Sertifika yenileniyor ama yanlış domain için, - Wildcard/domain kombinasyonu karışıyor.

Her domain için: - doğru sertifikanın doğru vhost’a bind edildiğini, - reverse proxy varsa doğru upstream’e geldiğini kontrol edin.

90 gün uygulamasının “güvenlik” kadar “uygulama” tarafına etkisi

Daha sık yenileme = daha sık konfigürasyon kontrolü

90 gün; otomasyonu zorunlu kılar. Bu, güvenlik açısından olumlu ama aynı zamanda “konfigürasyon disiplinini” yükseltir. İyi yapılan bir ortamda sonuç şudur: - Sertifikalar düzenli yenilenir, - reload sorunsuz olur, - expired riski ciddi biçimde azalır.

Kötü yapılan bir ortamda ise: - yenileme başarısız olduğunda fark edilmez, - reload yapılmadığı için eski sertifika kullanılır, - bitiş sonrası servis kesintisi yaşanır.

Hosting seçimi yaparken sertifika otomasyonu kritik bir kriter olur

Sunucu tarafında kontrol sizdeyse bile, hosting tarafındaki destek önemlidir. Net kriterler: - kontrol paneli otomatik renew sunuyor mu, - loglar nerede ve nasıl izleniyor, - barındırdığınız stack’in (Nginx/Apache/Reverse proxy/Container) otomasyona uygunluğu var mı.

Sonuç: 90 günle uyum için bugün atılacak somut adımlar

SSL süresinin 90 güne düşmesi, güvenlik etkisini artıran bir standarttır; ancak sizden beklenen değişim “yenilemenin otomatik ve izlenen bir süreç” haline getirilmesidir. Bugün yapmanız gerekenler net: 1) Sertifika yenileme yönteminizin (kontrol paneli mi ACME mi) ne olduğunu bulun. 2) Yenileme sonrası web server reload/restart akışının çalıştığını test edin. 3) Bitişe 14 ve 7 gün kala alarm kurun; yenileme başarısızlığını da alarm sinyaline bağlayın. 4) Çoklu domain varsa her domain için doğru eşlemeyi doğrulayın.

Bu dört adım tamamlandığında 90 gün rejimi operasyonel risk üretmez; aksine sertifika yönetimini daha kontrollü hale getirir.