Wildcard SSL mi SAN mı? E-Ticaret İçin Seçim Rehberi

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?

Sertifika kapsamının mimariyle uyuşmaması veya yenileme ve dağıtım süreçlerinin eksik planlanması, tarayıcı uyarılarına ve hizmet kesintilerine yol açabilir. 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) farklı özellikleri tanımlar; ancak her kombinasyonun sunulduğu varsayılmamalıdı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. Bu adlar SAN uzantısında listelenir; tek alan adlı ve Wildcard sertifikalar da SAN kullanır. Dolayısıyla Wildcard ve SAN birbirini dışlayan seçenekler değildir.

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ı; kapsanması için sertifikada ayrıca yer almalıdır)
  • 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 sertifikayı yeniden üretmeniz gerekmez; ancak mevcut sertifikanın ilgili TLS uç noktasında kurulmuş ve yeni host için yapılandırılmış olması gerekir.
• 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 doğrulaması 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; ancak üretim anahtarını bu ortamlara dağıtmak ortak anahtar riskini büyütür. Ortamlar arasında izolasyon gerekiyorsa ayrı anahtarlarla ayrı sertifikalar kullanın.

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 sertifikanın kapsadığı birinci seviye host adları için geçerli bir TLS kimliği sunabilir; bağlantıyı ele geçirmek için ayrıca trafiği kendi uç noktasına yönlendirmesi gerekir.
• 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.
• Tek Wildcard girdisi farklı alanları kapsamaz: Hem magazam.com hem magazam.com.tr hem de marka2.com gibi alanlarınız varsa, tek bir Wildcard girdisi ile bunların hepsini kapsayamazsınız; aynı sertifikada farklı alanlar için ek SAN girdileri bulunabilir.
• Yetki paylaşımı zorlaşır: Farklı ekipler (örn. ajans, alt yüklenici, üçüncü parti entegratör) farklı alt alanlardan sorumluysa ve aynı sertifika bu ekiplerin sunucularına dağıtılıyorsa, özel anahtar da paylaşılır; bu da güvenlik ve sorumluluk takibini zorlaştırır. Ekipler için ayrı anahtarlarla ayrı sertifikalar kullanmak veya TLS’i merkezi bir uç noktada sonlandırmak bu paylaşım ihtiyacını kaldırabilir.

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, SAN alanında birden fazla alan adı veya alt alan girdisi bulunan sertifikalardır; yalnızca SAN alanının dolu olması çok alan adlı oldukları anlamına gelmez.

Ö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. Bu eşleşme gereklidir ancak tek başına yeterli değildir; sertifikanın geçerlilik süresi ve güvenilir bir köke uzanan sertifika zinciri gibi diğer TLS doğrulamalarının da başarılı olması gerekir. Geçerli TLS bağlantısı, sitenin veya satıcının güvenilirliğini tek başına kanıtlamaz.

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.
• Daha açık kapsam envanteri: 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; ancak alan adı başına ayrı anahtar veya erişim yetkisi sağlamaz.
• Ç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: Mevcut sertifikanın kapsamadığı bir alan adını eklemek için 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: Tüm müşteri sitelerini tek SAN sertifikasında toplamak, yenileme ve anahtar yönetimini birbirine bağlar. Bir müşteri ayrıldığında veya bir alan adı taşındığında kapsamı ve anahtar erişimlerini yeniden değerlendirmek gerekir; sertifikayı yeniden üretmek ya da müşterileri ayrı sertifikalara ayırmak gerekebilir.

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. Alt alanlar aynı güvenlik ve yönetim sınırı içindeyse pratik bir 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 sertifikayı yeniden düzenlemeniz gerekmez; DNS, sunucu ve gerekiyorsa sertifika dağıtım ayarlarını yine yapmalısı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ı sertifikalar ve birbirinden bağımsız özel anahtarlar kullanarak bir anahtar sızıntısının etkisini sınırlayabilirsiniz.

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 tüm müşteri domain’lerini tek bir SAN sertifikasında toplamak kısa vadede pratik görünebilir; ancak müşteri izolasyonu açısından bazı sakıncaları vardır:

• Bir müşteri ayrıldığında, onun alan adını ortak sertifikadan çıkarmak için sertifikayı kalan adlarla yeniden düzenlemeniz gerekir.
• Ortak sertifikanın yenilenmesi ve değiştirilmesi, müşteriler arasında operasyonel bağımlılık oluşturur.
• Bir domain’in doğrulamasındaki sorun ortak sertifikanın yenilenmesini aksatabilir; bu, o domain’deki her DNS sorununun diğer siteleri doğrudan etkilediği anlamına gelmez.

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.
• Bu müşteri bazlı ayrımı koruyarak Let’s Encrypt ile DV sertifika üretimini ve yenilemeyi otomatikleştirmek.

Ç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:

• İlgili her üst alan grubu için ayrı Wildcard (örn. *.api.magazam.com),
• Ya da detaylı bir SAN sertifika tasarımı yapmak.

Mikroservis ve çok katmanlı alt alan mimarilerinde kombine bir yaklaşım kullanılabilir: 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: Doğrulanacak her alan adı için HTTP doğrulama yanıtını sunabildiğiniz yapılarda pratiktir; seçim yalnızca SAN listesinin büyüklüğüne bağlı değildir.
• DNS‑01 challenge: Wildcard sertifikalar ve çok alanlı SAN yapılar için kullanılabilir. DNS kayıtları elle de yönetilebilir; otomatik yenileme için DNS API erişimi veya başka bir otomatik DNS güncelleme yöntemi gerekir.

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.

Ayrı anahtarlar tek başına kapsam izolasyonu sağlamaz. Örneğin *.magazam.com, stg.magazam.com ve pay.magazam.com adlarını da kapsar. Staging veya ödeme uç noktasına ayrı sertifika vermek, bu adları mevcut Wildcard kapsamından çıkarmaz. Bir anahtarın yalnızca amaçlanan güvenlik sınırı içindeki adlar için kullanılabilmesi gerekiyorsa, tüm sertifikaların kapsamlarını birlikte kontrol edin; çakışan Wildcard yerine açık host adları kullanın veya alan adı hiyerarşisini çakışmayan gruplara ayırın.

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 dikkatle seçin: Hukuken, operasyonel olarak ve güvenlik açısından birbirine bağlı olan alan adlarını aynı sertifikanın SAN listesinde 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: Aynı seviyedeki alt alanlar için Wildcard SSL; kök alan da kullanılacaksa onu ayrıca kapsayan bir SAN kaydı ya da ayrı 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 (v2.api.magazam.com vb.)
  Öneri: Kritik alt alan grupları için ek Wildcard’lar (*.api.magazam.com) + gerekiyorsa sınırlı SAN kombinasyonları

Hosting Planında SSL Yönetimi İçin Neleri Değerlendirmelisiniz?

E‑ticaret, SaaS ve çok alan adlı projelerde sertifika türünün yanı sıra, sertifikayı mimarinin neresine, nasıl yerleştireceğinizi de belirlemeniz gerekir.

Paylaşımlı hosting, VPS, dedicated veya colocation seçeneklerini değerlendirirken şu işlerin sorumluluğunu kimin üstleneceğini ve seçilen planın destek kapsamını netleştirin:

• Domain yapısına ve büyüme planlarına uygun Wildcard / SAN / tek alan kombinasyonunun tasarlanması.
• Let’s Encrypt tabanlı otomatik SSL kurulum ve yenileme süreçlerinin, gerekiyorsa CI/CD ile entegrasyonunun planlanması.
• Staging ve canlı ortamlar için ayrı sertifika ve özel anahtarlarla risklerin bölünmesi.
• HTTP → HTTPS geçişlerinde yönlendirme, HSTS ve güvenlik başlıklarının sertifika stratejisiyle uyumlu hâle getirilmesi.

TLS ayarları, HTTP/2‑HTTP/3 ve şifre paketi seçimi bağlantı ve yükleme sürelerini etkileyebilir; Core Web Vitals üzerindeki etkiyi ölçerek değerlendirmek gerekir. OCSP stapling desteği sertifika otoritesine ve sertifikaya bağlıdır; Let’s Encrypt, OCSP hizmetini 6 Ağustos 2025’te kapattığından güncel sertifikalarında bu seçenek kullanılamaz. 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, ayrı özel anahtarlar kullanan, mantıklı segmentlere bölünmüş sertifika setleri bir anahtar sızıntısının etkisini sınırlayabilir; ancak yönetilecek anahtar ve yenileme sayısı artar.
• Let’s Encrypt ve ACME otomasyonları doğru kurulduğunda hem Wildcard hem SAN sertifikalarda rutin manuel yenileme işini azaltabilir; yenileme sonuçlarının izlenmesi ve hatalara müdahale yine gerekir.

Yeni bir e‑ticaret projesinde ya da mevcut yapıyı yeniden tasarlarken DNS, SSL ve hosting mimarisini birlikte planlamak sonradan yapılacak değişiklikleri azaltabilir. Sertifika kapsamını domain listenizle eşleştirin; varsa PCI DSS gereksinimlerini, HTTP/3 hedeflerini ve yedekleme stratejisini de mimari plana dahil edin. Son karar öncesinde sertifikaların nerede sonlandırılacağını, özel anahtarların kimde tutulacağını ve yenileme hatalarına kimin müdahale edeceğini netleştirin.