SSL Sertifika Standartlarında Yeni Gelişmeler

SSL sertifika dünyası son yıllarda hiç olmadığı kadar hızlı değişiyor. Tarayıcı üreticileri, CA/B Forum kararları, regülasyonlar ve siber saldırı trendleri; sertifika standartlarını sürekli yukarı çekiyor. Bu değişimlerin çoğu doğrudan web sitenizi, e‑ticaret altyapınızı, API uçlarınızı ve hatta e‑posta güvenliğinizi etkiliyor. DCHost tarafında yaptığımız güvenlik denetimlerinde en sık gördüğümüz sorun, bu değişikliklerin farkında olunmaması ve SSL tarafının hâlâ “bir kere kur, unut” mantığıyla yönetilmeye çalışılması.

Oysa artık tabloda çok net bir değişim var: Sertifika süreleri kısalıyor, otomasyon zorunlu hale geliyor, domain doğrulama yöntemleri sıkılaşıyor, kayıt altına alınmayan hiçbir sertifika tarayıcılar tarafından güvenilir sayılmıyor. Buna TLS 1.3, ECDSA anahtarlar, CAA kayıtları, ACME otomasyonu ve mTLS gibi başlıklar da eklenince; SSL sertifika standartlarını takip etmek, teknik borcu kontrol altında tutmak için kritik bir iş kalemine dönüşmüş durumda.

Bu yazıda DCHost ekibi olarak sahada gördüğümüz gerçek ihtiyaçlara dayanarak, SSL sertifika standartlarında son yıllarda öne çıkan yeni gelişmeleri, bunların hosting ve altyapı tarafına yansımalarını ve pratik yol haritalarını adım adım ele alacağız. Amacımız; hem teknik ekiplerin, hem de işletme sahiplerinin önümüzdeki 1‑3 yıl için net bir SSL/TLS stratejisi oluşturmasına yardımcı olmak.

SSL sertifika standartları neden bu kadar hızlı değişiyor?

Önce resme biraz uzaktan bakalım. SSL/TLS ekosisteminde standartları belirleyen başlıca aktörler:

• Tarayıcı üreticileri (Chrome, Firefox, Safari vb.)
• İşletim sistemleri ve mobil platformlar
• Sertifika Otoriteleri (CA’ler) ve CA/B Forum
• IETF ve benzeri standart belirleyici kurumlar

Bu aktörler son yıllarda üç ana baskı altında hareket ediyor:

• Siber saldırıların artması: Phishing siteleri, sahte sertifika alma girişimleri, çalınan private key’ler, TLS downgrade saldırıları.
• Regülasyonlar ve uyumluluk: KVKK, GDPR, PCI DSS gibi çerçeveler; veri güvenliğini kanuni bir zorunluluk haline getirdi.
• Şifreleme teknolojilerindeki ilerleme: TLS 1.3, modern şifre takımları, ECDSA ve orta vadede post‑quantum (kuantuma dayanıklı) algoritmalar.

Bu baskıların sonucu olarak; SSL sertifika standartları artık yalnızca “sertifika al – https’e geç” seviyesini çoktan aştı. Bugün konuştuğumuz başlıklar; maksimum sertifika süresi, zorunlu otomasyon, sertifika transparansı, DNS tabanlı kontroller (CAA, DNS‑01), mTLS ve post‑quantum hazırlıkları gibi çok daha detaylı konular.

Bu çerçeveyi biraz daha derinleştirmek isterseniz, TLS tarafındaki değişimleri teknik açıdan anlattığımız TLS 1.3 ve modern şifrelerin mutfağı yazımıza da göz atabilirsiniz.

Sertifika süreleri kısalıyor: 398 günden 90 güne giden yol

SSL sertifika standartlarındaki en somut değişimlerden biri, maksimum sertifika süresi. Birkaç yıl önceye kadar 3 yıla kadar sertifika almak mümkündü; bugün ise genel kabul görmüş üst sınır yaklaşık 398 gün (yaklaşık 13 ay). Tarayıcı üreticileri ve CA/B Forum, bu sürenin daha da kısalması yönünde güçlü bir irade ortaya koyuyor.

Neden daha kısa sertifika süreleri isteniyor?

• Çalınan anahtarların etkisini azaltmak: Private key’in sızması durumunda saldırganın kullanabileceği süre ne kadar kısa olursa, risk o kadar sınırlı olur.
• Kimlik bilgilerinin güncel kalması: Organizasyon adı, alan adları, IP aralıkları, hukukî bilgiler sık değişiyor; uzun süreli sertifikalar hızla eskimiş bilgi taşıyabiliyor.
• Güven zincirini sık tazelemek: CA tarafında yaşanan bir ihlalin etkilerinden hızlıca kurtulmak için; kısa süreli sertifikalar çok daha kolay yönetilebilir.

Tarayıcı üreticilerinin orta vadeli hedefi; 90 güne kadar inen sertifika süreleri. Henüz herkes için zorunlu değil, ancak ekosistem bu yöne doğru hızla ilerliyor. Bu da manuel yenilemeyi pratikte imkansız hale getiriyor.

İşletmeler için ne anlama geliyor?

Birçok müşterimizde gördüğümüz tablo şu: Sertifikalar hâlâ e‑posta hatırlatmaları ve manuel paneller üzerinden takip edilmeye çalışılıyor. Sertifika sayısı 10‑15’i geçtiğinde, bu model hem operasyonel olarak yorucu oluyor hem de “sertifika bitti, site düştü” senaryosunu kaçınılmaz hale getiriyor.

Yeni standartlara hazırlanmak için:

• En azından tüm DV sertifikalarınızı ACME otomasyonu ile yönetebileceğiniz bir altyapı kurun.
• OV/EV gibi kurumsal sertifikalarda dahi, yenileme süreçlerini takvimli ve dokümante hale getirin.
• Üretim, staging ve test ortamlarının tamamında sertifika yenileme senaryosunu denemeden canlıya güvenmeyin.

ACME tabanlı otomasyonun pratik tarafını daha detaylı görmek isterseniz, SSL sertifika otomasyonunda yenilikler yazımızdaki adım adım örnekler size iyi bir başlangıç planı verecektir.

Domain doğrulama standartlarında sıkılaşma: ACME, multi‑perspective ve CAA

SSL sertifika standartlarındaki bir diğer önemli değişim; domain doğrulama (DV) tarafında yaşanıyor. Eskiden yalnızca e‑posta ile onay veya basit bir HTTP doğrulaması yeterliyken; bugün bu süreç hem otomasyon hem de sahteciliği zorlaştırma amacıyla yeniden şekilleniyor.

ACME protokolü ve zorunlu otomasyona doğru gidiş

ACME (Automatic Certificate Management Environment), Let’s Encrypt ile hayatımıza girdi ama artık yalnızca ücretsiz DV sertifikaların konusu değil; birçok CA, kurumsal senaryolar için de ACME sunucuları sağlamaya başladı. Standartlar tarafında ACME’nin önemi şu noktalarda öne çıkıyor:

• Makine‑makine iletişim: Sertifika talebi, doğrulama ve yenileme işlemleri API üzerinden yapılıyor.
• Tekrarlanabilirlik: Aynı domain için her ortamda (test, staging, prod) aynı doğrulama akışı kurulabiliyor.
• Güncel kalma: 90 günlük sertifikalarla bile insan müdahalesi olmadan döngü tamamlanabiliyor.

ACME challenge türlerini, HTTP‑01, DNS‑01 ve TLS‑ALPN‑01 farklarıyla birlikte ayrıntılı anlattığımız ACME challenge türleri rehberimizi bu yazıyla birlikte okursanız, yeni standartların pratik tarafı çok daha net oturacaktır.

Multi‑perspective doğrulama: Sahte zone’lara karşı ek güvenlik

Bazı CA’ler, multi‑perspective validation adı verilen yeni bir yaklaşımı devreye alıyor. Fikir şu: Bir domain için DNS kaydı sorgulanırken, bu sorgu yalnızca tek bir noktadan değil, dünyanın farklı bölgelerinde bulunan birden fazla resolver üzerinden yapılıyor.

Böylece;

• Saldırganın yalnızca belirli bir ağa yönelik zehirlenmiş DNS cevapları üretmesi daha zor hale geliyor.
• Anycast, bölgesel DNS ve DNSSEC gibi teknolojilerle birlikte, DNS tarafındaki bütünlük çok daha sağlam korunuyor.

Bu, özellikle kritik marka alan adları ve yüksek hacimli e‑ticaret siteleri için önemli; çünkü phishing siteleri genellikle gerçek sitelerin DNS yapılarını taklit ederek kullanıcılara sahte bir güven hissi vermeye çalışıyor.

CAA kayıtları zorunluluğa yakın: Hangi CA sertifika verebilir?

CAA (Certification Authority Authorization) kayıtları, bir domain için hangi CA’lerin sertifika verme yetkisine sahip olduğunu DNS üzerinden tanımlamanıza yarıyor. Standartlar düzeyinde CAA zaten uzun süredir tanımlı, fakat son yıllarda tarayıcı ve CA tarafındaki baskıyla birlikte fiilî bir “best practice”ten neredeyse “zorunluya yakın” bir noktaya taşındı.

Temel avantajlar:

• Siz izin vermedikçe, başka bir CA o domain için sertifika veremez.
• Yanlışlıkla alınan veya saldırganın almaya çalıştığı sertifikalar çok büyük oranda engellenir.
• Çoklu CA kullanan büyük yapılarda, hangi alt alan adı için hangi CA’nin yetkili olduğunu netleştirebilirsiniz.

CAA kayıtlarını detaylı işlediğimiz CAA kayıtları derinlemesine rehberimizde, tek CA’li basit yapılardan çoklu CA stratejisine geçen kurumsal yapılara kadar pratik örnekler bulabilirsiniz.

Sertifika transparansı (CT), log zorunluluğu ve izlenebilirlik

SSL sertifika standartlarındaki en önemli güvenlik adımlarından biri de Certificate Transparency (CT) zorunluluğu. Bugün büyük tarayıcılar, genel (public) olarak kullanılacak tüm sertifikaların onaylı CT loglarına kaydedilmiş olmasını bekliyor.

CT neden bu kadar kritik?

• İzlenebilirlik: Her sertifika herkese açık loglarda göründüğü için, bir domain için yetkisiz alınmış sertifikaları tespit etmek mümkün hale geliyor.
• Geriye dönük inceleme: Bir güvenlik olayı yaşandığında, ilgili dönemde hangi sertifikaların üretildiğini inceleyebiliyorsunuz.
• CA denetimi: Sertifika otoritelerinin hatalı veya kötü niyetli davranışları geriye dönük olarak incelenebiliyor.

Uygulama tarafında CT loglarını doğrudan yönetmeniz gerekmiyor; ama şu noktaları takip etmeniz önemli:

• Kullandığınız CA’nin CT gerekliliklerini karşılayıp karşılamadığından emin olun.
• Kurumsal yapınız büyükse, domainleriniz için CT log izleme (certificate monitoring) kurmayı düşünün.
• Phishing ve marka koruma ekipleriyle CT verilerini entegre kullanarak, alan adınızla ilgili sahte sertifika girişimlerini daha erken yakalayın.

Kriptografik standartlar: ECDSA, modern cipher’lar ve kuantuma hazırlık

SSL sertifika standartlarındaki değişim yalnızca prosedürel değil; kriptografi tarafında da ciddi bir evrim yaşanıyor. DCHost tarafında TLS yapılandırması yaparken en çok üstünde durduğumuz başlıklar şunlar:

RSA’dan ECDSA’ya geçiş: Performans ve güvenlik dengesi

Geleneksel olarak sertifikalar çoğunlukla RSA anahtarlarıyla üretilirdi. Güncel standartlar RSA’yı tamamen terk etmeye zorlamıyor; ancak giderek daha fazla ECDSA anahtarları teşvik ediliyor. Nedeni net:

• Daha kısa anahtar boyutuyla aynı güvenlik seviyesini sunar.
• Daha hızlı handshake ve daha düşük CPU kullanımı sağlar.
• Özellikle yüksek trafikli sitelerde, TLS terminasyon yükünü hissedilir şekilde azaltır.

Uyumluluk amacıyla birçok senaryoda hem RSA hem ECDSA sertifikanın aynı anda sunulduğu ikili yapı tercih ediliyor. Bu yapıyı Nginx ve Apache üzerinde nasıl kuracağınızı; ECDSA + RSA ikili SSL rehberimizde adım adım anlattık.

TLS 1.3 ve modern cipher suite’ler

Tarayıcı ve güvenlik topluluklarının ortak kararı net: TLS 1.3 zorunlu hedef, TLS 1.2 geçiş dönemi, TLS 1.0/1.1 ise fiilen tamamen devre dışı. Yeni sertifika standartları; protokol seviyesinde şu noktalara dikkat çekiyor:

• TLS 1.0 ve 1.1’in tamamen kapatılması.
• TLS 1.2’de zayıf cipher suite’lerin (örneğin bazı CBC tabanlı paketler) devre dışı bırakılması.
• TLS 1.3’te forward secrecy sağlayan modern paketlerin tercih edilmesi.

Bu konu yalnızca sertifikanın kendisiyle ilgili değil; web sunucusu, load balancer ve WAF konfigürasyonunuzla da doğrudan bağlantılı. Detaylı bir TLS sertleştirme yol haritası için, hem protokol hem de şifre listelerini ele aldığımız SSL/TLS protokol güncellemeleri rehberimize mutlaka göz atın.

Post‑quantum (kuantuma dayanıklı) sertifikalara doğru ilk adımlar

Kuantum bilgisayarların pratik saldırı kapasitesine ulaşmasına daha zaman olsa da, SSL sertifika standartlarında post‑quantum hazırlık çoktan başladı. Bugün için üretim ortamında yaygın değil, fakat standart tarafındaki hareketlere şimdiden kulak kabartmakta fayda var:

• Yeni taslaklar; klasik (örneğin ECDSA) ve post‑quantum algoritmaların hibrit olarak kullanıldığı sertifika yapıları tarif ediyor.
• Bazı CA ve tarayıcı kombinasyonlarında test amaçlı PQ anahtar denemeleri yapılıyor.
• Kurumsal tarafta kriptografik envanter (hangi uygulamada hangi algoritma kullanılıyor?) çıkarma yaklaşımı giderek zorunlu hale geliyor.

Bugün atılması gereken adım, prod ortamda PQ sertifika dağıtmak değil; altyapınızın TLS ve kütüphane seviyesinde modern, güncel ve esnek olduğundan emin olmak. Böylece birkaç yıl içinde hibrit sertifikalar yaygınlaştığında, mimarinizi kökten değiştirmek zorunda kalmazsınız.

mTLS, istemci sertifikaları ve Zero Trust mimarilerde yeni rol

SSL sertifika denince çoğunluk yalnızca sunucu tarafındaki sertifikayı düşünür. Oysa standartlardaki önemli bir gelişme de istemci sertifikaları ve mTLS (mutual TLS) tarafında yaşanıyor. Özellikle Zero Trust yaklaşımlarının yükselişiyle birlikte:

• Yönetim panellerine erişimde IP kısıtlamasına ek olarak, istemci sertifikası zorunlu tutuluyor.
• Mikroservisler arası iletişim mTLS ile güvene alınıyor.
• VPN yerine, yalnızca sertifikaya sahip cihazların erişebildiği servis tasarımları yaygınlaşıyor.

Bu yaklaşımda SSL sertifika standartları yalnızca “web sitenize dışarıdan gelen trafiği” değil; aynı zamanda iç servisleriniz ve yönetim katmanınızı da kapsıyor.

Örneğin; Nginx üzerinde mTLS kurulumunu adım adım anlattığımız Nginx ve Caddy’de mTLS rehberi, Zero Trust yaklaşımına geçmek isteyen ekipler için oldukça pratik bir başlangıç noktası sunuyor.

Otomasyon olmadan yeni standartlara uyum mümkün değil

Bugüne kadar anlattığımız tüm trendlerin ortak sonucu çok net: Otomasyon olmadan modern SSL sertifika standartlarına tam uyum mümkün değil. DCHost tarafında müşterilerle yaptığımız planlama toplantılarında en çok şu soruyla karşılaşıyoruz:

“Bizim 30‑40 adet alan adımız var, her birinin alt alanları ve farklı ortamları var. Bunların sertifikalarını manuel takip etmek artık imkansız hale geldi, ne yapmalıyız?”

Pratik bir otomasyon stratejisi nasıl kurulur?

Aşama aşama ilerlemek en sağlıklısıdır:

1. Envanter çıkarın: Hangi domain, hangi subdomain, hangi ortamda hangi sertifikayı kullanıyor? OV/EV mi, DV mi, wildcard mı?
2. Risk önceliği verin: Önce kamuya açık, yüksek trafikli ve ödeme alan sitelerinizin sertifika süreçlerini otomatikleştirin.
3. ACME sunucusu ve istemcilerini seçin: cPanel, Plesk, DirectAdmin, Nginx, Apache, Kubernetes gibi bileşenlerinizde ACME istemcilerini standardize edin.
4. DNS entegrasyonunu planlayın: Özellikle wildcard sertifikalar için DNS‑01 challenge’ı destekleyecek bir DNS otomasyonu kurun.
5. İzleme ve alarm ekleyin: Sertifika bitiş tarihlerini ve otomatik yenileme hatalarını izleme sisteminize entegre edin.

Daha ileri senaryolarda, ACME otomasyonunda yedekli CA tasarımı veya SaaS uygulamalarında otomatik SSL mimarisi gibi daha karmaşık ama esnek yapılara da geçmek mümkün.

Standart değişimlerini somutlaştırmak: Tipik senaryolar

Senaryo 1: Orta ölçekli e‑ticaret sitesi

Birçok müşterimizin profilini yansıtan bu senaryoda:

• 1 ana domain, 3‑4 alt alan (www, api, panel, static) bulunuyor.
• WordPress + WooCommerce veya özel geliştirilmiş bir PHP/Laravel altyapısı kullanılıyor.
• Ödeme sayfası PCI DSS gerekliliklerine tabi.

Yeni SSL standartları açısından yapılması gereken minimumlar:

• TLS 1.0 ve 1.1 tamamen kapatılmalı, TLS 1.3 aktif hale getirilmeli.
• Sertifika süresi en fazla 398 gün olacak şekilde planlanmalı; mümkünse 90 günlük otomatik yenileme tercih edilmeli.
• CAA kayıtları ile hangi CA’nin sertifika verebileceği DNS tarafında sınırlandırılmalı.
• HSTS, OCSP stapling ve modern cipher suite’ler etkinleştirilmeli.

WooCommerce tarafında PCI DSS uyumluluğunu bütünsel olarak ele aldığımız WooCommerce için PCI DSS hosting kontrol listesi de bu senaryo için tamamlayıcı bir rehber olacaktır.

Senaryo 2: Çok kiracılı SaaS uygulaması

Özellikle B2B SaaS dünyasında yaygın olan bu modelde:

• Her müşteriye kendi alt alanı veriliyor (musteri1.ornek.com, musteri2.ornek.com).
• Bazı müşteriler, kendi alan adlarını sisteme getirip CNAME ile bağlamak istiyor.
• Yüzlerce, hatta binlerce sertifikayı manuel yönetmek mümkün değil.

Burada yeni standartların dayattığı çözüm çok net: ACME + DNS‑01 otomasyonu ile tam otomatik SSL mimarisi. DCHost olarak özellikle SaaS müşterilerimizde:

• Wildcard sertifikalarla temel domain yapısını güvene alıyor,
• Müşteri özel alan adları için DNS‑01 ile otomatik sertifika üreten bir ACME akışı kuruyoruz,
• Sertifika bitiş tarihleri ve hata durumlarını merkezi izleme ile takip ediyoruz.

Bu modelin mimari detaylarını merak ediyorsanız, SaaS’te özel alan adları ve otomatik SSL rehberi tam size göre.

Senaryo 3: Kurumsal intranet, yönetim panelleri ve mTLS

Kurumsal yapılarda çoğu zaman asıl kritik veriler, dış dünyaya kapalı intranet uygulamalarında, yönetim panellerinde ve iç API’lerde taşınır. Yeni SSL standartları bu alanı da kapsayacak şekilde genişliyor; özellikle de Zero Trust güvenlik modelinin yaygınlaşmasıyla.

Burada uygulanabilecek stratejiler:

• Yönetim panellerine yalnızca mTLS ile, kurumsal istemci sertifikasına sahip cihazların erişmesine izin vermek.
• İç mikroservislerin tamamı arasında mTLS zorunlu hale getirerek, ağ içindeki yatay hareket (lateral movement) riskini azaltmak.
• İç CA altyapısını modernleştirerek, kısa süreli istemci sertifikaları ve otomatik yenileme akışları kurmak.

Böyle bir mimari, klasik “VPN + IP kısıtlaması” modeline göre hem daha esnek hem de daha izlenebilir bir yapı sunuyor.

DCHost altyapısında SSL sertifika standartlarına nasıl hazırlanıyoruz?

DCHost olarak hem paylaşımlı hosting, hem VPS, hem dedicated sunucu hem de colocation altyapılarımızda SSL/TLS tarafını uzun süredir bir “ek özellik” değil, temel güvenlik bileşeni olarak konumlandırıyoruz. Yeni standartlara uyum için içerde attığımız bazı adımlar:

• Yeni kurulan tüm web sunucularında TLS 1.3’ü varsayılan olarak aktif hale getirmek.
• Hazır kurulum şablonlarımızda ECDSA + RSA ikili sertifika mimarisini desteklemek.
• cPanel ve benzeri panellerde Let’s Encrypt veya eşdeğer ACME sağlayıcılarını etkinleştirerek; otomatik DV sertifika kurulumunu varsayılan yapmak.
• Müşterilerimizin talebiyle, OV/EV kurumsal sertifikaların da otomasyon süreçlerine entegre edilebileceği ACME ve API akışları tasarlamak.

Eğer mevcut sitenizi veya SaaS altyapınızı DCHost üzerinde barındırıyorsanız ve “Biz bu yeni SSL sertifika standartlarına ne kadar uyumluyuz?” sorusunun net yanıtını arıyorsanız; birlikte kapsamlı bir SSL/TLS denetimi planlayabilir, gerekli güncellemeleri aşama aşama hayata geçirebiliriz.

Özet: Bundan sonra ne yapmalısınız?

SSL sertifika standartlarındaki değişimleri tek tek incelediğinizde, tablo biraz göz korkutucu görünebilir: Daha kısa sertifika süreleri, otomasyon zorunluluğu, CAA kayıtları, CT log zorunluluğu, TLS 1.3, ECDSA, mTLS, post‑quantum hazırlıklar… Fakat bu başlıkların ortak noktası; hepsinin adım adım ve planlı bir şekilde hayata geçirilebilmesi.

Pratik bir yol haritası çizmek için şu sırayı önerebiliriz:

1. Tüm domain ve sertifikalarınızın güncel bir envanterini çıkarın.
2. TLS versiyonlarınızı ve cipher suite’lerinizi gözden geçirip TLS 1.3’e geçişi planlayın.
3. En azından DV sertifikalarınız için ACME tabanlı otomatik yenileme akışı kurun.
4. CAA kayıtları ve CT izleme gibi kontrollerle sahte sertifika riskini azaltın.
5. Yönetim panelleri ve iç servisler için mTLS kullanımını değerlendirin.

Bunların her biri; web sitenizin, e‑ticaret mağazanızın veya SaaS ürününüzün hem güvenliğini hem de kesintisizliğini doğrudan etkileyen adımlar. DCHost tarafında ister paylaşımlı hosting, ister VPS, ister dedicated sunucu veya colocation kullanın; SSL/TLS tarafındaki tüm bu yeni standartlara uygun, sürdürülebilir ve otomasyona dayalı bir mimari kurmanız için yanınızdayız.

Eğer nereden başlayacağınız konusunda aklınız karışıyorsa, önce SSL sertifikası nedir ve sitenizi nasıl güvence altına alırsınız yazımıza göz atın, ardından bu yazıdaki adımları kendi ortamınıza uyarlamaya çalışın. Takıldığınız her noktada altyapınızı birlikte gözden geçirip, SSL sertifika standartlarındaki tüm yeni gereklilikleri sade ve uygulanabilir bir plana dönüştürebiliriz.