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

SSL sertifikası süresinin 90 güne düşürülmesi, sadece “sertifika yenileme zamanı geldi” mesajından ibaret değil. Bu değişiklik; otomasyon, güvenlik politikaları, yayın hızı ve web operasyon süreçleri üzerinde doğrudan etkiler yaratıyor. Bu rehberde 90 gün kararının arka planındaki mantığı, pratikte neyi değiştirmeniz gerektiğini ve VDS/VPS/web hosting tarafında en sık yapılan hataları net şekilde anlatacağım.

1) 90 gün kararı neyi hedefliyor?

SSL/TLS sertifikalarının kısa süreli verilmesi (90 gün gibi) güvenlik ekosisteminde tek bir hedefe hizmet eder: sertifika yaşam döngüsünü kısaltmak ve olası ihlal etkisini azaltmak. Sertifika özel anahtarı (private key) veya sertifika zinciri (chain) bir şekilde risk altına girerse, saldırganın elindeki geçerlilik penceresi küçülür.

Bu yaklaşımın arka planında birkaç teknik/operasyonel motivasyon var:

• Daha hızlı sürümleme: TLS sürümlerinde (ör. TLS 1.2/1.3) ve şifre takımlarında (cipher suite) güncel uygulamalar daha kısa sürede yaygınlaşır.
• İhlal olasılığına karşı sınır koyma: Uzun süreli sertifikalarda (ör. 1 yıl) anahtar sızarsa etki daha uzun sürer.
• Operasyonel disiplin: “Yıl sonu” tarzı yenileme değil, daha ritmik yenileme alışkanlığı oluşur.
• Güvenlik denetimlerinin kolaylaşması: Kısa ömür, otomasyon ve izleme gereksinimini artırır; bu da kurumsal süreçlerde görünürlüğü yükseltir.

Burada kritik nokta şu: 90 gün, sadece kullanıcıyı yenilemeye zorlayan bir kural değil; aynı zamanda hatalı yenileme/eksik otomasyon riskini görünür kılan bir tasarımdır.

2) 90 günün web sitene etkisi: “sertifika bitmeden yenile” yeter mi?

90 güne geçişin pratik sonucu, sertifikaların daha sık yenilenmesi ve bu süreçte daha çok kontrol gerektirmesidir. Bu noktada asıl risk, sertifikanın süresinin dolması değil; sertifikanın yenilenmesine rağmen sitenin beklenen dosyaları otomatik yüklememesi veya ara katmanla (intermediate) yanlış zincir sunulmasıdır.

Aşağıdaki tabloda 90 güne geçiş sonrası sık görülen senaryolar ve net çözüm adımları yer alır:

Hangi kontroller “asıl fayda” sağlar?

• Sertifika bitmeden (ör. 7-14 gün kala) otomasyonun çalıştığını doğrulayın.
• Nginx/Apache konfigürasyonunda doğru dosya yollarını kontrol edin (fullchain.pem ve privkey.pem).
• Tarayıcı yerine en az bir doğrulama aracı kullanın: ör. openssl s_client ile zinciri görmek veya çevrimiçi SSL testleri.

3) Neden bu kadar tartışılıyor? Operasyonel maliyet ve güvenlik dengesi

90 gün süresi tartışmasının asıl nedeni iki uç arasındaki denge:

1) Güvenlik kazanımı: Sertifika yaşamı kısalınca “yanlışlıkla açıkta kalma” süresi azalır. 2) Operasyonel maliyet: Yenileme sıklığı artar; otomasyon yoksa süreçler hata üretebilir.

Bu yüzden iyi kurulum şunları sağlamalıdır: - Yenileme işlemi tek başına yetmez; web sunucusunun yeni sertifikayı servis etmesi de gerekir. - Sertifika dosyalarının güncellenmesi ile reload/restart arasında net bir bağ kurulmalıdır. - Kayıp/okunmayan loglar yerine yenileme başarısı ve servis reload sonuçları takip edilmelidir.

4) VDS/VPS ve kontrol paneli açısından net yapılacaklar

90 güne düşüş sonrası en büyük fark, “kurulum yaptım tamam” yaklaşımından “yenileme akışı çalışıyor mu?” yaklaşımına geçmektir. Aşağıda iki senaryo üzerinden net kontrol listesi var.

4.1 Kontrol paneli olan ortamlar (cPanel/DirectAdmin/Plesk vb.)

Kontrol paneli kullanıyorsanız hedef, panelin sertifika yenilemeyi otomatik yapıp yapmadığını görmek ve yenileme sonrası web servisini yeniden yüklediğinden emin olmaktır.

Net kontrol adımları: - Sertifika bölümünde son yenileme tarihini ve sonraki yenileme planını görün. - Wildcard veya çoklu domain kullanıyorsanız panelin bunu nasıl yönettiğini doğrulayın. - “Failover” veya ek proxy (Cloudflare benzeri) kullanıyorsanız, sertifikayı hangi katmanda yönettiğinizi netleştirin.

4.2 Komut satırı/otomasyon ile yönetilen VDS sunucular (Nginx/Apache)

Bu senaryoda otomasyonun varlığı kadar, dosya yolları ve reload adımları kritiktir.

Net uygulanabilir kontrol: - Yenileme aracınız (ör. ACME istemcisi) sertifikayı güncellediğinde hedef dosyaya yazıyor mu? - Web sunucusu yapılandırmanız yeni dosyaları okuyor mu? - Yenileme sonrası şu adımlar otomatik mi: - Nginx için nginx -t kontrolü - Sonra reload - Apache için apachectl graceful benzeri doğru yeniden yükleme

Önemli: “Sertifika yenilendi” mesajı görmek tek başına yeterli değildir. Sunucunun gerçekten yeni sertifikayı servis edip etmediğini test edin.

4.3 DNS ve doğrulama yöntemi seçimi: HTTP-01 mi DNS-01 mi?

90 gün sisteminde başarının önemli kısmı doğrulama metoduna bağlıdır.

• HTTP-01 doğrulama: Siteye belirli bir path üzerinden erişim gerektiğinden altyapı kısıtları varsa zorlaşır.
• DNS-01 doğrulama: Etkiyi DNS kaydı üzerinden sağladığı için wildcard kullanımında daha uygundur.

Net seçim kriterleri: - Subdomain sayısı çoksa ve wildcard hedefleniyorsa DNS-01 daha yönetilebilir olur. - Hostinginizde HTTP-01’i bozacak yönlendirme/rewriting katmanları varsa DNS-01 tercih edin.

5) NetKıyas bakışıyla: Hangi barındırma tipinde risk daha düşer?

90 gün değişimi, hosting sağlayıcının “sertifika yenileme otomasyonu” kalitesiyle doğrudan ilişkilidir. Aynı sertifikayı siz de yönetebilirsiniz; fakat pratikte yönetim maliyeti sağlayıcı ve altyapıya göre değişir.

Aşağıdaki tablo, kullanıcı bakışında net farkları özetler:

VDS/VPS alırken sorulacak net sorular

• Sertifika yenileme otomasyonu var mı ve reload otomatik yapılıyor mu?
• Panel kullanıyorsam yenileme sonrası servis yeniden başlatılıyor mu?
• ACME doğrulama (HTTP-01/DNS-01) desteği var mı?
• Yenileme logları erişilebilir mi? (Siteden “bitti” haberini beklemeyin.)

6) Son tarihler yaklaşırken uygulanacak aksiyon planı

90 gün süresine uyum, tek seferlik kurulum değil; “sertifika bitmeden yenileme ve doğrulama” döngüsüdür. Aşağıdaki plan, bugün başlasanız bile en az riskle ilerlemenizi sağlar.

6.1 Hemen şimdi (bugün) yapın

• Sertifikanın bitmesine kalan süreyi kontrol edin.
• Web sunucunuz Nginx/Apache ise sertifika dosya yollarının nereden okunduğunu doğrulayın.
• Subdomain varsa hepsi aynı yenileme stratejisini mi kullanıyor kontrol edin.

6.2 7 gün içinde kurumsal güvence ekleyin

• Yenileme otomasyonunu çalıştırın veya “deneme yenileme” prosedürü uygulayın.
• Yenileme sonrası reload/graceful adımının gerçekten tetiklendiğini logdan doğrulayın.
• Zincirin doğru servis edildiğini en az bir test ile kontrol edin.

6.3 Süreklilik için izleme ekleyin

Sertifikanın bitişiyle birlikte “uyarı gördüm” demek geç kalmaktır. Net yaklaşım: - Yenileme başarısız olunca bildirim alın. - Sertifika bitiş tarihine göre erken uyarı üretin (ör. 14/7 gün).

Sonuç: 90 günle uyumun ana anahtarı otomasyon + test zinciri

SSL süresinin 90 güne düşmesi güvenlik etkisini artırırken, operasyon tarafında otomasyonun sağlam olmasını zorunlu hale getiriyor. Tek yapmanız gereken “sertifika yenileyici kurmak” değil; yenilemenin web sunucusuna yansıdığını doğrulamak ve erken uyarı/izleme eklemek.

Bu hafta bir kontrol listesiyle ilerleyin: sertifika bitişini bulun, yenileme mekanizmasını test edin, reload zincirini doğrulayın ve subdomain/wildcard stratejisini netleştirin. Böylece 90 günlük periyot boyunca sürpriz yaşatmadan güvenli TLS hizmeti devam eder.