Multi-Domain SSL (SAN) Ne Zaman Tercih Edilmeli? Net Rehber

Giriş

Multi-domain SSL (SAN, Subject Alternative Name) tek bir sertifika içinde birden fazla alan adını (domain) barındıran bir yapı sunar. Doğru yerde kullanıldığında sertifika yönetimini sadeleştirir, maliyeti ve operasyon yükünü düşürür; yanlış senaryoda ise güncelleme ve uyumluluk sorunları çıkarabilir. Bu rehberde SAN sertifikanın ne zaman tercih edilmesi gerektiğini; maliyet, teknik kısıtlar, güvenlik ve yönetim açısından net şekilde ele alacağız.

SAN sertifika neyi çözer, neyi çözmez?

SAN sertifika, tek bir sertifika dosyasıyla birden fazla FQDN (tam alan adı) için TLS şifrelemesi sağlar. Örneğin aynı altyapıda şu isimleri tek sertifikada tanımlayabilirsiniz: - example.com - www.example.com - blog.example.com - mail.example.com

Bu yapı özellikle şu sorunları çözer: - Sertifika sayısını azaltma: Aynı CA (Certificate Authority) üzerinden tek sertifikayla çok sayıda alan adı yönetirsiniz. - Zamanlama senkronu: Yenilemeler aynı sertifika üzerinden planlanır. - Operasyonel tutarlılık: Kontrol paneli ya da otomasyon (ACME/sertifika yöneticisi) yerine daha basit bir “tek sertifika” modeli uygulanır.

Ama SAN sertifika her ihtiyacın “tek çözüm”ü değildir: - Bir alan adı farklı bir ekosistemde (ör. farklı bir load balancer/WAF, farklı egress IP/route) tamamen ayrık ise yönetim yine de zorlaşabilir. - Sertifika içeriği genişledikçe (çok fazla SAN kaydı) bazı sağlayıcı/CA sınırları ve etki alanı doğrulama (DV/OV/EV) pratikleri devreye girebilir. - Sertifika yaşam döngüsünde tek sertifika yenilense bile, tüm alan adlarının etkilenme riski tek noktadan yönetildiği için plan doğru yapılmazsa tüm domainler aynı anda etkilenebilir.

SAN sertifikada dikkat edilmesi gereken temel bileşen

SAN sertifikanın üzerinde çalıştığı temel mantık şudur: Sertifika doğrulama sırasında CA, sertifikadaki domain adlarının doğruluğunu ister. Bu nedenle “sonradan eklenecek domainleri” satın almadan önce planlamak kritiktir.

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

Aşağıdaki durumlar, SAN sertifikanın belirgin fayda sağladığı senaryolardır. Her madde, pratik bir kontrol noktasıyla birlikte verilmiştir.

1) Aynı altyapıda birden fazla alt alan adı (subdomain) yönetiyorsunuz

Örnek senaryo: Tek bir uygulama yığını (Kubernetes/In-house platform, tek VDS/VPS, tek load balancer) üzerinde www, api, app, admin gibi alt alan adları aynı TLS altyapısını paylaşıyor.

Net karar ölçütü: Aynı TLS termination noktası varsa (ör. aynı reverse proxy ya da aynı load balancer) SAN mantıklıdır.

2) “Birden fazla web sitesi” aynı sunucuda veya aynı ağda çalışıyor

Kurumsal yapılarda birden fazla site aynı hosting hesabında ya da aynı VDS üzerinde çalışır: - site1.com ve site1.com.tr - site2.com ve www.site2.com - Portföy sayfaları ve kampanya sayfaları

Net karar ölçütü: Domainler aynı makineye/aynı kontrol paneli kurulumuna bağlıysa sertifikayı bölmek yerine SAN tek sertifika ile operasyonu düşürür.

3) Sertifika yenileme süreçlerini standardize etmek istiyorsunuz

Ekiplerde en sık hata “farklı sertifikaların farklı tarihlerde yenilenmesi”dir. SAN ile tek sertifikayı tek takvimde yenileyerek: - yenileme kaçırma riskini, - acil müdahale ihtiyacını - kontrol paneli/otomasyon karmaşasını azaltırsınız.

Net karar ölçütü: Net bir teslim tarihi ve standart bir iş akışı (ör. her 90 günde bir yenile kontrolü) kurabiliyorsanız SAN avantaj sağlar.

4) Maliyet/administrasyon dengesini tek noktada yönetmeniz gerekiyorsa

Her domain için ayrı sertifika, özellikle kısa vadeli kampanya domainlerinde maliyet ve operasyon yükü yaratır. SAN sertifika, domain sayısı arttıkça yönetim ölçeğini iyileştirir.

Net karar ölçütü: 2-3 domain ile bile yönetim maliyeti hissediliyorsa SAN sertifika “operasyon kazancı” sağlar. 1-2 domain’de ise ayrı sertifika genelde daha sade olur.

5) Tek kontrol panelinde (Plesk/cPanel/DirectAdmin) birden fazla domain var

Kontrol paneli tarafında sertifika yönetimi çoğu zaman aynı ekranda yapılır. SAN sertifika tek sertifika olarak yerleşir.

Net karar ölçütü: Kontrol panelinizin sertifika kurulum arayüzünde SAN sertifikaları pratik şekilde yönetebildiği bir yapı varsa SAN seçimi netleşir.

Ne zaman SAN yerine ayrı SSL (single-domain) daha mantıklı?

SAN her durumda doğru değildir. Aşağıdaki durumlarda tek domain sertifikalar daha kontrollü bir model sunar.

1) Domainler farklı kritik sistemlerde sonlanıyor (TLS termination farklı)

Örneğin bir domain CDN/WAF üzerinden, diğeri doğrudan origin üzerinde TLS sonlandırıyor.

Net karar ölçütü: TLS sonlanma noktası farklıysa sertifikayı tek pakette birleştirmek, sorun yaşandığında etkilenme alanını genişletir.

2) Domainlerden biri başka bir CA veya doğrulama rejimiyle yönetilecekse

DV/OV/EV doğrulama rejimleri ve CA tercihi değişebiliyorsa tek sertifikada toplamak ileride uyumsuzluk yaratır.

3) Çok farklı yenileme takvimleri ve “bırakılacak domainler” varsa

Bir domainin yıl içinde devre dışı kalacağı net ise, SAN sertifika içinde tutulması yenileme sonrası “gereksiz kullanım” doğurur.

Teknik ve operasyon riskleri: SAN seçerken net kontrol listesi

SAN sertifika tercih ettiğinizde riskleri azaltmak için şu kontrolleri uygula.

1) Sertifika limitleri ve CA politikası

Bazı sağlayıcılar bir sertifikada kaç SAN kaydı sunar sorusunu sınırlarla belirler. Ayrıca wildcard (*.example.com) ile SAN kaydı birlikte kullanılabilirlik değişebilir.

Kontrol: Satın almadan önce “kaç domain/ad” hedeflediğinizi CA/sağlayıcı sınırlarıyla eşleştirin.

2) Yenileme sırasında tüm domainlerin etkilenmesi

Tek sertifika kullanımı, tek bir başarısız yenileme durumunda birden fazla domainin etkilenmesi anlamına gelir.

Kontrol: Yenileme işlemini “kademeli geçiş” mantığıyla planlayın: - Yeni sertifikayı kuracağınız arayüzü (reverse proxy, load balancer, kontrol paneli) önceden belirleyin. - Yenilemeden önce konfigürasyonu test ortamında doğrulayın.

3) Doğru “sertifika zinciri” (chain) kurulumu

Yanlış chain, bazı istemcilerde güven hatası oluşturabilir.

Kontrol: Sağlayıcının sunduğu intermediate/chain dosyalarını doğru sırayla konfigüre ettiğinizi doğrulayın.

4) Eski TLS ayarları ve SNI (Server Name Indication)

Modern çoklu domain kurulumlarında SNI kullanımı yaygındır. Eski proxy’lerde SNI davranışı düzgün değilse yanlış sertifika sunulabilir.

Kontrol: Sunucu/Proxy sürümünüz SNI’yı doğru destekliyor mu kontrol edin.

SAN sertifika ve wildcard karışıklığı: Hangisi daha doğru?

Bazı ekipler *.example.com wildcard ile SAN’ı karıştırır. Kısa ve net ayırım: - Wildcard: Aynı kök domainin alt alan adlarını kapsar (ör. a.example.com, b.example.com). - SAN: Düz alan adları ve alt alan adlarını listeleyerek birden fazla ismi tek sertifikada toplar.

Hızlı karar tablosu

Pratik örnek senaryolar (Net senaryo eşleştirme)

Senaryo A: Kurumsal marka sitesi + API alt alan adı

• example.com
• www.example.com
• api.example.com Aynı reverse proxy (Nginx/Traefik) arkasında çalışıyor.

Tercih: SAN sertifika. Beklenen fayda: Tek sertifika, tek yenileme takvimi, yönetim sade.

Senaryo B: Bir domain CDN üzerinden, diğeri origin’de tutuluyor

• example.com CDN WAF arkasında
• dashboard.example.com origin’de farklı policy ile

Tercih: Ayrı sertifikalar. Beklenen fayda: Sorun olasılığında etkilenme alanı daralır, her policy ayrı uygulanır.

Senaryo C: Büyüyen panel: 1 yıl içinde 5-10 yeni alt alan adı eklenecek

Bu noktada SAN seçimi yapılabilir, ancak “sertifika içinde kaç SAN kaydı” konusu kritik olur.

Tercih: Küçük SAN ile başlamak + kurulum planını otomasyona bağlamak. Beklenen fayda: İlk günden gereksiz geniş paket yerine sınırları doğru yönetirsiniz.

Kontrol paneli ve sunucu tarafında kurulum doğrulaması (kısa ama net)

SAN sertifikayı kurduktan sonra mutlaka doğrulama yapın:

1) Her domain için ayrı ayrı doğrulayın

Özellikle şunları test edin: - https://example.com - https://www.example.com - https://api.example.com

2) İstemci tarafında sertifika bilgisi kontrolü

Tarayıcıda kilit simgesinden sertifika ayrıntılarını görün. Sertifikadaki SAN listesinin ilgili FQDN’i içerdiğini doğrulayın.

3) Otomasyon kullanıyorsanız “yenileme sonrası” kontrol

Yenilemeden sonra sertifikanın doğru dosya/konfigürasyona yüklendiğini doğrulayın. Bu aşama, en sık gözden kaçan operasyondur.

Sonuç: Hızlı aksiyon planı

SAN sertifika; aynı TLS sonlanma noktasını paylaşan, birden fazla domaini tek sertifika yönetimi altında standardize etmek isteyen ve yenileme takvimini tek akışa bağlamak isteyen ekipler için net fayda sağlar. İlk adım olarak mevcut mimarinizi yazın: Domainler hangi reverse proxy/load balancer/çözüm üzerinden çıkıyor? Ardından hedef domain sayısını (SAN kaydı limitleriyle birlikte) netleştirip “tek sertifika ile toplama” kararını verin. Bu planı çıkarınca SAN seçimi riskleri kontrol altına alarak yönetim yükünü belirgin şekilde azaltır.

Aksiyon: Mevcut domain listenizi çıkarın, TLS sonlanma noktalarını işaretleyin ve SAN yerine ayrı sertifikaya ihtiyaç duyacağınız noktaları (farklı proxy/policy, farklı CA doğrulama rejimleri, farklı yenileme takvimi) netleştirin. Buna göre SAN sertifikayı küçük bir paketle başlatın ya da ayrı sertifikaya geçin; her iki durumda da yenileme sonrası test adımını iş akışına ekleyin.