SAN Sertifikası ile Çok Alan Adlı SSL

Birden fazla web projesi işleten hemen herkes eninde sonunda aynı soruyla karşılaşır: elimde ornek.com, ornekmarket.com.tr ve blog.ornekhaber.net var; her biri için ayrı ayrı SSL sertifikası mı almalıyım, yoksa hepsini tek bir sertifikayla toplamanın bir yolu var mı? Cevap, çoğu kişinin fark etmediği kadar pratik. Modern TLS sertifikalarının içinde Subject Alternative Name (SAN) adında bir alan bulunur ve bu alan, tek bir sertifikaya birbirinden tamamen bağımsız onlarca tam alan adını sığdırmanıza izin verir. İşte "çok alan adlı SSL", "multi-domain SSL" ya da eski adıyla "UCC sertifika" dediğimiz şey tam olarak budur.

Bu rehberde SAN alanının teknik olarak nasıl çalıştığını, wildcard sertifikadan hangi noktalarda ayrıştığını, hangi senaryoda hangisinin doğru tercih olduğunu ve en önemlisi kendi CSR'ınıza openssl yapılandırmasıyla SAN girdilerini nasıl ekleyeceğinizi baştan sona anlatacağım. Sertifika mantığını henüz tam oturtmadıysanız önce SSL sertifikası nedir yazısına, subdomain temelli koruma arıyorsanız wildcard SSL nedir yazısına göz atmanızı öneririm; bu makale ikisinin arasındaki boşluğu doldurur.

SAN Alanı Nedir ve Neden Var?#

Her X.509 sertifikasının bir öznesi (subject) vardır ve tarihsel olarak alan adı, bu öznenin Common Name (CN) kısmına yazılırdı. CN tek bir metin alanıdır; yani yapısı gereği tek bir alan adı taşıyabilir. İnternet büyüyüp bir sunucunun birden çok siteyi barındırması normalleşince bu tekil yapı yetersiz kaldı. Çözüm, sertifika standardına Subject Alternative Name genişletmesinin eklenmesi oldu.

SAN, adı üstünde "alternatif isimler" listesidir. Bir sertifikanın SAN alanına virgülle ayrılmış şekilde birden çok DNS girdisi yazabilirsiniz:

DNS:ornek.com
DNS:www.ornek.com
DNS:ornekmarket.com.tr
DNS:www.ornekmarket.com.tr
DNS:blog.ornekhaber.net

Tarayıcı bir siteye bağlandığında artık CN alanına neredeyse hiç bakmaz; adres çubuğundaki alan adının SAN listesinde olup olmadığını kontrol eder. RFC 2818 ve güncel tarayıcı davranışı, doğrulamanın SAN üzerinden yapılmasını zorunlu kılar. Bu yüzden günümüzde CN aslında geriye dönük uyumluluk için duran, işlevsel olarak SAN'a devredilmiş bir alandır. Bir başka deyişle: tek alan adlı bir sertifikada bile o alan adı hem CN'de hem SAN'da bulunur; SAN olmadan geçerli sayılmaz.

Buradan çıkan sonuç güçlü: eğer doğrulama SAN listesine bakıyorsa, o listeye kaç isim koyduğunuz teknik olarak fark etmez. Bir isim de koyabilirsiniz, elli isim de. İşte "çok alan adlı SSL" bu esneklikten doğar; ekstra bir teknoloji değil, SAN alanının doğal kullanımıdır.

Çok Alan Adlı (Multi-Domain) SSL Nasıl Çalışır?#

Çok alan adlı bir sertifika, SAN alanında birbirinden bağımsız kök alan adları taşıyan tek bir sertifikadır. "Bağımsız" kelimesi burada kritik: ornek.com, baska-marka.net ve sirket.com.tr aralarında hiçbir DNS akrabalığı olmayan üç ayrı alandır, ama tek bir SAN sertifikasında bir arada yaşayabilirler.

Pratikte akış şöyle işler. Sunucu, TLS el sıkışması sırasında istemciye tek bir sertifika sunar. İstemci (tarayıcı) bağlandığı alan adını sertifikanın SAN listesiyle karşılaştırır, eşleşme bulursa bağlantıyı güvenli kabul eder. Aynı sunucu üzerinde farklı alan adlarını ayırt etmek için de SNI (Server Name Indication) devreye girer: istemci, el sıkışmanın en başında hangi alan adına bağlanmak istediğini açıkça belirtir, sunucu da doğru sertifikayı (ya da bu durumda doğru SAN girdisini kapsayan tek sertifikayı) sunar.

Nginx tarafında birden çok alan adını tek SAN sertifikasıyla sunmak son derece sadedir:

server {
    listen 443 ssl;
    server_name ornek.com www.ornek.com ornekmarket.com.tr blog.ornekhaber.net;

    ssl_certificate     /etc/ssl/cloutr/san-bundle.crt;
    ssl_certificate_key /etc/ssl/cloutr/san.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root /var/www/coklu-site;
    index index.html;
}

Tek ssl_certificate satırıyla üç ayrı markanın da HTTPS'i çalışır, çünkü hepsi aynı sertifikanın SAN listesinde. Farklı alan adlarını farklı dizinlere yönlendirmek isterseniz her biri için ayrı server bloğu açıp aynı sertifika dosyasını gösterebilirsiniz; sertifika ortaktır, yönlendirme mantığı size aittir.

Bu mimarinin en somut kazanımı operasyonel sadeliktir: tek bir yenileme tarihi, tek bir özel anahtar, tek bir kurulum. On ayrı sertifikanın bitiş tarihlerini takvimde kovalamak yerine tek bir kalemi izlersiniz.

SAN ile Wildcard Arasındaki Fark#

En sık karıştırılan konu bu. İkisi de "tek sertifika, çok isim" vaadi verir ama tamamen farklı problemleri çözerler. Ayrımı net koymak gerekirse: wildcard tek bir alan adının sınırsız alt seviyesini, SAN ise birbirinden farklı alan adlarını kapsar.

Wildcard sertifika *.ornek.com biçimindedir ve blog.ornek.com, shop.ornek.com, panel.ornek.com gibi aynı kök alan adına ait birinci seviye subdomainlerin hepsini tek seferde kapsar — ileride ekleyeceğiniz crm.ornek.com bile otomatik dahil olur. Buna karşılık wildcard, ornek.com.tr gibi başka bir alan adını asla kapsayamaz.

SAN sertifika ise her ismi açıkça listelemek zorundadır ama listeye ne yazacağınız konusunda özgürsünüz: farklı TLD'ler, farklı markalar, hatta subdomain'ler yan yana durabilir. Karşılığında, listede olmayan bir subdomain'i sonradan sertifikasız bırakırsınız; yeni bir isim eklemek için sertifikayı yeniden düzenlemeniz gerekir.

İyi haber şu: bu ikisi birbirini dışlamaz. Bir SAN sertifikasının içine wildcard girdisi de koyabilirsiniz. Örneğin şu şekilde tek bir "melez" sertifika üretebilirsiniz:

DNS:ornek.com
DNS:*.ornek.com
DNS:ornekmarket.com.tr
DNS:*.ornekmarket.com.tr

Bu sertifika hem iki ayrı markayı hem de her ikisinin tüm subdomainlerini aynı anda korur. Kurumsal ortamlarda en sık tercih edilen yapı budur. Hangisinin size uygun olduğuna karar verirken temel soruyu sorun: koruyacağım isimler tek bir kökün altında mı toplanıyor (wildcard), yoksa farklı alan adları mı (SAN)?

UCC/UCS Sertifikaları ve Kullanım Alanları#

Çok alan adlı sertifikaların bir de UCC (Unified Communications Certificate) olarak bilinen özel bir kullanım geleneği vardır. Teknik olarak UCC de bir SAN sertifikasıdır; isim, Microsoft Exchange ve Office Communications Server ortamlarında birden çok host adını tek sertifikada toplama ihtiyacından gelir. Bir Exchange sunucusunun aynı anda mail.ornek.com, autodiscover.ornek.com ve webmail.ornek.com isimlerini sunması gerekir; UCC/SAN bunu tek sertifikayla çözer.

En yaygın gerçek dünya senaryolarını sıralayalım:

• E-posta ve işbirliği sunucuları: Exchange, Zimbra veya Mailcow kurulumlarında mail, autodiscover, smtp, imap host adları tek SAN sertifikasında toplanır. E-posta altyapısını kurumsal e-posta çözümleri üzerinden yönetiyorsanız bu yapı standarttır.
• Çoklu marka barındıran ajanslar/bayiler: Bir reseller hosting hesabında farklı müşterilerin sitelerini barındıran ajanslar, birkaç ana alan adını tek sertifikada birleştirerek yönetim yükünü azaltır.
• Landing page ve kampanya siteleri: Aynı şirketin urun-lansmani.com, kampanya.net, indirim.com.tr gibi ayrı kampanya alanları tek SAN sertifikasıyla korunabilir.
• Uluslararası TLD'ler: Aynı markanın .com, .com.tr, .net ve .org varyantlarını birlikte kullandığı durumlarda hepsi tek listede toplanır. Bu alan adlarını alan adı kayıt tarafında zaten tek panelden yönetiyorsanız SSL'i de tek noktada toplamak tutarlıdır.

Bu senaryoların ortak noktası, isimlerin farklı köklerden gelmesi ve dolayısıyla wildcard'ın yetmemesidir. İşte SAN'ın parladığı yer tam burasıdır.

CSR'a SAN Alanı Nasıl Eklenir? (openssl ile Adım Adım)#

Şimdi işin pratik kalbine geldik. Bir SAN sertifikası almak için, sertifika talebinizi (CSR — Certificate Signing Request) oluştururken SAN girdilerini CSR'ın içine gömmeniz gerekir. Sertifika Otoritesi (CA), CSR'daki SAN listesini okuyup sertifikaya işler. Komut satırından tek satır openssl req ile bunu yapmak zordur; en temiz yöntem, bir OpenSSL yapılandırma dosyası kullanmaktır.

1. OpenSSL yapılandırma dosyasını hazırlayın#

san.cnf adında bir dosya oluşturun ve içine hem özne bilgilerini hem de alt_names bölümünü yazın:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
req_extensions     = req_ext
distinguished_name = dn

[ dn ]
C  = TR
ST = Istanbul
L  = Istanbul
O  = Ornek Teknoloji A.S.
CN = ornek.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = ornek.com
DNS.2 = www.ornek.com
DNS.3 = ornekmarket.com.tr
DNS.4 = www.ornekmarket.com.tr
DNS.5 = blog.ornekhaber.net

Dikkat edilecek birkaç nokta var. CN alanına yazdığınız isim, mutlaka alt_names listesinde de bulunmalıdır (tarayıcı yalnızca SAN'a baktığı için). prompt = no ayarı, openssl'in size interaktif soru sormasını engeller; tüm değerleri dosyadan alır. DNS.1, DNS.2 şeklindeki numaralandırma sıralı ve benzersiz olmalıdır.

2. Özel anahtarı ve CSR'ı üretin#

Tek komutla hem 2048-bit RSA anahtarını hem de SAN'lı CSR'ı oluşturun:

openssl req -new -nodes \
  -newkey rsa:2048 \
  -keyout san.key \
  -out san.csr \
  -config san.cnf

-nodes (no DES) parametresi anahtarı parolasız üretir; bu, sunucunun her yeniden başlatmada parola sormadan TLS'i ayağa kaldırabilmesi için pratikte yaygın bir tercihtir. Üretilen san.key dosyasını güvenli tutun ve asla kimseyle paylaşmayın; CA'ya yalnızca san.csr dosyasını göndereceksiniz.

3. SAN girdilerinin CSR'a işlendiğini doğrulayın#

Sertifika Otoritesine göndermeden önce CSR'ın içindeki SAN listesini mutlaka kontrol edin. Eksik ya da yanlış bir SAN, sertifikanın yanlış üretilmesine ve baştan başlamaya yol açar:

openssl req -in san.csr -noout -text | grep -A1 "Subject Alternative Name"

Çıktıda listelediğiniz tüm alan adlarını görüyorsanız CSR hazırdır:

X509v3 Subject Alternative Name:
    DNS:ornek.com, DNS:www.ornek.com, DNS:ornekmarket.com.tr,
    DNS:www.ornekmarket.com.tr, DNS:blog.ornekhaber.net

4. Doğrulamayı her alan adı için ayrı yapın#

Burada çok önemli bir kural var: SAN sertifikasındaki her bir alan adı ayrı ayrı doğrulanır. Yani CA, listedeki ornek.com, ornekmarket.com.tr ve blog.ornekhaber.net alanlarının her birinin size ait olduğunu bağımsız olarak kanıtlamanızı ister. DV (Domain Validation) sertifikalarında bu genellikle her alan için ayrı bir DNS TXT kaydı ya da HTTP dosya doğrulaması demektir. Beş alan adlı bir SAN sertifikasında beş ayrı doğrulama yaparsınız. Bu, wildcard'a kıyasla ek bir emek ama tek seferliktir.

Kurulum aşamasında sertifikayı, CA'nın verdiği ara sertifikalarla (intermediate) birleştirip tam zinciri (san-bundle.crt) oluşturmayı unutmayın; aksi halde bazı istemcilerde "zincir eksik" hatası görürsünüz. Zincir birleştirme ve kurulum detaylarını sunucu yönetimi tarafında ekibimiz sizin için de yapabilir.

Let's Encrypt ile Ücretsiz Multi-Domain Sertifika#

Ticari bir SAN sertifikası satın almadan da çok alan adlı koruma alabilirsiniz. Let's Encrypt, tek bir sertifikaya birden çok alan adı koymayı destekler; certbot ile her -d parametresi SAN listesine bir girdi ekler:

certbot certonly --nginx \
  -d ornek.com \
  -d www.ornek.com \
  -d ornekmarket.com.tr \
  -d www.ornekmarket.com.tr \
  -d blog.ornekhaber.net

Bu komut, beş alan adını da SAN alanında taşıyan tek bir sertifika üretir. Let's Encrypt'in pratik bir sınırı vardır: tek sertifika başına en fazla 100 SAN girdisi koyabilirsiniz. Küçük ve orta ölçekli çoğu senaryo için bu limit ziyadesiyle yeterlidir.

Otomatik yenileme kritik konudur. Let's Encrypt sertifikaları 90 gün geçerlidir; certbot renew komutunu bir zamanlanmış görevle çalıştırarak süreci otomatikleştirin:

0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Yenileme sırasında listedeki her alan adının doğrulaması tekrar geçmelidir. Bu yüzden bir alan adını artık kullanmıyorsanız, o alanın DNS'i ya da HTTP doğrulaması bozulup tüm sertifikanın yenilenmesini engelleyebilir. Kullanmadığınız alanları yenileme komutundan çıkarmayı ihmal etmeyin. cPanel tabanlı web hosting paketlerimizde AutoSSL çoğu durumda bu işi arka planda otomatik yürütür; kendi sunucunuzu sunucu yönetimi tarafında işletiyorsanız certbot'un cron'unu mutlaka doğrulayın.

SAN Sertifikası Yönetiminde Dikkat Edilecekler#

Çok alan adlı sertifikalar operasyonu sadeleştirir ama kendine has birkaç risk taşır; bunları baştan bilmek sizi ileride ciddi baş ağrısından kurtarır.

Tek anahtar, tek nokta: Bir SAN sertifikasındaki tüm alan adları aynı özel anahtarı paylaşır. Bu anahtar sızarsa, listedeki her site aynı anda risk altına girer. Bu yüzden anahtar dosyasının izinlerini sıkı tutun (chmod 600), yedeklerinizi şifreli saklayın ve bir sızma şüphesinde sertifikayı hemen iptal (revoke) edip yeniden üretin. Anahtar güvenliği için yedekleme stratejinizi de gözden geçirin.

Bir alanı değiştirmek hepsini etkiler: SAN listesine yeni bir alan eklemek ya da bir alanı çıkarmak, sertifikanın tamamen yeniden üretilmesini gerektirir. Sık sık site ekleyip çıkaran dinamik bir ortamda bu, wildcard'a kıyasla daha çok yeniden düzenleme demektir. Alan yapınız oturmuşsa SAN idealdir; sürekli değişiyorsa wildcard ya da alan başına ayrı sertifika daha rahat olabilir.

Doğrulama zinciri en zayıf halkadan kopar: Yenileme anında listedeki tek bir alanın doğrulaması bile başarısız olursa, sağlam olan diğer dört alan da yenilenemez. Bu yüzden SAN listesini gerçekten aktif ve kontrolünüzde olan alanlarla sınırlı tutun.

Uygulama katmanında güvenlik ayrı bir konudur: SSL yalnızca aktarım güvenliğini (trafiğin şifrelenmesini) sağlar; uygulamanıza gelen kötü niyetli istekleri engellemez. Çok sayıda alanı tek sunucuda topluyorsanız, önüne bir WAF ve DDoS koruması koymanız katmanlı güvenlik açısından önemlidir. WordPress ağırlıklı bir kurulumsanız WordPress bakım hizmetimiz düzenli güvenlik güncellemelerini üstlenir.

İzleme ve son kullanma takibi: Tek yenileme tarihi avantaj gibi görünse de, o tek tarihi kaçırırsanız hepsi birden düşer. Bir sertifika son kullanma izleyicisi kurun ve bitişten en az iki hafta önce uyarı alacak şekilde yapılandırın.

Sıkça Sorulan Sorular#

SAN sertifikası ile wildcard sertifika arasındaki temel fark nedir?#

Aradaki fark kapsam mantığında yatar. Wildcard sertifika *.ornek.com biçiminde tek bir kök alan adının tüm birinci seviye subdomainlerini otomatik olarak kapsar, ama başka bir alan adını (ornek.net gibi) asla içeremez. SAN sertifika ise her ismi açıkça listeler ve bu listeye birbirinden bağımsız farklı alan adlarını koyabilirsiniz. Kısaca wildcard "tek marka, sınırsız subdomain", SAN ise "farklı markalar/alanlar, açık liste" için tasarlanmıştır. İkisi tek sertifikada birleştirilebilir de.

Bir SAN sertifikasına en fazla kaç alan adı ekleyebilirim?#

Bu, sertifikayı aldığınız otoriteye bağlıdır. Let's Encrypt tek sertifika başına en fazla 100 SAN girdisine izin verir. Ticari sertifika otoriteleri genellikle temel pakette 3 ila 5 alan adı verir ve ek alanları ücretli olarak eklemenize olanak tanır; bazıları 250'ye kadar çıkabilir. Küçük ve orta ölçekli projeler için bu limitlerin hiçbiri pratikte sorun oluşturmaz.

SAN sertifikasındaki her alan adı ayrı ayrı mı doğrulanır?#

Evet. Sertifika otoritesi, SAN listesindeki her bir alan adının size ait olduğunu bağımsız olarak kanıtlamanızı ister. Domain Validation sertifikalarında bu, her alan için ayrı bir DNS TXT kaydı ya da HTTP dosya doğrulaması demektir. Beş alan adlı bir sertifikada beş ayrı doğrulama yaparsınız ve bu doğrulamalar sertifika yenilendikçe tekrar geçerli olmalıdır. Bu yüzden listeye yalnızca gerçekten kontrolünüzde olan alanları koymalısınız.

CSR oluştururken SAN girdilerini eklemeyi unutursam ne olur?#

CSR'da SAN alanı yoksa, otorite yalnızca CN'deki tek alan adını içeren bir sertifika üretir ve diğer alanlarınız korumasız kalır. Modern tarayıcılar doğrulamayı yalnızca SAN üzerinden yaptığı için, SAN'ı eksik bir sertifika beklediğiniz siteler için "geçersiz sertifika" uyarısı verir. Bu durumda yeni bir openssl yapılandırma dosyasıyla SAN'lı bir CSR üretip süreci baştan başlatmanız gerekir; bu yüzden göndermeden önce openssl req -in san.csr -noout -text ile SAN listesini mutlaka doğrulayın.

Aynı sertifikaya hem wildcard hem de düz alan adı koyabilir miyim?#

Evet, bu tamamen mümkün ve kurumsal ortamlarda çok yaygındır. SAN listesine ornek.com, *.ornek.com ve ornekmarket.com.tr, *.ornekmarket.com.tr gibi girdileri bir arada yazabilirsiniz. Böylece hem iki ayrı markanın kök alanlarını hem de her ikisinin tüm subdomainlerini tek bir sertifikayla korursunuz. Let's Encrypt de dahil çoğu otorite bu melez yapıyı destekler; yalnızca wildcard girdilerinin DNS-01 yöntemiyle doğrulanması gerektiğini unutmayın.

SAN sertifikasında bir alan adını sonradan çıkarmak diğerlerini etkiler mi?#

Evet, dolaylı olarak etkiler. Bir alanı listeden çıkarmak sertifikanın yeniden üretilmesini gerektirir; yani kalan alanlar için de yeni bir sertifika basılır ve dağıtılır. Daha kritik olan şu: eğer bir alanın doğrulaması yenileme anında başarısız olursa (örneğin DNS'i bozulmuşsa), sağlam olan diğer alanlar da yenilenemez ve hepsi birden süresi dolmuş sertifikayla kalır. Bu yüzden kullanmadığınız alanları yenileme komutundan proaktif olarak çıkarmak iyi bir alışkanlıktır.

Kapanış#

SAN alanı, tek bir sertifikaya farklı markaları, TLD'leri ve host adlarını sığdıran sessiz kahramandır. Doğru senaryoda — birden çok bağımsız siteyi tek noktadan yönetmek istediğinizde — hem maliyeti hem operasyon yükünü belirgin biçimde düşürür. Wildcard'ın tek kökün subdomainlerini, SAN'ın ise farklı alan adlarını çözdüğünü ve ikisinin gerektiğinde tek sertifikada birleşebildiğini aklınızda tutarsanız, hangi yapıyı seçeceğiniz konusunda hiç tereddüt etmezsiniz.

Clou.TR'de SAN ve wildcard sertifika kurulumundan CSR üretimine, otomatik yenilemeden zincir yapılandırmasına kadar tüm SSL sürecini sizin yerinize yönetiyoruz. SSL çözümlerimizi inceleyebilir, alan adlarınızı tek panelden toplamak için hosting paketlerimize göz atabilir ya da kendi sunucunuzda uçtan uca kurulumu sunucu yönetimi ekibimize bırakabilirsiniz. Birden çok markayı güvenle çevrimiçi tutmanın en pratik yolu, doğru kurgulanmış tek bir SAN sertifikasından geçer.