Multi-domain SSL (SAN) ne zaman tercih edilmeli? Net karar rehberi

Multi-domain SSL (SAN, Subject Alternative Name) tek bir sertifika içinde birden çok alan adını (domain) barındırmaya yarar. Doğru zamanda kullanıldığında hem sertifika yönetimi hem de kurulum süreçleri ciddi şekilde hızlanır. Yanlış senaryoda ise maliyet ve operasyon yükü artar. Bu rehberde SAN sertifikanın tam olarak hangi koşullarda net avantaj sağladığını; hangi durumlarda ayrı sertifika daha doğru olduğunu sayısal ve operasyonel açıdan anlatıyorum.

Multi-domain SSL (SAN) tam olarak ne sağlar?

SAN sertifika, tek bir TLS sertifikası üzerinden birden fazla alan adını kapsar. Örneğin: - example.com - www.example.com - api.example.com - panel.example.com aynı sertifika altında tanımlanabilir.

Bu sayede her domain için ayrı sertifika satın alıp ayrı ayrı yükleme/yenileme yapma ihtiyacı azalır. Sertifikayı kullandığınız altyapıya göre avantaj değişir: - Birden çok vhost/hostname kullanan web sunucuları - Aynı IP üzerinde farklı domain’leri barındıran ters proxy (reverse proxy) - Birden fazla servis aynı ekosistemde çalışıyorsa (ör. web + API + panel)

SAN sertifikanın yönetim etkisi

SAN’ın operasyonel etkisi şuradan gelir: Sertifika yenileme (renewal) ve hata durumunda müdahale (sözgelimi yanlış zincir, eksik intermediate) tek noktada gerçekleşir. Bu; özellikle küçük ekiplerde ya da çok sayıda domain’i aynı anda yönetmek zorunda olan yapılarda belirgindir.

SAN sertifika ne zaman net şekilde tercih edilmeli?

Aşağıdaki senaryolarda SAN sertifika, ayrı sertifikaya göre daha az operasyon ve daha düşük yönetim maliyeti üretir. Her maddeyi NetKıyas’ta karşılaştırma mantığıyla “hangi problem çözülüyor” şeklinde ele alıyorum.

1) Aynı sunucuda/aynı ters proxy arkasında birçok hostname yönetiyorsanız

En yaygın kullanım budur. - Tek bir Nginx/Apache üzerinde birden fazla domain ya da subdomain - Aynı load balancer / reverse proxy üzerinde farklı host header’lar

Örneğin 10 domain barındıran bir sistemde, her domain için ayrı sertifika yönetmek şu riski büyütür: - Yenileme takvimini kaçırma - Her sertifikayı ayrı bağlama (certificate chain, key eşleştirme) - Farklı domain’lerde farklı hatalar raporlanması

SAN ile bu “tek sertifika + tek yenileme” modeline yaklaşır.

2) Ortak doğrulama (validation) süreçleri aynı kurumsal kimlik üzerinde yürütülüyorsa

Eğer tüm domain’ler aynı organizasyonla doğrulanıyorsa (kurumsal yapı, aynı e-posta/WHOIS/verification kanalları) sertifika alma süreci pratikleşir. Bu, özellikle wildcard kullanılmayan ama çoklu domain gerektiren durumlarda avantajdır.

3) Kısa sürede çok sayıda domain’i yayına almak istiyorsanız

Geliştirme → staging → prod geçişlerinde (ör. yeni müşteriler, kampanya domain’leri) kısa zaman penceresi kritik olur. - Tek seferde sertifikayı yükleyip tüm domain’leri çalıştırmak - Yenilemeyi de aynı sertifika döngüsüne oturtmak

Burada SAN, “sertifikayı her domain için ayrı ayrı alma” gecikmesini azaltır.

4) Sertifika maliyeti tek tek yerine paket mantığıyla daha iyi kontrol ediliyorsa

SAN sertifikada her sağlayıcının SAN sayısı ve fiyat modeli farklıdır. Ancak genel prensip şudur: - Tek bir SAN sertifikanın maliyeti, kapsadığı domain sayısı arttıkça daha “birim maliyet” avantajı yaratır.

Karar verirken basit bir karşılaştırma yapın: - Kapsamak istediğiniz toplam domain sayısı = D - Sağlayıcının SAN sertifikada kapsadığı maksimum hostname sayısı = M - SAN sertifikada birden fazla sertifika gerekiyorsa (D > M), kaç sertifika gerektiği = ceil(D / M)

Aşağıdaki tablo, “ürün seçimi” yaklaşımı için hesap mantığını netleştirir:

Senaryo	Ayrı SSL sayısı	SAN SSL sayısı (D/M)	Operasyon etkisi
2-3 domain	2-3	1	SAN genelde daha pratik
5-10 domain	5-10	1	SAN net avantaj, yönetim azalır
15-25 domain	15-25	2-3	SAN hâlâ mantıklı; yenileme tek/az noktada
50+ domain	50+	5-10	Genelde SAN tek başına çözmez; mimari revizyon gerekir

5) Hata senaryosunda tek noktadan yönetim istiyorsanız

Yanlış sertifika zinciri, yanlış SNI eşleşmesi, eksik ara sertifika gibi sorunlarda müdahale süresi önemlidir. SAN yaklaşımı, güncellemeyi tek bir sertifikaya topladığı için: - Envanter takibi kolaylaşır - Güncelleme adımı sayısı azalır - Log analizinde “aynı sertifika profili” üzerinden ilerlersiniz

SAN sertifika ne zaman doğru değildir? (Ayrı sertifika daha iyi olabilir)

SAN her problem için tek seçenek değildir. Aşağıdaki durumlarda ayrı sertifika daha kontrollü olur.

1) Domain’ler farklı bağımsız iş birimlerine aitse

Örneğin: - Bir domain pazarlama ekibi yönetiyor - Diğer domain ürün ekibi yönetiyor - Üçüncü domain tamamen ayrı bir marka

Bu durumda sertifikalar bağımsız yenilendiğinde izinler, onay süreçleri ve sorumluluklar daha net ayrılır. SAN sertifika ise tek sertifika üzerinden tüm domain’lere etki edebilir; bir domain değişikliği tüm sertifika yenilemesini tetikleyebilir.

2) Çok fazla domain var ve SAN limitine takılıyorsanız

Her sağlayıcı SAN için bir üst limit koyar. D, M’yi aşıyorsa iki/üç SAN sertifika bile yönetim karmaşıklığını azaltmaz. Bu noktada daha doğru yaklaşım şunlardan biri olur: - Reverse proxy katmanında SNI bazlı doğru sertifika dağıtımı - Yetkili CA (Certificate Authority) ile kurumsal sertifika yönetimi - Mümkünse grup bazlı sertifika planlama (bölümlere/hatlara göre)

3) Domain’lerde yaşam döngüsü çok farklıysa

Örneğin: - Bazı domain’ler yıl içinde kapatılıyor/taşınıyor - Diğerleri uzun süre sabit kalıyor

SAN sertifika, kapsamdaki domain’lerden birinin değişmesiyle tüm sertifikayı yenilemeye itebilir. Bu da maliyet ve risk yaratır.

SAN vs Wildcard vs Tek domain: Net karşılaştırma

Aynı ihtiyacı farklı sertifika tipleriyle çözebilirsiniz. Aşağıdaki tablo karar sürecini hızlandırır.

İhtiyaç	En uygun yaklaşım	Neden
Aynı kök domain altında çok sayıda subdomain	Wildcard SSL	`*.example.com` tek sertifikayla kapsar
Farklı kök domain’ler (example.com + example.org + example.net)	Multi-domain (SAN) SSL	Farklı domain’leri tek sertifikada toplar
Tek bir domain için kurumsal süreç	Tek domain SSL	Kapsam dar, yönetim basit
Çok sayıda domain (yüksek D) ve bağımsız yaşam döngüsü	Karma model	SAN limitleri ve yenileme tetikleyicileri dikkate alınır

Hangi durumda Wildcard yerine SAN seçilir?

Wildcard, yalnızca aynı kök domain içinde (*.example.com) doğru çalışır. Farklı kök domain’leri tek sertifikada toplamak gerekiyorsa SAN doğru araçtır.

Doğru SAN kapsamı nasıl belirlenir? (Pratik kontrol listesi)

SAN sertifikayı planlarken şu 8 maddeyi netleştirin. Bu maddeler yanlış kapsama bağlı “gereksiz yenileme” riskini azaltır.

Kapsanacak hostname sayısı (D): Sadece kök domain mi, www de var mı? API panel gibi alt hostlar dahil mi?
Sertifika sağlayıcının SAN limiti (M): Kaç hostname en fazla destekleniyor?
Yaşam döngüsü: Hangi domain’ler sık değişiyor (taşıma, kampanya, yeni müşteri)?
Doğrulama tipi: DV/OV/EV yaklaşımı ve doğrulama kanalları aynı mı?
Sunucu mimarisi: Nginx/Apache mi, load balancer mi, Kubernetes ingress mi?
SNI uyumu: Aynı IP üzerinde birden fazla hostname yönetiliyorsa SNI (Server Name Indication) gereksinimi var mı?
Yenileme süreçleri: Otomatik renewal yapılabiliyor mu, kontrol paneli üzerinden izleniyor mu?
Geri dönüş planı: Sertifika hatasında hızlı rollback nasıl yapılır?

Kubernetes/Ingress veya reverse proxy kullanıyorsanız dikkat

SAN sertifika yüklemek tek başına yeterli değildir. SNI üzerinden doğru sertifikanın doğru host’a servis edilmesi gerekir. Bu noktada hatalar genelde şu kaynaktan çıkar: - Yanlış secret/certificate chain bağlama - Ingress controller konfigürasyonunda host rule eşleşmemesi - Aynı sertifikanın birden fazla yerde farklı isimle tutulması

Maliyet ve operasyonu netleştiren mini hesap

SAN kararı için “birim maliyet + birim operasyon” yaklaşımı yapın.

1) Sertifikada kapsayacağınız domain sayısı: D 2) Maksimum SAN limiti: M 3) Gereken SAN sertifika adedi: S = ceil(D/M)

Ardından iki maliyeti düşünün: - Sertifika maliyeti: S adet sertifikanın yıllık bedeli - Operasyon maliyeti: Yenileme + dağıtım + olası düzeltme adımlarının sayısı

Genel olarak D yükseldikçe SAN’ın “yenileme adedi” etkisi azalır, ama S artarsa avantaj düşer. Bu nedenle SAN’ı “tek sertifika” değil “az sayıda sertifika” hedefiyle planlamak daha doğru olur.

NetKıyas karar önerisi: SAN’ı şu 3 şartta seçin

Aşağıdaki üç şart aynı anda sağlanıyorsa SAN sertifika genelde en doğru tercihtir:

Tek bir mimaride (aynı sunucu/reverse proxy) birden çok domain/hostname yönetiyorsunuz.
Domain’lerin yaşam döngüsü birbirine yakın (sık kapanmıyor/taşınmıyor).
Sağlayıcının SAN limiti içinde az sayıda sertifikayla ihtiyacınız karşılanıyor.

Bu şartlar yoksa, domain gruplarını ayırın ya da wildcard/tek domain yaklaşımıyla kapsama gidin.

Sonuç: Hızlı aksiyon planı

Karar vermeyi kolaylaştırmak için önce D’yi (toplam kapsanacak hostname) çıkarın, sonra sağlayıcının SAN limitini (M) öğrenin ve S = ceil(D/M) hesabını yapın. D küçükse SAN genelde pratik; D büyükse bile S az kalıyorsa SAN hâlâ mantıklıdır. Ancak domain’ler bağımsız ekiplere ve farklı yaşam döngülerine sahipse SAN kapsamını dar tutun ya da ayrı sertifikayla sorumluluk ayrımı yapın. Bu adımları yaptıktan sonra sertifikayı tek bir değişken (fiyat) üzerinden değil; yenileme ve dağıtım operasyonu üzerinden seçin.