Wildcard SSL mi SAN (Multi‑Domain) Sertifika mı? E‑Ticaret ve Çok Alan Adlı Yapılar İçin Rehber

E‑ticaret ya da çok alan adlı (multi‑domain) bir mimari kurarken kaç çekirdek, ne kadar RAM sorularını çözmek genelde daha kolaydır. Asıl kafa karıştıran noktalar çoğu zaman DNS ve SSL tarafında ortaya çıkar. Aynı markanın birden fazla alt alanı, farklı ülke siteleri, ödeme sayfaları, API uçları, hatta ayrı markalar devreye girdikçe şu soru tekrar tekrar masaya gelir: Wildcard SSL mi yoksa SAN (Multi‑Domain) sertifika mı kullanmalıyız?

DCHost ekibi olarak gördüğümüz tablo net: Yanlış seçilen sertifika tipi kısa vadede pratik görünse de uzun vadede yenileme krizleri, karmaşık DNS ayarları, beklenmedik tarayıcı uyarıları ve hatta satış kaybına kadar giden sonuçlar doğurabiliyor. Bu yazıda, tamamen pratik senaryolardan yola çıkarak Wildcard ve SAN SSL sertifikalarını teknik, operasyonel ve güvenlik boyutlarıyla ele alacağız. E‑ticaret siteleri, ajanslar, SaaS ve çok markalı yapılarda hangi durumda hangisini tercih etmeniz gerektiğini somut kriterlerle netleştireceğiz.

SSL Sertifika Türlerini Doğru Konumlandırmak

Önce kısa bir çerçeve çizelim: SSL/TLS sertifikalarını iki eksende düşünebilirsiniz:

• Kimlik doğrulama seviyesi: DV, OV, EV (alan adı, kurum, genişletilmiş doğrulama)
• Kapsam türü: Tek alan adı, Wildcard, SAN (Multi‑Domain)

Kimlik doğrulama seviyeleri (DV/OV/EV) ile kapsam türü (Wildcard/SAN) birbirinden bağımsız kavramlardır. Örneğin DV Wildcard, OV SAN gibi kombinasyonlar mümkündür. Bu yazıda ağırlıklı olarak kapsam türü tarafına odaklanacağız, ancak DV/OV/EV ayrımını daha net görmek isterseniz DV, OV, EV ve Wildcard SSL türleri arasındaki farkları anlattığımız rehbere mutlaka göz atın.

Temel hatırlatma:

• Tek alan adı sertifikası: Sadece tek bir FQDN’i (örneğin www.ornek.com) kapsar.
• Wildcard sertifika: Belirli bir alanın birinci seviye tüm alt alanlarını (örneğin *.ornek.com) kapsar.
• SAN (Multi‑Domain) sertifika: Birden çok farklı alan adını ve/veya alt alanı aynı sertifika içinde barındırır.

Wildcard SSL Nedir, Neleri Kapsar, Neleri Kapsamaz?

Wildcard SSL, kabaca *.alanadiniz.com formatında üretilen ve o alanın birinci seviye tüm alt alanlarını kapsayan sertifika tipidir. Örneğin:

• *.magazam.com için aşağıdakiler kapsama dahildir:
  • www.magazam.com
  • api.magazam.com
  • cdn.magazam.com
  • pay.magazam.com vb.
• Ancak şunlar kapsama dahil değildir:
  • magazam.com (kök alan adı, çoğu sertifika sağlayıcıda ayrıca eklenmelidir)
  • v2.api.magazam.com (ikinci seviye alt alan)
  • magazam.com.tr gibi farklı TLD’ler

Yani Wildcard, tek bir alanın etrafındaki alt alan ormanını güvenceye almak için tasarlanmış bir yaklaşımdır. Özellikle “www, shop, cdn, img, api” gibi klasik alt alan kalıplarını tek bir hamlede çözmek istediğinizde hayat kurtarır.

Wildcard SSL’in Avantajları

• Yeni alt alan açma özgürlüğü: Önceden hangi alt alanlara ihtiyaç duyacağınızı bilmek zorunda değilsiniz. Gelecekte blog.magazam.com ya da beta.magazam.com açmak istediğinizde ek bir sertifika işlemi yapmanız gerekmez.
• Daha basit sertifika envanteri: Tek bir alan için onlarca ayrı sertifika yerine, tek Wildcard sertifika ile yönetim yükünü azaltırsınız.
• Let’s Encrypt ile otomasyon imkânı: DNS‑01 challange ile Wildcard sertifikaları otomatik üretip yenileyeceğiniz bir altyapı kurduğunuzda, manuel yenileme derdini neredeyse tamamen ortadan kaldırabilirsiniz.
• Geliştirme/staging ortamları için pratik: dev.magazam.com, stg.magazam.com, test.magazam.com gibi ortamlar için de aynı sertifikayı kullanabilirsiniz.

Wildcard SSL’in Dezavantajları ve Riskleri

• Tek anahtar – çok nokta riski: Aynı özel anahtarı (private key) birden çok sunucuya dağıttığınızda, bu anahtarı ele geçiren bir saldırgan *.alanadiniz.com altındaki tüm host’ları taklit edebilir.
• Bir seviye ile sınırlı hiyerarşi: *.alanadiniz.com sertifikası v2.api.alanadiniz.com gibi çok seviye alt alanları kapsamaz. Karmaşık mikroservis mimarilerinde bu sınırlama sıkıntı olabilir.
• Birden çok marka / TLD için uygun değil: Hem magazam.com hem magazam.com.tr hem de marka2.com gibi alanlarınız varsa, tek bir Wildcard ile bunların hepsini kapsayamazsınız.
• Yetki paylaşımı zorlaşır: Farklı ekipler (örn. ajans, alt yüklenici, üçüncü parti entegratör) farklı alt alanlardan sorumluysa, hepsi aynı sertifikayı ve anahtarı paylaşmak zorunda kalır; bu da güvenlik ve sorumluluk takibini zorlaştırır.

SAN (Multi‑Domain) SSL Nedir, Nasıl Çalışır?

SAN (Subject Alternative Name) alanı, bir sertifikanın birden fazla alan adını ve alt alanı kapsamasını sağlayan TLS/SSL özelliğidir. Pratikte “Multi‑Domain SSL” diye gördüğünüz sertifikalar teknik olarak SAN alanı dolu sertifikalardır.

Örneğin tek bir SAN sertifikası aşağıdakilerin tamamını aynı anda kapsayabilir:

• www.magazam.com
• magazam.com
• www.magazam.com.tr
• api.magazam.com
• www.markab.com
• odeme.magazam.com

Tarayıcı, TLS el sıkışması (handshake) sırasında sertifikada yer alan SAN listesini kontrol eder ve bağlandığı host adının bu listedeki değerlerden biriyle eşleşip eşleşmediğine bakar. Eşleşme varsa bağlantı güvenli kabul edilir.

SAN SSL’in Avantajları

• Farklı alan adlarını tek çatı altında toplar: Farklı markalarınız, coğrafi siteleriniz (örn. .com, .com.tr, .de) ya da farklı projeleriniz varsa tek bir SAN sertifikası ile hepsini koruyabilirsiniz.
• Alan adı başına daha net yetkilendirme: Hangi alanların sertifika altında olduğu SAN listesinde açıkça görünür. Bu, denetim ve dokümantasyon açısından şeffaflık sağlar.
• Çok markalı e‑ticaret ve marketplace’ler için esnek: Örneğin magaza1.com, magaza2.com, magaza3.com gibi domain’leri aynı gateway arkasında koşturuyorsanız, ortak bir SAN sertifikası kullanabilirsiniz.
• EV/OV ile birlikte kullanılabilir: Kurumsal firmalar için hem şirket isminin sertifikada görünmesini (OV/EV) hem de çok alan adı kapsamasını aynı anda sağlayabilirsiniz.

SAN SSL’in Dezavantajları

• SAN listesi yönetimi: Yeni bir alan adı eklendiğinde genellikle sertifikayı yeniden üretmek gerekir. Bu da otomasyonu kurgulamadıysanız operasyonel yük oluşturur.
• Maksimum alan adı limiti: Çoğu CA, tek bir SAN sertifikasında izin verdiği alan adı sayısını sınırlar. Onlarca, yüzlerce alan adı olan ajans ve SaaS yapılarında bu limiti planlamanız gerekir.
• Tek sertifika – çok müşteri riski: Ajansların sık yaptığı hata: Tüm müşteri sitelerini tek SAN sertifikasına doldurmak. Bir müşteriyle yollar ayrıldığında ya da bir domain taşındığında, sertifikayı bölmek ve yeniden tasarlamak zorunda kalırsınız.

E‑Ticaret Senaryolarında Wildcard vs SAN Karşılaştırması

Teoriyi kenara bırakıp gerçek hayattaki yaygın senaryolara bakalım. Her senaryo için hangi sertifika tipinin daha mantıklı olduğuna dair net tavsiyeler paylaşacağız.

Senaryo 1: Tek Marka, Çok Alt Alan (Klasik E‑Ticaret)

Alan adlarınız şöyle olsun:

• magazam.com (kök)
• www.magazam.com (web)
• api.magazam.com (REST/GraphQL API)
• img.magazam.com (görseller)
• cdn.magazam.com (CDN origin)
• pay.magazam.com (ödeme)

Bu durumda tek marka ve tek TLD çevresinde dönen bir ekosistemden bahsediyoruz. Genellikle en mantıklı yaklaşım:

• Bir adet Wildcard SSL: *.magazam.com
• Gerekirse kök alan adı (magazam.com) için ekstra SAN girişi veya ayrı bir DV sertifika

Böyle bir mimaride Wildcard sertifika size şu avantajları sağlar:

• Yeni alt alanlar (örn. beta.magazam.com, m.magazam.com) için ekstra işlem yapmazsınız.
• CI/CD sürecinize Let’s Encrypt entegrasyonu ile otomatik SSL yenileme eklerseniz, sertifika yönetimi büyük ölçüde arka planda kalır.

Burada kritik nokta, ödeme sayfası (pay.magazam.com) gibi PCI DSS’e dokunan bileşenleri barındırdığınız sunucularda anahtar yönetimini daha sıkı yapmanızdır. Bu konuyu derinlemesine ele aldığımız PCI DSS uyumlu e‑ticaret hosting rehberine de göz atabilirsiniz.

Senaryo 2: Çok Ülke, Çok TLD (Global Mağaza)

Daha büyük çaplı bir e‑ticaret yapısında şu kombinasyonu düşünelim:

• www.magazam.com (global)
• www.magazam.com.tr (Türkiye)
• www.magazam.de (Almanya)
• www.magazam.fr (Fransa)

Tek marka ama birden fazla ülke ve TLD var. Çoğu zaman bu alan adlarının önünde aynı CDN, WAF veya load balancer bulunuyor. Bu durumda:

• Ön uç (edge) katmanda, tüm bu alan adlarını içeren bir SAN (Multi‑Domain) sertifika mantıklıdır.
• Arka plandaki origin sunucularda ise hâlâ Wildcard ya da tek alan adı sertifikaları ile çalışabilirsiniz.

Yani burada karşımıza çıkan model: Edge’de SAN, origin’de Wildcard/tek alan. Böylece:

• CDN/WAF katmanında tek sertifika ile tüm ülkeleri kapsarsınız.
• Uygulama sunucularında ise ayrı ayrı sertifika ve anahtar yönetimi yaparak saldırı yüzeyini daraltırsınız.

Senaryo 3: Ajans veya SaaS, Çok Müşteri, Çok Domain

Bir ajans veya SaaS sağlayıcısı olarak onlarca müşteriniz olabilir:

• www.musteri1.com
• www.musteri2.com.tr
• shop.musteri3.com vb.

Burada sık yapılan hatalardan biri, tüm müşteri domain’lerini tek bir SAN sertifikasına doldurmak. Kısa vadede pratik görünür; ancak:

• Bir müşteri ayrıldığında sertifikayı yeniden tasarlamak zorunda kalırsınız.
• Hukuki ve operasyonel olarak müşteriler arasında gereksiz bir bağımlılık oluşur.
• Bir domain’de yaşanan DNS/SSL sorunu diğerlerini de etkileyebilir.

Bu tip yapılarda genelde şu strateji daha sağlıklıdır:

• Her müşteri için ayrı bir Wildcard veya tek alan adı sertifikası kullanmak.
• Ya da Let’s Encrypt ile otomatik çalışan, müşteri başına izole edilmiş DV sertifikalar üretmek.

Çok kiracılı SaaS mimarilerinde özel alan adları ve otomatik SSL konusunu derinlemesine anlattığımız özel alan adları ve otomatik SSL rehberini de incelemenizi öneririz.

Teknik Kriterler: Hangi Mimaride Hangisi Daha Uygun?

Karar verirken sadece “alan sayısı”na bakmak yeterli değil. Mimarinin bazı teknik detayları da seçimde kritik rol oynar.

1. Alt Alan Adı Hiyerarşisi

Eğer yapınızda şu tarz adresler varsa:

• api.v2.magazam.com
• blue.api.magazam.com
• eu1.pay.magazam.com

Wildcard sertifikanız *.magazam.com ise, bunlar kapsam dışında kalır. Bu durumda seçenekleriniz:

• Her seviye için ayrı Wildcard (örn. *.api.magazam.com),
• Ya da detaylı bir SAN sertifika tasarımı yapmak.

Mikroservis ve çok katmanlı alt alan mimarilerinde genellikle kombine bir yaklaşım gerekir: Bazı kritik alt alan grupları için ayrı Wildcard, geri kalan için SAN vb.

2. Otomasyon ve ACME Desteği

Let’s Encrypt gibi ACME tabanlı sistemler sayesinde hem Wildcard hem SAN sertifikaları otomatik üretip yenileyebilirsiniz. Ancak kullanılan challenge türü ve DNS yapınız bu noktada belirleyicidir.

• HTTP‑01 challenge: Genellikle tek alan adı veya sınırlı SAN kombinasyonları için daha pratik.
• DNS‑01 challenge: Wildcard sertifikalar ve çok alanlı SAN yapılar için idealdir; ancak DNS API erişimi gerektirir.

ACME challenge türlerini ayrıntılı karşılaştırdığımız HTTP‑01, DNS‑01 ve TLS‑ALPN‑01 odaklı rehbere göz atarak kendi mimarinize en uygun otomasyon yaklaşımını belirleyebilirsiniz.

Bir diğer kritik nokta ise rate limit yönetimi. Çok sayıda domain için Let’s Encrypt kullanıyorsanız, rate limit’e takılmadan çok alan adında SSL yönetmek için hazırladığımız strateji rehberi pratik çözümler sunuyor.

3. IP ve SNI Kullanımı

Güncel tarayıcıların büyük çoğunluğu SNI (Server Name Indication) desteğine sahip olduğundan, tek IP üzerinde birden fazla SSL sertifikası barındırmak çoğu senaryoda problem değil. Dolayısıyla “tek IP var, mutlaka SAN kullanmalıyım” ya da “Wildcard tek çözümdür” gibi genellemeler artık geçerliliğini yitirdi.

Önemli olan; sunucu konfigürasyonunuzu (Nginx, Apache, LiteSpeed vb.) doğru yapmanız ve hangi host adında hangi sertifikanın sunulacağını net tanımlamanızdır. Bu konfigürasyonları yaparken HTTP/2/HTTP/3, ALPN ve performans ayarlarını da birlikte ele almak istiyorsanız HTTP/2 ve HTTP/3’ün SEO ve performansa etkilerini incelediğimiz rehber size yol gösterecektir.

Güvenlik Perspektifi: Tek Sertifika mı, Bölünmüş Sertifikalar mı?

Hem Wildcard hem SAN sertifikaların ortak bir riski var: tek sertifikanın çok fazla yeri kapsaması. Bu, yönetilmesi gerektiği gibi yönetildiğinde avantaj; ihmale uğradığında ise ciddi bir zafiyet kaynağı olabilir.

Wildcard Güvenlik Risklerini Azaltma Önerileri

• Özel anahtarı mümkün olduğunca az sunucuya kopyalayın: Her alt alan için ayrı origin sunucunuz varsa bile, sertifikayı doğrudan hepsine dağıtmak yerine önlerinde duran ters proxy/load balancer’a yüklemeyi tercih edin.
• Key rotation (anahtar döndürme) uygulayın: Sertifika yenileme sürecinde aynı private key’i yıllarca kullanmak yerine belirli periyotlarla yeni anahtar üretin.
• Erişim kontrolü: Sertifika ve anahtar dosyalarına kimlerin eriştiği net olsun. DCHost üzerinde çalışan VPS/dedicated sunucularınızda, bu dosyalara erişimi sadece gerçekten ihtiyaç duyan kullanıcılarla sınırlayın.

SAN Sertifikalarda İzolasyon Stratejisi

• Aynı sertifikaya girecek domain’leri dikkat seçin: Hukuken, operasyonel olarak ve güvenlik açısından birbirine bağlı olan alan adlarını aynı SAN içinde gruplayın.
• Müşteri sınırlarını gözetin: Farklı müşterilere ait domain’leri aynı SAN içinde karıştırmayın.
• Değişim frekansını planlayın: Sürekli domain ekleyip çıkardığınız dinamik yapılarda, SAN listesi yönetimini otomasyona bağlamadan yola çıkmayın.

HTTP’den HTTPS’e Geçişte Wildcard ve SAN Kararının Etkisi

Yeni bir e‑ticaret projesinde çoğu zaman zaten HTTPS ile başlıyorsunuz. Ancak yıllardır açık olan bir siteyi HTTP’den HTTPS’e geçirirken, sertifika stratejiniz SEO ve kullanıcı deneyimi açısından kritik rol oynar.

Özellikle:

• www ve kök alan (www.magazam.com + magazam.com) kombinasyonları,
• Farklı dil sürümleri (en.magazam.com, de.magazam.com),
• Eski/yanlış yönlendirmeler,

gibi konularda yapılacak hatalar tarayıcıda “Not Secure” uyarıları ve SEO kaybına yol açabilir. Bu süreci adım adım anlattığımız HTTP’den HTTPS’e geçiş rehberinde 301 yönlendirmeleri, HSTS ve SEO tarafını detaylarıyla ele aldık. Oradaki prensipleri Wildcard veya SAN kararınızla birlikte düşünmek, geçiş sürecini çok daha sorunsuz hale getirir.

Pratik Karar Tablosu: Wildcard mı, SAN mı?

Tüm bu bilgileri özetleyerek hızlı bir karar kılavuzu çıkaralım:

• Senaryo: Tek marka, tek TLD, çok alt alan
  Öneri: Ana domain için Wildcard SSL (gerekirse kök alan için ek SAN ya da ayrı DV sertifika)
• Senaryo: Tek marka, çok TLD (com, com.tr, de, fr vb.)
  Öneri: Edge/CDN katmanında SAN SSL, origin tarafında Wildcard + tek alan sertifikalarının kombinasyonu
• Senaryo: Çok markalı e‑ticaret veya marketplace
  Öneri: Her marka için ayrı Wildcard/tek alan; ortak gateway katmanında sınırlı bir SAN sertifika seti
• Senaryo: Ajans/SaaS, çok müşteri
  Öneri: Müşteri başına izole DV/Wildcard; mümkün olduğunca müşteriler arası ortak SAN kullanmaktan kaçınmak
• Senaryo: Mikroservis, çok seviye alt alan (api.v2.magazam.com vb.)
  Öneri: Kritik alt alan grupları için ek Wildcard’lar (*.api.magazam.com) + gerekiyorsa sınırlı SAN kombinasyonları

DCHost Tarafında Nasıl Yardımcı Oluyoruz?

DCHost olarak pek çok e‑ticaret, SaaS ve çok alan adlı projede aynı sorularla tekrar tekrar karşılaşıyoruz. Deneyimimiz gösteriyor ki sorun çoğu zaman “hangi sertifikayı alacağım?”dan çok, “sertifikayı mimarinin neresine, nasıl yerleştireceğim?” noktasında düğümleniyor.

Altyapınızı bizden aldığınızda (paylaşımlı hosting, VPS, dedicated ya da colocation fark etmeksizin):

• Domain yapınızı ve büyüme planlarınızı dinleyerek Wildcard / SAN / tek alan kombinasyonunu birlikte tasarlıyoruz.
• Let’s Encrypt tabanlı otomatik SSL kurulum ve yenileme süreçlerini CI/CD’nize entegre etmenize yardımcı oluyoruz.
• Gerekirse staging ve canlı ortamlar için ayrı sertifika stratejileri belirleyerek riskleri bölüyoruz.
• HTTP → HTTPS geçişlerinde yönlendirme, HSTS ve güvenlik başlıklarını sertifika stratejinizle uyumlu hâle getiriyoruz.

Özellikle yüksek hacimli e‑ticaret sitelerinde TLS ayarları, HTTP/2‑HTTP/3, OCSP stapling ve modern şifre paketleri gibi detaylar doğrudan Core Web Vitals skorlarınıza yansıyor. Bu tarafta daha derin optimizasyon düşünüyorsanız modern HTTPS için SSL/TLS güncellemelerini anlattığımız rehber ve Core Web Vitals odaklı sunucu tarafı iyileştirme yazımız iyi bir başlangıç noktası olur.

Sonuç: Tek Doğru Yok, Ama Yanlış Kombinasyonlar Çok

Wildcard SSL mi SAN (Multi‑Domain) sertifika mı sorusunun herkese uyan tek bir cevabı yok. Ancak elinizde net bazı kriterler olursa, yanlış kombinasyonlara düşme ihtimaliniz ciddi şekilde azalır:

• Tek marka ve alt alan odaklı bir yapıdaysanız Wildcard genellikle en pratik çözüm.
• Çok TLD ve çok marka senaryolarında SAN sertifikalar devreye giriyor, ama müşteriler arası izolasyondan ödün vermemek şartıyla.
• Güvenlik tarafında tek sertifika ile aşırı büyük bir alanı kapsamak yerine, mantıklı segmentlere bölünmüş sertifika setleri ile anahtar yönetimini kolaylaştırmak daha sağlıklı.
• Let’s Encrypt ve ACME otomasyonları sayesinde, doğru kurulduğunda hem Wildcard hem SAN sertifikalar manuel iş yükü yaratmadan yönetilebilir.

Yeni bir e‑ticaret projesine başlıyorsanız ya da mevcut yapınızı yeniden tasarlıyorsanız, DNS, SSL ve hosting mimarisini en baştan birlikte düşünmek uzun vadede ciddi zaman ve para kazandırıyor. DCHost ekibi olarak, domain yapınızdan PCI DSS gereksinimlerinize, HTTP/3 performansından otomatik yedekleme stratejilerinize kadar tüm mimariyi bütüncül ele alıyoruz. Mevcut sitenizde hangi sertifika tipinin daha doğru olacağını netleştirmek ya da yeni projeniz için sağlam bir SSL stratejisi kurmak isterseniz, destek ekibimizle iletişime geçmeniz yeterli.