SSL süresi neden 90 güne düştü? Teknik nedenler ve plan

18.07.2026 itibarıyla birçok sağlayıcı, HTTPS sertifikalarında 90 gün uygulamasını daha görünür hale getirdi. Bu değişiklik “güvenlik mi zorunlu optimizasyon mu?” sorusunu doğuruyor. Bu yazıda; 90 güne düşürmenin teknik gerekçelerini, kullanıcı tarafında oluşan etkileri (yenileme, kesinti riski, süreç gereksinimi) ve hemen uygulanabilir bir uyum planını öğreneceksiniz.

SSL süresi neden 90 güne düşürüldü? (Teknik gerekçe)

SSL/TLS sertifikalarının ömrünün kısaltılması tek bir sebepten değil, birden fazla güvenlik ve operasyon hedefinin birleşiminden gelir. Özetle amaç; sertifika sızıntısı, sahtekârlık veya yanlış yapılandırma gibi senaryolarda zararın “zamanla büyümesini” azaltmaktır.

Kısa ömür = sızıntı etkisini azaltma

Bir sertifika çalınırsa (ör. özel anahtarın ele geçirilmesi) saldırgan sertifikayı kullanarak man-in-the-middle (MITM) benzeri durumlar yaratabilir. Sertifikanın geçerlilik süresi kısaldıkça saldırganın sertifikayı kullanabileceği pencere daralır.

• Sertifika ömrü 1 yıl ise risk penceresi daha uzundur.
• Sertifika ömrü 90 gün ise risk penceresi daha kısadır.

Bu yaklaşım, güvenlik olaylarının “bekleme süresini” kısaltır. Tek başına çözüm değildir; ancak sızıntı/yanlış kullanım senaryolarında toplam etkiyi düşürür.

İmza/sertifika zinciri ekosisteminde güvenlik güncellemeleri

TLS ekosistemi düzenli olarak güncellenir. Örneğin daha yeni şifre takımları (cipher suites), protokol tercihleri ve doğrulama (validation) akışları zamanla iyileştirilir. Sertifika ömürlerinin kısaltılması, sağlayıcı ekosisteminin güncelleme tempo­suna uyum sağlar.

Otomasyona zorlayarak operasyonel hatayı azaltma

90 güne düşüşün pratik etkisi şudur: Yenileme işlemi “yıllık ritüel” olmaktan çıkıp daha düzenli bir otomasyon işine dönüşür. Otomasyon olmayan sistemlerde bile bu durum, süreçlerin gözden geçirilmesini zorunlu kılar.

Özellikle şu hatalar uzun sertifika ömürlerinde daha “görünmez” kalabilir: - Yenileme tarihini kaçırma - Kontrol panelinde yanlış sertifikayı seçme - Özel anahtar (private key) ile sertifikanın eşleşmemesi - Zincir (intermediate chain) eksik bırakma

Kısa ömür, bu hataların tekrarlarını daha sık yakalatır; yani hatalar daha hızlı tespit edilir.

90 gün uygulaması kullanıcı tarafında ne değiştirir?

Bu değişikliğin asıl etkisi teknik uygulama ve operasyon planındadır. Siteniz zaten HTTPS çalıştırıyorsa bile yenileme süreci yeni bir “iş programı” gerektirir.

Yenileme sıklığı ve kesinti riski

90 gün, manuel yönetimde hataya açık bir aralığa dönüşebilir. Manuel yenileme yapan ekiplerde iki temel risk oluşur: 1) Yenileme tarihini kaçırma 2) Yenileme anında yanlış yükleme

Bu riskleri azaltmak için hedef; sertifikanın yenilenmesini, kontrol paneli/otomasyon altyapısı üzerinden “takvim baskısı olmadan” yürütmektir.

Otomasyon gereksinimi artar

Aşağıdaki senaryolarda otomasyon neredeyse zorunlu hale gelir: - Çoklu domain/subdomain (ör. example.com, *.example.com) - Birden fazla ortam (staging/production) - Birden fazla sunucu (rolling deploy) - Tek bir ekip üzerinden merkezi yönetim beklentisi

Kontrol paneli ve kurulum yöntemi kritiktir

Sertifika yenileme mekanizması sağlayıcıya göre değişir: - Bazı hosting yönetim panelleri sertifikayı otomatik yeniler. - Bazı VDS/VPS kurulumlarında otomasyon için acme client gerekir (ör. ACME/Let’s Encrypt).

Burada belirleyici olan “sertifika dosyasının nerede tutulduğu” ve “web sunucusunun (Nginx/Apache/LiteSpeed) hangi dosyaları okuduğu”dur.

Hangi sistemlerde 90 gün etkisini daha çok hissedersiniz?

Aşağıdaki tablo, etki türlerini netleştirir:

Wildcard SSL ile doğrulama yöntemi farkı

Wildcard sertifikalarda doğrulama çoğunlukla DNS-01 yaklaşımıyla yapılır. 90 günle birlikte, DNS kayıtlarının yenileme döngüsü boyunca erişilebilir kalması gerekir. Bu; özellikle DNS hizmeti farklı bir sağlayıcıda ise daha da önem kazanır.

Net uyum planı: 90 güne geçişten sonra yapılacaklar

Aşağıdaki plan, kesintisiz yenileme hedefiyle doğrudan uygulanabilir adımlar içerir. Bu kontrol listesi, ister paylaşımlı hosting kullanın ister VDS/VPS yönetin, aynı mantığı takip eder.

1) Mevcut sertifikanızın detaylarını çıkarın

Şunları netleştirin: - Sertifika sağlayıcısı - Geçerlilik bitiş tarihi - Sertifika türü (tek domain / multi-domain / wildcard) - Kurulu olduğu yerdeki dosya veya kontrol panel kaydı

Hedef: Sisteminizin “hangi sertifikayı” kullandığını ve “ne zaman bittiğini” tek bir ekrandan görünür yapmak.

2) Yenileme yöntemini belirleyin (otomasyon mu manuel mi?)

Aşağıdaki karar çerçevesiyle ilerleyin:

• Panelde “otomatik yenile” seçeneği aktif mi?
• VDS/VPS üzerinde ACME istemcisi çalışıyor mu?
• Yenileme sonrası web sunucusunu yeniden yükleyen bir hook var mı?

Kural: Yenileme işleminden sonra web sunucusunun yeni sertifikayı gerçekten okuyup okumadığını doğrulayın.

3) Yenileme penceresi (buffer) oluşturun

90 günle birlikte tarih yönetimi daha sık hale gelir. Bu yüzden yenileme için güvenli tampon belirleyin: - Sertifika bitişinden önce yenilemeyi başlatın. - Örneğin 30 gün kala yenileme başlatma gibi bir yaklaşım, hatayı yakalamak için yeterli zaman sağlar.

Bu tampon, DNS/propagation gecikmeleri veya sağlayıcı tarafı doğrulama sorunlarında kritik olur.

4) Doğru zincir (intermediate chain) ve anahtar eşleşmesini kontrol edin

Yenileme sonrası “sertifika var ama tarayıcı yine güven vermiyor” sorunları çoğunlukla şu nedenlerden çıkar: - Chain eksik - Yanlış sertifika dosyası seçildi - Private key yeni sertifikayla eşleşmiyor

Net hedef: Sertifika yükledikten sonra tarayıcı testinin yanında sunucu tarafı doğrulama yapın.

5) İzleme (monitoring) ekleyin

Sertifikanın bitiş tarihini periyodik kontrol eden basit bir izleme kuralları şunları önler: - Son gün fark etme - Tarayıcı hatalarını kullanıcı rapor etmeden yakalama

Pratik yaklaşım: “Bitiş tarihine X gün kala uyarı” mantığı. X değeri 15-30 gün bandında netleştirilebilir.

Sağlayıcı/kurulum türüne göre kontrol listesi

Bu bölümde, en yaygın senaryolara göre “tam olarak ne kontrol edilmeli?” sorusuna yanıt veriyorum.

Paylaşımlı hosting + kontrol paneli

• Kontrol panelinde SSL yönetimi sayfasında “otomatik yenileme” aktif mi?
• Çoklu domain varsa her biri için durum tek tek doğru mu?
• Yenileme sonrası web sunucusu yeniden başlatılıyor mu (genelde otomatik yapılır, ama panel davranışını test edin)?

VDS/VPS + web sunucusu (Nginx/Apache/LiteSpeed)

• Sertifika dosyaları standart bir dizinde mi tutuluyor?
• Yenileme sonrası reload/restart tetikleniyor mu?
• Birden fazla site varsa her vhost doğru sertifikayı gösteriyor mu?

Ters proxy / reverse proxy (ör. load balancer)

• Sertifikayı edge’de mi sonlandırıyorsunuz, yoksa uygulama katmanında mı?
• Edge katmanında yenileme otomasyonu var mı?
• İç ağda uygulamaya giden trafiğin TLS ayarları tutarlı mı?

90 gün değişikliğiyle birlikte pratik beklenti: “Sertifika bitti” senaryosunu sıfıra yaklaştırın

Sertifika bitimi yaşandığında, tipik sonuç tarayıcı uyarıları ve belirli gezginlerde güven sorunu olur. Bu nedenle hedef “yenileme işini tarih temelli olmaktan çıkarıp otomasyona bağlamak” olmalı.

Net hedef seti: - Sertifika bitişini 30 gün önceden gör - Yenilemeyi 30 gün bandında tetikle - Yenileme sonrası sunucuda gerçekten yeni sertifika aktif mi doğrula - Uyarı sistemiyle manuel unutmayı engelle

Sonuç: 90 günle uyum için bugünden yapılacak en doğru aksiyon

90 gün kuralı tek başına “daha az güvenli” ya da “daha fazla sorun” anlamına gelmez; güvenlik riskini daraltan ve otomasyonu teşvik eden bir operasyon standardıdır. Bugün yapmanız gereken tek şey: Mevcut sertifikanızın yenileme yöntemini netleştirmek ve yenilemeyi otomatik hale getirip bitiş tarihini 15-30 gün bandında izlemeye almak. Eğer şu an yenileme manuel ise, bir sonraki yenileme döngüsünü “takvimle değil otomasyonla” yönetmeye geçin.