Geçen hafta bir müşterinin paneline bakarken yine aynı sahneyle karşılaştım: “SSL var, tamamdır” diye düşünülmüş ama sertifikanın bitmesine 19 gün kalmış. Hani insan bazen alarm kurmayı unutuyor ya, işte bu konu tam öyle bir yerden vuruyor. Birkaç yıl önce yılda bir kez yenilemek çoğu ekip için yeterliydi; şimdi o rahatlık yavaş yavaş tarihe karışıyor.
Vallahi, Aslında — hayır dur, daha doğrusu dur, önce şunu söyleyeyim: 2026’da gelen değişiklik sadece “sertifika süresi kısaldı” haberi değil. Bu, tüm TLS yaşam döngüsünün yeniden yazılması demek. CA/Browser Forum’un aldığı karar, özellikle de SC-081v3 ile birlikte, sektöre net bir mesaj veriyor: manuel işlere güvenme, otomasyonu toparla, envanteri temizle.
Ne değişiyor, neden herkes bunu konuşuyor?
Konu basit gibi görünüyor. Ama etkisi geniş. Kamuya açık TLS sertifikalarının maksimum geçerlilik süresi 15 Mart 2026’dan itibaren 398 günden 200 güne düşüyor — sonra 2027’de 100 gün, 2029’da ise 47 gün seviyesine kadar iniyor,. Adım adım sıkışıyor. Evet, kulağa sert geliyor. Ama sektör zaten uzun süredir bu yöne gidiyordu zaten.
Bir dakika — bununla bitmedi.
Ben bu haberi ilk gördüğümde, açık konuşayım, biraz “yine mi?” dedim. Çünkü daha birkaç yıl önce de benzer bir kısalma yaşanmıştı; o zaman da birçok ekip panik yapmıştı ama sonra otomasyon kuranlar rahatlamıştı hızla. Şimdi fark şu: bu sefer mesele tek seferlik bir ayar değil, operasyon modelinin kendisi değişiyor.
İşin aslı şu ki sertifika dünyası yıllardır aynı problemle boğuşuyor: insanlar yenilemeyi unutuyor, doğrulama verileri bayatlıyor. Özel anahtarlar gereğinden uzun süre hayatta kalıyor. Süre kısaldıkça risk penceresi de daralıyor. Kağıt üstünde sıkıcı duran bu değişiklik, pratikte bayağı büyük etki yaratıyor (ciddiyim)
– 15 Mart 2026’ya kadar: maksimum 398 gün
– 15 Mart 2026 sonrası: maksimum 200 gün
– 15 Mart 2027 sonrası: maksimum 100 gün
– 15 Mart 2029 sonrası: maksimum 47 gün
Neden süreler kısalıyor?
Bunun arkasında üç tane çok net sebep var. Üçü de hayatın içinden geliyor. Birincisi, doğrulama bilgileri zamanla eskiyor — bugün size ait olan domain yarın başka bir ekibin eline geçebilir; şirket birleşir, DNS değişir, bulut mimarisi taşınır… Yani sertifikanın dayandığı zemin hiç de sabit değil.
Hmm, bunu nasıl anlatsamdı…
Açıkçası, İkincisi, özel anahtar sızarsa zararın boyutu küçülsün isteniyor. Kısa ömürlü sertifika demek, kötü niyetli biri elindeki anahtarla daha az süre oynayabilsin demek. Revocation hâlâ önemli tabii ama dürüst olayım — revocation mekanizması çoğu zaman beklediğimiz kadar hızlı çalışmıyor, sahada görüyoruz bunu.
Üçüncüsü biraz acı gerçek. Otomasyon artık lüks değil, zorunluluk oldu. CA/B Forum adeta “manuel süreçlerle uğraşmayı bırakın” diyor. Ben bunu kendi projelerimde de hissettim; özellikle küçük ekiplerde sertifika işi hep en sona atılıyor ve sonra gece yarısı telefon çalıyor… klasik hikâye.
Kısa ömür = daha taze güven
İlginç olan şu ki, Sertifika süresinin düşmesi aslında internetin güven katmanını daha canlı tutuyor. Bu biraz marketten bayat ekmek almak yerine her gün taze almak gibi düşünülebilir. Uğraştırır mı? Evet. Ama riski azaltır mı? Kesinlikle.
Daha az manuel iş = daha az sürpriz
Bunu yaşayan biri olarak söyleyeyim, Bakın şimdi burada güzel taraf da var: düzenli yenileme sizi disipline ediyor. İyi kurulmuş ACME akışı olan ekipler için bu haber neredeyse hiç sorun değil; hatta gözle görülür bir iyileşme bile olabilir çünkü eski usul unutulan, ertelenen, “bir ara hallederiz” denilen görevler kendiliğinden azalır.
| Dönem | Maksimum Geçerlilik | Doğrulama Yeniden Kullanımı |
|---|---|---|
| 15 Mart 2026 öncesi | 398 gün | 398 gün |
| 15 Mart 2026 sonrası | 200 gün | 200 gün |
| 15 Mart 2027 sonrası | 100 gün | 100 gün |
| 15 Mart 2029 sonrası | 47 gün | 10 gün |
Peki operasyon tarafında ne olacak?
Küçük bir startup için tablo net: eğer birkaç web servisi ve iki üç alan adı varsa sorun çözülebilir seviyede kalır, ama elle takip yapıyorsanız işler çabuk karışır. Mesela ben geçen sonbaharda İzmir’de çalışan küçük bir SaaS ekibinde buna benzer bir yapı gördüm; cert-manager vardı ama sadece staging ortamında aktifti. Production tarafında ise “bir ara hallederiz” mantığıyla ilerlenmişti… tahmin edin ne oldu? Ekip tatildeyken uyarılar patladı (ben de ilk duyduğumda şaşırmıştım)
Çok konuştum, örnekle göstereyim.
Açıkçası, Büyük kurumlarda ise dert başka türlü büyüyor. Parçalı sahiplik problemi ortaya çıkıyor — bir sistem otomatik yenileniyor, diğeri yarı otomatik durumda kalıyor, üçüncüsü ise hâlâ tek kişinin laptopundaki script’e bağlı oluyor. İşte o an süreç drift’i başlıyor ve kimse tüm resmi göremiyor (ciddiyim)
Kime ne düşüyor?
- SRE / DevOps: Yenileme akışını otomasyona bağlamak zorunda.
- Sistem yöneticileri: Envanter çıkarıp sahiplik tanımlamalı. (bence en önemlisi)
- Güvenlik ekipleri: Doğrulama verisinin yaşını ve revocation durumunu izlemeli.
- Ürün ekipleri: Dışa açık servislerde kesinti riskini ciddiye almalı.
Neyse uzatmayayım; en büyük hata sadece “sertifika aldık mı?” sorusuna odaklanmak oluyor (ciddiyim). Asıl soru şu olmalı: Bu sertifika nasıl dağıtılıyor, nerede kullanılıyor ve bittiğinde kim fark edecek?
Kısa kalan sürelerin asıl etkisi yenileme sayısını artırmak değil; hataya toleransı azaltmak.
Manuel süreçlerde küçük aksaklıklar bile doğrudan kesintiye dönüşebiliyor.
Mars’tan gelmiyorlar: hazırlanmak için ne yapmak lazım?
Bence burada devasa PKI projelerine dalmaya gerek yok. Önce temiz bir temel kurmak yeterli olurdu — hâlâ da öyle. İlk iş bütün kamuya açık sertifikaları listeleyin ve her biri için tek bir sahip belirleyin. Sahibi olmayan şey genelde unutulur; teknoloji dünyasında bu kural şaşırtıcı biçimde hep çalışıyor.
Editör masasında bu konuyu yazarken aklıma Ankara’daki eski bir kurumsal proje geldi (2019 sonlarıydı). Orada yüzlerce subdomain vardı ve ekiplerin yarısı hangi sertifikanın kimde olduğunu bilmiyordu bile. Bir excel dosyası vardı tabii… ama excel dediğin şey güvenlik sistemi değildir; en fazla iyi niyetlidir. Daha fazla bilgi için QuerySelector’ı Bıraktım: DOM’a Direkt Bağlanmak yazımıza bakabilirsiniz.
Tavsiye edilen hazırlık listesi
- Tüm public certificate’ları envantere alın.
- Ana sahibi ve yedek sahibi belirleyin. — ciddi fark yaratıyor
- Tam otomatik / yarı otomatik / manuel diye ayırın.
- Sadece issuance değil deployment’ı da test edin.
- Süre dolmadan önce uyarılar kurun: 30, 14, 7, 3 ve 1 gün gibi.
# Örnek kontrol yaklaşımı
openssl s_client -connect example.com:443 -servername example.com E tabi burada teknik araçlardan biri ACME tabanlı otomasyonlar oluyor; Let’s Encrypt kullanan ekiplerin çoğu zaten bu düzene alıştı bile diyebiliriz. Ama enterprise tarafta bazen ticari CA’larla entegrasyon gerekiyor ve orada API erişimi, onay akışları, firewall politikaları derken işler biraz çetrefilli hale geliyor — yani iş sadece komut çalıştırmak değil. Bir GitHub Projesinin Son %1’i: Sürümü Sağlam Kapatmak yazımızda bu konuya da değinmiştik. Daha fazla bilgi için ESP32 ile Spotify Ekranı: Cloudflare Workers’ın Gücü yazımıza bakabilirsiniz.
Küçük ekipler ile büyük organizasyonlar aynı şeyi yaşamayacak
Küçük startup senaryosu
Küçük ekiplerde ana problem görünürlük eksikliği olur genelde. Çünkü insan sayısı azdır ve herkes aynı anda birkaç şapka takar. Sertifika konusu da çoğu zaman “ben bakarım” denilip kenara itilir, fakat sonra o kişi izne çıkınca zincir kırılır. Bu yüzden tek kişiye bağlı süreçlerden kaçmak gerekiyor — ciddi söylüyorum, bu kural küçük ekiplerde hayat kurtarıyor.
Kurum senaryosu
Büyük yapılarda ise prosedür çoktur ama hız düşer. Güzel taraf: kaynak bol olabilir. Kötü taraf: koordinasyon ağırdır (buna dikkat edin). Benim gözlemim şu — kurumsalda teknik sorun kadar organizasyon sorunu da vardır, hatta bazen ondan bile fazla. Kimse tam resmi görmüyor çünkü herkes kendi parçasına bakıyor (kendi tecrübem) Morgan Stanley’nin Kripto Yolculuğu Bitmedi: Tokenizasyon ve Vergi Hamlesi yazımızda da bu konuya değinmiştik. Yapay Zekâ Ajanı Ne Yaptı?: Kanıtlayabiliyor musun? yazımızda da bu konuya değinmiştik.
Dengeyi kaçırmamak lazım. Her şeyi tam otomasyona bağlamak kolay değil ama hedef orası olmalı. Aksi halde kısa süreli sertifikalar size sadece daha sık toplantı olarak geri döner… kimse istemez onu!
Bana göre asıl ders ne?
Bu haber bana şunu düşündürdü: güvenlik alanında konfor alanı diye bir şey yok. Bir sistem yıllarca çalışmış olabilir ama dış dünya değişince sizin ritminiz de değişmek zorunda kalıyor. SSL/TLS konusu bunun en görünür örneklerinden biri.
İzleme, sahiplik ve deploy zinciri birlikte düşünülmeli.
Yoksa ertelenen her iş küçük bir borca dönüşüyor.
Sıkça Sorulan Sorular
TLS sertifikaları neden daha kısa süreli hale geliyor?
Daha kısa süreler sayesinde doğrulama bilgileri daha taze kalıyor ve sızıntı durumunda zarar penceresi küçülüyor. Ayrıca sektör otomasyona zorlanıyor; manuel süreçlerin riski azalıyor.
Mecburen ACME mi kullanmam gerekiyor?
Küçük bir detay: Mecburen değil. Güçlü şekilde tavsiye edilir. En çok da de sık yenilenen public sertifikalarda ACME tabanlı otomasyon hayat kurtarıyor.
Küçük işletmeler bu değişiklikten nasıl etkilenir?
Küçük işletmelerde asıl risk unutulan manuel işlemler olur. Basit uyarılar, sahiplik listesi. Otomatik yenileme çoğu sorunu çözer.
Büyük şirketlerde en büyük problem ne olacak?
Büyük yapılarda parçalara ayrılmış sorumluluk en büyük dert olur. Bazı sistemler iyi yönetilirken bazıları gölgede kalabilir,işte esas tehlike orada başlıyor.
>Kaynaklar İleri Okuma h2 >
Server Certificate Baseline Requirements
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
