SSL Sertifika Standartları: Süre ve Doğrulama

SSL/TLS sertifika yönetiminde süre, doğrulama ve tarayıcı güven politikalarını birlikte takip etmek gerekir. Bu rehberin politika kontrol tarihi 4 Kasım 2026’dır; süre ve MPIC tabloları CA/B Forum Baseline Requirements v2.3.1’in (4 Ekim 2026) ilgili bölümlerine dayanır. Kapsam, genel güven depolarına dayanan TLS sunucu sertifikalarıdır; S/MIME e-posta sertifikaları ve yalnız kurum içinde güvenilen özel PKI aynı kurallara tabi kabul edilmemelidir. SSL tarafını “bir kere kur, unut” mantığıyla yönetmek, standart değişikliklerinin ve yenileme ihtiyaçlarının gözden kaçmasına yol açabilir.

Oysa artık tabloda çok net bir değişim var: Sertifika süreleri kısalıyor, otomasyonun operasyonel önemi artıyor, domain doğrulama yöntemleri sıkılaşıyor; CT politikası uygulayan tarayıcılarda, bu politikaların kapsamındaki sertifikalar için log gereksinimlerine uyum aranı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 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 sertifika verilme politikası, tarayıcı güveni ve bağlantı protokolü ayrı katmanlardır. 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 kararları etkileyen güvenlik ve işletim başlıkları arasında şunlar bulunur:

• Siber saldırı riskleri: Phishing siteleri, sahte sertifika alma girişimleri, çalınan private key’ler, TLS downgrade saldırıları.
• Regülasyonlar ve uyumluluk: KVKK ve GDPR gibi düzenlemeler ile PCI DSS gibi sektör standartları, veri güvenliğine ilişkin yükümlülükler getiriyor.
• Şifreleme teknolojilerindeki ilerleme: TLS 1.3, modern şifre takımları, ECDSA ve post‑quantum (kuantuma dayanıklı) algoritmalara hazırlık.

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, sertifika otomasyonu, 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: Yenileme planına etkileri

Neden daha kısa sertifika süreleri isteniyor?

• Çalınan anahtarların etkisini sınırlamak: Daha kısa geçerlilik süresi, sızan anahtarla birlikte kullanılabilecek sertifikanın geçerlilik penceresini daraltır. Ancak aynı anahtar yenilenen sertifikalarda kullanılmaya devam ederse risk sürer; sızıntıda anahtarın değiştirilmesi ve ilgili sertifikaların iptali gerekir.
• 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 zincirindeki değişikliklere uyum: Sık yenileme, gerekli zincir değişikliklerini uygulamak için daha sık fırsat sunar; ancak CA ihlalinde gereken iptal veya güven deposu müdahalelerinin yerini tutmaz.

90 gün, bütün CA’ler için gelecekteki ortak zorunlu son nokta değildir; kabul edilmiş takvim 47 günlük tavana kadar gider. Ayrıca BR §4.2.1’de alan adı/IP doğrulama verisinin yeniden kullanım tavanı 15 Mart 2026’da 200, 15 Mart 2027’de 100, 15 Mart 2029’da 10 gündür. Kurum kimliği doğrulama verisi için 15 Mart 2026’dan itibaren ayrı 398 günlük tavan vardır. Doğrulama verisinin yaşı, sertifikanın geçerlilik süresi ve istemcinin yenileme zamanı farklı kavramlardır. Bu da özellikle sertifika sayısı arttıkça manuel yenilemenin iş yükünü ve hata riskini yükseltiyor.

İşletmeler için ne anlama geliyor?

Örneğin, bir ekip sertifikalarını yalnızca e‑posta hatırlatmaları ve manuel paneller üzerinden takip ediyor olabilir. Sertifika sayısı arttıkça bu modelin iş yükü ve yenilemenin atlanması riski artar; ancak kesinti için evrensel bir sertifika sayısı eşiği yoktur.

Yeni standartlara hazırlanmak için:

• Desteklenen DV sertifikaları için ACME veya CA’nin uygun API akışını değerlendirin; ACME kullanımı genel bir BR zorunluluğu değildir.
• OV/EV’de de CA desteğini, kurum doğrulamasını, hesap yetkilerini ve yeniden doğrulama zamanını belgeleyin.
• Test ve staging ortamında talep, doğrulama, yükleme, servis reload’u ve hata senaryolarını deneyin; üretimde kontrollü dağıtım sonrası gerçekten sunulan sertifikayı doğrulayın.
• İstemci/CA yenileme penceresini kullanın, son günü beklemeyin; süre kısaldıkça alarm ve müdahale payını yeniden hesaplayın.

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

SSL sertifika standartlarındaki bir diğer önemli değişim; domain doğrulama (DV) tarafında yaşanıyor. Domain doğrulama yöntemleri, otomasyonu destekleme ve sahteciliği zorlaştırma hedefleriyle geliştiriliyor; kullanılabilecek yöntemi seçerken CA’nin desteklediği akışlar ve geçerli doğrulama kuralları birlikte değerlendirilmelidir.

ACME protokolü ve sertifika otomasyonu

ACME, RFC 8555’te tanımlanan otomatik sertifika yönetim protokolüdür. Let’s Encrypt ve başka sağlayıcılarla kullanılabilir; desteklenen sertifika türü, challenge, hesap ve API koşulları CA’ye göre değişir. Kurumsal kimlik doğrulaması gereken bir ürün, yalnız ACME bağlantısı kuruldu diye otomatik olarak doğrulanmış olmaz. Seçimde şu özellikleri değerlendirin:

• Makine iletişimi: Sertifika talebi, yetkilendirme ve sertifika alma adımlarını istemci yönetebilir; sunucuya güvenli dağıtım ayrıca kurulmalıdır.
• Tekrarlanabilirlik: Her ortamın DNS, ağ erişimi, hesap yetkisi ve challenge yolunu test edin; aynı akış her yerde kendiliğinden çalışmaz.
• Yenileme: CA’nin verdiği gerçek süreye ve istemcinin desteklediği yenileme penceresine göre çalışın. Zamanlayıcı, rate limit, hata tekrarı ve dağıtım sonucunu izleyin.

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: Farklı ağ noktalarından kontrol

Böylece;

• Saldırganın yalnızca tek bir ağ noktasını yanıltarak doğrulamayı geçmesi zorlaştırılabilir.
• Anycast veya bölgesel DNS kullanımı tek başına DNS verisinin bütünlüğünü garanti etmez; çok noktadan doğrulama da DNSSEC ile aynı güvenceyi sağlayan bir mekanizma olarak görülmemelidir.
• 15 Mart 2026’dan itibaren BR’nin birincil perspektif DNS sorguları ve CAA kontrolleri için DNSSEC doğrulama koşulları da geçerlidir. Bu, her alan adının DNSSEC ile imzalanmasının zorunlu olduğu anlamına gelmez; BR §4.2.2.2.3’teki bazı e-posta yöntemlerine ilişkin sınırlı istisna dışında, birincil perspektifteki DNSSEC doğrulama hatası sertifika verme izni sayılmaz.

Bu, özellikle kritik marka alan adları ve yüksek hacimli e‑ticaret siteleri için yetkisiz sertifika verilmesi riskini azaltmaya yönelik bir kontroldür. Benzer görünümlü başka alan adlarıyla kurulan phishing sitelerini ise tek başına engellemez.

CAA kayıtları: 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. CAA, sertifika verilmesi aşamasındaki yetkilendirmeyi sınırlar; CAA kayıtlarını değiştirmek mevcut sertifikaları iptal etmez ve tek başına kapsamlı site koruması sağlamaz. Alan adı sahibinin CAA kaydı yayımlaması genel bir zorunluluk değildir; CA’nin ilgili CAA kontrolünü yapması ayrı bir yükümlülüktür. İlgili CAA RRset bulunmadığında CAA kaynaklı kısıtlama oluşmaz, ancak diğer doğrulama şartları devam eder. Mevcut ve yedek CA’leri yetkilendirmeyi birlikte planlayın.

Temel avantajlar:

• Kısıtlayıcı bir CAA politikası yayımladığınızda, CAA kurallarına uyan CA’ler bu politikanın izin verdiği ölçüde sertifika verebilir.
• Bu kontrol, izin verilmeyen CA’lerden sertifika alınması riskini azaltır; izin verilen bir CA’deki hatalı doğrulamayı veya tüm yetkisiz sertifika taleplerini engelleme garantisi sunmaz.
• Ç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ı: Tarayıcı politikası ve izlenebilirlik

Certificate Transparency gereksinimleri tarayıcının politikasına ve güven kapsamına göre değerlendirilir. Örneğin Chrome’un CT politikasındaki sertifikalar, kabul edilen loglardan gerekli SCT kanıtlarını sağlamalıdır; özel olarak yüklenen kurum köklerini aynı kapsamda varsaymayın. SCT, logun belirlenen süre içinde kaydı ekleyeceğine ilişkin imzalı taahhüttür; tek başına kaydın çoktan eklendiğinin kanıtı değildir. CT, sertifikanın güven zinciri veya alan adı doğrulamasının yerine geçmez.

CT neden bu kadar kritik?

• İzlenebilirlik: Loglara alınan sertifika/ön sertifikalar üzerinden kendi alan adlarınıza beklenmedik düzenlemeleri araştırabilirsiniz.
• Olay incelemesi: Log zamanı, sertifika kimliği, isimler ve CA bilgisi olay kaydına katkı sağlar; üretimde kullanılmış olduğunu tek başına kanıtlamaz.
• CA denetimi: Hatalı düzenleme araştırmasına yardımcı olur. CT kaydı sertifikayı güvenli, işletmeyi meşru veya içeriği zararsız ilan etmez.

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

• CA’nin ve istemcilerin geçerli CT politikasını, SCT teslimini ve zincir doğrulamasını kontrol edin.
• Kendi alan adlarınız için CT izleme kurun; yeni kayıtları beklenen sertifika envanteriyle eşleştirin.
• Beklenmedik kayıtta sahipliği ve yetkilendirmeyi inceleyin; gerekiyorsa CA iptal sürecini başlatın. Benzer yazımlı başka alan adlarıyla phishing ayrı marka izleme kapsamıdır.

Kriptografik standartlar

Sertifika anahtarı, CA’nin imza algoritması ve TLS bağlantısındaki anahtar anlaşması ayrı seçimlerdir. RSA/ECDSA sertifikası, tek başına TLS sürümünü, forward secrecy’yi veya bağlantının performansını belirlemez. Bu katmanları birlikte değerlendirin:

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

BR’nin ilgili profilleri RSA ve eliptik eğri anahtarlarını destekler; RSA’dan ECDSA’ya evrensel bir geçiş zorunluluğu yoktur. ECDSA’yı, güvenlik seviyesi, istemci uyumluluğu ve ölçülen sunucu maliyeti açısından değerlendirin:

• Uygun algoritma ve parametrelerde, karşılaştırılabilir klasik güvenlik seviyesi daha kısa eliptik eğri anahtarıyla sağlanabilir.
• İmzalama, doğrulama ve handshake maliyeti kütüphane, donanım, zincir ve iş yüküne bağlıdır; her senaryoda hızlanma beklemeyin.
• Yüksek trafikte CPU ve gecikmeyi temsilî istemcilerle ölçün; anahtar boyutu bütün sertifika zincirinin boyutu değildir.

Uyumluluk amacıyla birçok senaryoda hem RSA hem ECDSA sertifikanın sunucuda birlikte yapılandırıldığı 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. Sunucu genellikle istemci yeteneklerine uygun sertifikayı seçer; aynı handshake içinde her iki uç sertifikayı birden sunması veya her eski istemcinin başarılı olması garanti değildir. İki türün yenilenmesini ve sunulan zincirlerini ayrı izleyin.

TLS 1.3 ve modern cipher suite’ler

TLS sürümü sertifika geçerlilik takviminden ayrı bir protokol tercihidir. RFC 9325, TLS 1.0/1.1’in kullanılmamasını, TLS 1.2 için güvenli yapılandırmayı ve desteklendiğinde TLS 1.3’ün tercih edilmesini söyler. TLS 1.2’nin bütün kullanımını geçersiz ilan eden genel bir sertifika kuralı yoktur. Sunucu, yük dengeleyici ve istemci uyumluluğunu birlikte test edin:

• TLS 1.0/1.1’i ve SSL sürümlerini kaldırın; eski bağımlılıkları güncelleyin.
• TLS 1.2’de güncel güvenlik politikasına uygun ECDHE ve AEAD seçeneklerini değerlendirin; yalnız şifre paketi adını değiştirerek tüm yapılandırmayı güvenli saymayın.
• TLS 1.3’te şifre paketinin anahtar anlaşması veya sertifika imza algoritmasını seçmediğini hatırlayın. PSK ve 0-RTT kullanımı gibi seçenekleri ayrıca inceleyin; erken veride tekrar saldırısı riski vardır.

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 sonrası hazırlık için sertifika imzasını TLS anahtar anlaşmasından ayırın. NIST’in Ağustos 2024’te yayımladığı FIPS 203, 204 ve 205; ML-KEM, ML-DSA ve SLH-DSA’yı standartlaştırır. Bu, söz konusu algoritmaların genel güvenilen web sertifikalarında her CA ve tarayıcı tarafından kabul edildiği anlamına gelmez.

• Hibrit veya PQ anahtar anlaşması desteği, PQ imzalı sertifika desteğiyle aynı özellik değildir.
• Kriptografik envanterde sertifika anahtarı/imzası, TLS kütüphanesi, bağlantı algoritmaları ve veri saklama süresini ayrı kaydedin.
• CA, tarayıcı ve yazılımın açık destek beyanlarını izleyin; değişikliği önce uyumluluk, yük ve geri dönüş testinden geçirin.

Güncel TLS kütüphaneleri, yapılandırma yönetimi ve anahtar değiştirme süreçleri geçiş hazırlığını kolaylaştırır. Kabul politikası doğrulanmamış PQ sertifikasını üretime dağıtmayın. Mevcut mimarinin gelecekte hiçbir değişiklik gerektirmeyeceği veya belirli yılda hibrit sertifikaya geçileceği sonucu çıkarılamaz.

mTLS, istemci sertifikaları ve Zero Trust mimarilerde yeni rol

mTLS, sunucu doğrulamasına ek olarak istemcinin de sertifikayla kimliğini kanıtlayabildiği TLS kullanım biçimidir. Yönetim ve servis iletişiminde değerlendirilebilir; yeni CA/B web sertifikası takviminin bütün istemci sertifikalarına genişlemesi anlamına gelmez. Uygun örnekler:

• Yönetim panelinde kullanıcı yetkilendirmesi ve gerekirse IP kısıtlaması yanında istemci sertifikası istemek.
• Servisler arasında ayrı kimlikler, dar yetkiler ve izlenebilir yenileme ile mTLS kullanmak.
• Belirli uygulama erişiminde cihaz/istemci sertifikasını ek kontrol yapmak; bunu her VPN’in işlevsel karşılığı saymamak.

İç CA’nın güven dağıtımı, istemci sertifikası yaşam döngüsü ve erişim politikası ayrıca tasarlanır. mTLS kimlik doğrular; kullanıcının veya servisin her işlemi yapmaya yetkili olduğunu kendiliğinden belirlemez. Anahtar kaybı, iptal, kısa süre, yeniden kayıt ve acil erişim senaryolarını da planlayın.

Ö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.

Süreler kısalırken otomasyonu ve izlemeyi birlikte kurun

BR, her işletmenin belirli bir otomasyon ürününü kullanmasını şart koşmaz. Ancak sertifika sayısı ve yenileme sıklığı arttığında, doğrulama ve dağıtımın otomasyonu hata olasılığını azaltmaya yardımcı olur. İzleme ve sorumlu ekip olmadan otomatik süreç de başarısız kalabilir. Örnek bir planlama sorusu:

“Varsayımsal olarak 30–40 alan adı, bunların alt alanları ve farklı ortamları için sertifika yönetiyorsak, yenileme ve dağıtım hatasını nasıl fark eder ve düzeltiriz?” Bu sayı gerçek müşteri ölçümü veya otomasyon için zorunlu eşik değildir.

Pratik bir otomasyon stratejisi nasıl kurulur?

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

1. Envanter: Alan adı/SAN, ortam, DV/OV/EV, wildcard kapsamı, CA, anahtar konumu, sertifika bitişi ve sorumluyu kaydedin.
2. Öncelik: Ödeme, API ve yönetim gibi kritik işlemlerden başlayın; staging ve unutulmuş uçları envanter dışında bırakmayın.
3. İstemci ve dağıtım: cPanel, Plesk, DirectAdmin, Nginx, Apache veya Kubernetes bileşeninde gerçek CA/ACME desteğini doğrulayın. Talep başarısıyla yetinmeyin; anahtar izinlerini, atomik yüklemeyi, reload sonucunu ve dışarıdan sunulan zinciri kontrol edin.
4. DNS: ACME wildcard için DNS-01 desteğini ve gerekli DNS yetkisini planlayın. API anahtarını dar kapsamlı tutun; müşteri özel alanında doğrulama kaydı/delegasyonu ile trafik CNAME’ini karıştırmayın.
5. İzleme: Bitiş tarihi, yenileme/dağıtım hatası, durmuş zamanlayıcı ve eksik metrik için alarm oluşturun. Gönderim ve çözülme bildirimini test edin; sorumlu ve müdahale süresi belirleyin.
6. Hata yönetimi: CA rate limitlerini, ölçülü retry/backoff’u ve test ortamını kullanın. Yedek CA’nın CAA, hesap ve challenge uyumluluğunu önceden doğrulayın; geri dönüşte süresi dolmuş veya iptal edilmiş sertifikaya dönmeyin.

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

Gerçek müşteri sonucu olarak sunulmayan örnek bir e-ticaret yapısı düşünelim:

• 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.

Bu örnekte sertifika politikası, TLS yapılandırması ve ödeme uyumluluğu için ayrı kontroller gerekir:

• TLS 1.0/1.1’i kaldırıp uygun TLS 1.2/1.3 politikasını gerçek ödeme akışıyla test edin.
• Düzenlenme tarihine göre yukarıdaki 200/100/47 günlük tavanları uygulayın; gerçek sertifika süresine uygun erken yenileme ve dağıtım izleme kurun.
• CAA politikası kullanılıyorsa etkin ve yedek CA’leri doğru yetkilendirin.
• HSTS’yi çalışan HTTPS ve alt alan kapsamını doğrulayarak aşamalı açın; includeSubDomains/preload kararını ayrıca verin.
• OCSP stapling’i yalnız ilgili sertifika/CA ve istemci destekliyorsa değerlendirin. Let’s Encrypt OCSP hizmeti 6 Ağustos 2025’te sona erdi; güncel sertifikaları için evrensel stapling talimatı uygulanamaz.

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.example.com, musteri2.example.com).
• Bazı müşteriler, kendi alan adlarını sisteme getirip CNAME ile bağlamak istiyor.
• Yüzlerce veya binlerce sertifikada manuel takip, yenileme ve hata müdahalesinin işletim yükü büyür.

Çok kiracılı modelde otomasyon güçlü bir işletim tercihidir; BR tek bir mimariyi veya her özel alan için DNS-01 kullanımını dayatmaz. CA’nin desteklediği ve kontrol edebildiğiniz challenge yöntemini seçin. Örnek tasarım:

• Platform alt alanlarında wildcard kapsamını doğru hesaplayın: *.example.com, example.com veya a.b.example.com adını kapsamaz; gerekli SAN’ları ayrıca sağlayın.
• Müşteri özel alanında sahiplik/tenant eşlemesini ve challenge yetkisini doğrulayın. Trafik CNAME’i tek başına DNS-01 TXT kaydı yazma yetkisi vermez; ayrı delegasyon veya uygun HTTP doğrulaması gerekebilir.
• CA hesabı, DNS kimlik bilgileri, sertifika/anahtar dağıtımı ve müşteri ayrılışında kayıt temizliğini tenant sınırlarıyla yönetin.
• Sertifika bitişi, otomatik yenileme ve uçta sunulan sertifikayı merkezi izleyin; hatalı müşteri alanını diğer tenant’lara bağlamayın.

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

İntranet, yönetim paneli ve iç API’lerde özel PKI kullanılabilir. Kurum kökü genel uygulama güven depolarıyla dağıtılmıyorsa BR’nin genel TLS sunucu sertifikası takvimini bu sertifikalara otomatik uygulamayın. Kurum politikası yine kısa süre, denetim ve otomasyon hedefleyebilir.

Burada uygulanabilecek stratejiler:

• Panelde istemci sertifikasını doğrulayın; kullanıcı/cihaz kimliğine göre yetki, iptal ve kayıt politikası uygulayın.
• Mikroservislerde karşılıklı kimlik doğrulamasını dar servis yetkileriyle birleştirin; ele geçirilmiş yetkili servisin erişimini yalnız mTLS engellemez.
• İç CA için güven kökü dağıtımı, kısa süreli istemci sertifikaları, otomatik yenileme, anahtar koruması ve CA kurtarma planı oluşturun.

VPN, IP kısıtı ve mTLS farklı kontrollerdir. Seçimi uygulama erişimi, cihaz yönetimi, işletim yükü ve olay kayıtlarıyla değerlendirin; evrensel bir üstünlük veya daha kolay izleme sonucu varsaymayın.

Hosting sağlayıcısıyla hangi özellikleri doğrulamalısınız?

DCHost üzerinde paylaşımlı hosting, VPS, dedicated sunucu veya colocation kullanırken yönetim sorumluluğu ve erişim modeli değişebilir. Seçilen plan için şu koşulları doğrulayın:

• Gerçek sunucu/panel sürümü, etkin TLS protokolleri ve desteklenen istemci matrisi.
• RSA/ECDSA sertifika seçimi ve her iki zincirin ayrı yenileme/dağıtım desteği.
• AutoSSL veya ACME sağlayıcısı, doğrulama yöntemi, zamanlayıcı, yenileme hatası bildirimleri ve müdahale sorumlusu.
• OV/EV için desteklenen API/ACME ürünleri, kimlik doğrulama yenilemesi ve yetkili hesap yönetimi.

Destek görüşmesine envanteri, sertifika düzenlenme/bitiş tarihlerini, CA bilgilerini ve hassas veri içermeyen hata kayıtlarını hazırlayın. Yönetilen hizmet kapsamını, değişikliği kimin uygulayacağını ve ücret/erişim koşullarını teyit edin.

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

Öncelikli değişiklikler, tarihli sertifika süresi ve doğrulama koşullarıdır. ACME işletimi, CAA, tarayıcı CT politikası, TLS yapılandırması, ECDSA uyumluluğu ve mTLS/PQ hazırlıkları bunlarla ilişkili ama ayrı karar alanlarıdır. Hepsini tek bir evrensel zorunluluk listesi gibi uygulamayın.

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

1. Alan adı, sertifika, anahtar ve sorumluların envanterini çıkarın; düzenlenme tarihine göre geçerlilik ve doğrulama yeniden kullanım tavanını kontrol edin.
2. TLS sürümleri, şifre politikası ve RSA/ECDSA istemci uyumluluğunu test edin.
3. Desteklenen ACME/API yenilemesini güvenli dağıtım, reload kontrolü ve dış sertifika izlemesiyle tamamlayın.
4. CAA yetkilendirmesini, MPIC için doğrulama erişimini ve CT olay bildirimlerini inceleyin.
5. İç servislerde mTLS/özel PKI yaşam döngüsünü ayrı planlayın; PQ için envanter ve kontrollü geçiş hazırlığı yapın.

Değişikliklerin kabul ölçütü yalnız başarılı sertifika talebi değildir. Kritik kullanıcı işlemi çalışmalı, doğru sertifika uçta sunulmalı, hata alarmı ulaşmalı ve bir sonraki yenilemenin sorumlusu belli olmalıdır. Bu kontroller kesinti riskini azaltmaya yardımcı olur; kesintisizlik garantisi vermez.

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. Gereksinimleri CA ve tarayıcı politikasıyla doğrulayın; sağlayıcı desteğinin kapsamını ayrıca teyit ederek değişiklik ve geri dönüş planı hazırlayın.