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

SSL sertifikası (certificate) bir web sitesinin tarayıcı ile şifreli konuşmasını sağlar. Fakat birden fazla alan adı (domain) yöneten ekiplerde tek tek sertifika almak maliyeti artırır, yönetimi zorlaştırır. Multi-domain SSL ise tek sertifikaya birden fazla alan adını (SAN, Subject Alternative Name) dahil eder. Bu yazıda SAN’ın ne zaman mantıklı olduğunu; hangi durumlarda tek domain SSL’nin daha doğru tercih olacağını net eşiklerle ele alacağım.

SAN (Multi-domain) SSL ile tek domain SSL arasındaki temel fark

SAN sertifikası tek bir sertifika dosyasında birden çok alan adını barındırır. Örneğin aynı sertifika; example.com, www.example.com, api.example.com ve hatta bazı durumlarda farklı alt alan adlarını kapsar.

Tek domain SSL (single-domain) ise yalnızca belirli bir FQDN’i (Fully Qualified Domain Name) ya da bazı ürünlerde yalnızca apex domain’i hedefler. Ürün modeline göre www ayrı sertifika gerektirebilir.

Pratik sonuçlar

• Yönetim: SAN’da sertifika sayısı azalır; yenileme, kurulum ve hatırlatma süreçleri kolaylaşır.
• Yer değiştirme riski: Yanlış kurulum ya da eksik bağlama durumunda etkisi daha geniş olabilir.
• Maliyet: SAN genellikle tek tek sertifika almaktan daha avantajlı fiyatlandırılır; ancak her ürün sağlayıcıya göre değişir.

Multi-domain SSL (SAN) hangi durumlarda “doğru seçim” olur?

SAN’ı tercih etmek mantıklı olduğunda karar genellikle şu kriterlerden birine dayanır: “Sertifikayı sık değiştiriyorsun ama domain sayısı yönetilebilir”, “aynı doğrulama yapılıyor” veya “tek merkezden yönetmek istiyorsun”. Aşağıdaki senaryolar bu kapsama girer.

1) Bir marka altında birden fazla subdomain’i birlikte yönetiyorsun

Örnek: example.com, www.example.com, shop.example.com, api.example.com.

Bu durumda SAN şu iki nedenle netleşir: - Tek sertifikayı web sunucuna (Nginx/Apache) bağlayıp aynı TLS ayarları ile devam edersin. - Yenileme zamanı geldiğinde birden çok sertifikayı tek tek kontrol etmezsin.

Net eşik: Aynı zamanda yönetilen alan adı sayısı 3-5 veya daha fazla ise SAN genellikle daha az operasyon yükü getirir.

2) Aynı ekiple çalışan birden fazla web projesi aynı domain ailesine bağlıysa

Bir kuruluş; aynı kök domainde farklı servisleri barındırır: app.example.com, panel.example.com, status.example.com gibi. Bu tip projelerde TLS ayarları ve sertifika yenileme süreçleri aynı takvimde yürütülür.

SAN, “tek takvim – tek sertifika” yönetimi sağlar.

3) “Sık sertifika yenileme” operasyonu kritikse

Bazı ortamlarda otomatik yenileme (renewal) ve dağıtım (deployment) süreçleri vardır. SAN sayesinde sertifika sayısı düştüğü için: - DevOps tarafında dağıtım adedi azalır. - Kontrol listesi (checklist) daha kısa olur.

Net öneri: CI/CD ile sertifika dosyası dağıtıyorsan ve birkaç alan adını aynı pipeline ile güncelliyorsan SAN avantaj sağlar.

4) Tek bir kontrol panelinden (control panel) sertifikayı yönetmen gereken senaryolar

cPanel / Plesk / benzeri kontrol panellerinde sertifika yönetimi çoğunlukla “sertifika yükle” mantığıyla ilerler. Domain sayısı arttıkça yükleme ekranı, doğrulama adımı ve hata yakalama noktası çoğalır.

SAN ile bu karmaşıklık azalır.

Ne zaman SAN yerine tek domain SSL daha doğru olur?

SAN her durumda daha iyi değildir. Aşağıdaki durumlarda tek domain yaklaşımı daha güvenli ve daha esnek olur.

1) Domainler farklı organizasyon birimleri tarafından yönetiliyorsa

Aynı sertifikada birden fazla alan adını birleştirdiğinde yenileme sorumluluğu ortaklaşır. Farklı ekipler farklı takvim, farklı onay ve farklı DNS sorumluluğu yürütüyorsa bu ortak yönetim pratikte çatışmaya neden olur.

Net eşik: Domainlerin sorumluluğu farklı ekiplerdeyse ve yenileme/plan değişikliği sık yaşanıyorsa single-domain daha doğru seçimdir.

2) Domainlerden biri farklı doğrulama süreci gerektiriyorsa

Bazı doğrulama modelleri (DV/OV/EV) veya doğrulama adımları (DNS doğrulama, web doğrulama) ürün bazında değişebilir. Eğer bir alan adında doğrulama modeli/kanıt sunumu farklıysa SAN’da kapsamı aynı anda yönetmek zorlaşır.

3) Güvenlik veya izolasyon hedefin “etki alanını daraltmak” ise

SAN sertifikada bir sorun çıkarsa (ör. yanlış bağlama, yanlış zincir, hatalı ara sertifika paketi) etki alanı daha geniş olabilir.

Kapsamlı izolasyon istiyorsan tek domain sertifikalarla “tek hata – tek site” yaklaşımı daha kontrollüdür.

4) Çok fazla domain eklenmesi planlanıyorsa

SAN sertifikaların içinde belirli sayıda alan adı kapsanır; sağlayıcıya göre limitler değişir. Domain sayısı hızlı büyüyorsa tek tek sertifikalar veya farklı stratejiler daha ölçeklenebilir olabilir.

Net kontrol: Sertifika sağlayıcının “SAN limit” bilgisini kontrol etmeden SAN’ı büyük domain portföyüne yayma.

SAN sertifikada maliyet ve limitler nasıl değerlendirilir?

SAN’ın fiyat/limit avantajı ürün gamına göre değişir, bu yüzden yaklaşımı “tek bir fiyata indirgemeden” ölçmek gerekir.

Karşılaştırma için kontrol listesi (ürün sayfasından)

• SAN sertifikada desteklenen maksimum alan adı sayısı
• Sertifikanın yenileme fiyatı (ilk alım değil, renewal)
• DV/OV/EV doğrulama seviyesi
• DNS doğrulama için gereken kayıt türleri (çoğu zaman TXT)
• Sertifika kurulumu için gereken zincir bilgileri (fullchain)

Küçük bir karar tablosu

Aşağıdaki tablo, hangi tarafa eğileceğini hızlı görmen için hazırlanmıştır.

Kurulum ve operasyon riskleri: SAN neyi “kolaylaştırır”, neyi “zorlaştırır”?

SAN’ın faydası yönetim yükünü azaltmaktır; fakat tek sertifika ile çok alan adı yönetmek aynı zamanda birkaç teknik hassasiyet getirir.

1) Yanlış SNI / yanlış host eşleştirmesi

Modern TLS’te aynı IP üzerinde birden çok site çalıştırılabilir. Bu durumda sunucu tarafında SNI (Server Name Indication) doğru host ile eşleşmelidir.

SAN kullanırken, sertifikayı yanlış server_name veya yanlış vhost’a bağlarsan tarayıcı hataları tüm kapsama alanlarını etkileyebilir.

2) Fullchain / intermediate zinciri eksikse etkisi büyür

Sertifikada “root” dışında intermediate zinciri eksikse bazı istemciler doğrulamayı tamamlayamaz. Tek site yerine çoklu domainleri kapsıyorsan kullanıcı etkisi daha geniş olur.

3) Yenileme sonrası dağıtım adımını atlamak

Otomatik yenileme yapan sistemlerde bile güncel sertifikayı yükleme adımı unutulursa (ör. Nginx reload veya kontrol paneli üzerinden yeniden yükleme) etki çok alan adında görünür.

Net öneri: Yenileme sonrası “sertifika dosyası doğru mu, chain doğru mu, web sunucuda doğru host’a yüklendi mi?” doğrulamasını standart kontrol olarak tanımla.

DNS ve doğrulama tarafı: SAN ile süreç nasıl değişir?

SAN’da alan adları sayısı arttıkça doğrulama adımları da artabilir. Genelde iki durum görülür:

• DNS doğrulaması (çoğu sağlayıcı TXT kaydı ister)
• Web tabanlı doğrulama (farklı klasör/HTTP yanıtı ister)

DNS doğrulamada pratik akış

1. Sağlayıcı, doğrulama için her alan adı veya kök için TXT kaydı ister.
2. DNS eklenir.
3. Sağlayıcı doğrulamayı tamamlar.
4. Sertifika yayımlanır.

Net fark: SAN’da doğrulama adımları birden fazla alan adını kapsayabildiği için TXT kaydı yönetimi daha fazla düzen gerektirir. Ancak tek sertifika yayımlandığı için yayınlandıktan sonraki kurulum genellikle daha basit kalır.

Net karar: SAN mı, tek domain mi? Hızlı seçim formülü

Aşağıdaki formül, kararını “tahmin” yerine ölçülebilir başlıklara bağlar.

SAN’ı seç

Şu üç koşulun en az ikisi sağlanıyorsa SAN doğru başlangıçtır: - Aynı kök domainde 3-5+ alt alan adı aktif kullanılıyor - Sertifikayı yenileme/distribüsyon süreci otomatik ya da standartlaştırılmış - Kontrol paneli veya sunucu mimarisi tek sertifika ile toplu yönetimi destekliyor

Tek domain SSL’yi seç

Şu koşullardan en az biri varsa tek domain daha uygun olur: - Domain sorumlulukları farklı ekiplerde veya farklı takvimde yönetiliyor - Doğrulama modeli/validasyon yaklaşımı farklı - İzolasyon hedefin yüksek ve etki alanını daraltmak istiyorsun

Güvenli uygulama önerileri (SAN kullanırken)

SAN kararını verdikten sonra kaliteyi belirleyen kısım “kurulum ve doğrulama disiplini”dir.

Minimum kontrol listesi

• Sertifikayı yüklemeden önce hedef host eşleşmesini doğrula (server_name / vhost)
• Sertifika zinciri olarak fullchain kullandığını kontrol et
• Yenileme sonrası sunucuda reload/restart yapıldığını doğrula
• Tarayıcıda ve gerekiyorsa openssl ile doğrulama yap

Örnek doğrulama komutu

Sunucu tarafında sertifikanın hangi isimleri kapsadığını görmek için kullanılabilir: openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text

(Çıktıda “Subject Alternative Name” bölümünü kontrol et.)

Sonuç: SAN’ı “kapsam yönetimi” için kullan, izolasyon gerektiğinde tek domain seç

Multi-domain SSL (SAN), aynı marka/ekosistem içinde birden fazla alan adını tek sertifika ile yönetmen gerektiğinde net biçimde avantaj sağlar. Özellikle aynı kök domainde 3-5+ subdomain, standart yenileme-distribüsyon süreçleri ve tek kontrol paneli üzerinden yürütülen operasyonlarda SAN tercih edilmelidir. Buna karşılık domain sorumlulukları ayrıştığında, doğrulama süreçleri farklılaştığında veya etki alanını daraltmak istediğinde tek domain SSL daha kontrollü olur.

Aksiyon önerisi: Elindeki domain listesini kök domaine göre gruplandır, her grupta kaç FQDN olduğunu say ve sorumluluk/validasyon farklılığını işaretle. Bu iki ölçümle 1-2 senaryoda SAN’a mı yoksa tek domain yaklaşımına mı daha doğru başladığını netleştir.