Wildcard SSL/TLS Sertifikası Nedir?
Wildcard sertifika, TLS bağlantılarında belirli bir alan adı düzeyindeki birden fazla sunucu adını tek sertifika girdisiyle doğrulamak için yıldız karakteri kullanan sertifikadır. *.example.com girdisi; www.example.com, api.example.com ve shop.example.com gibi doğrudan alt alanlarla eşleşebilir.
Bu kapsam sınırsız değildir. Yıldız yalnız bir tam alan adı etiketinin, yani iki nokta arasındaki tek bölümün yerini tutar. example.com kök alan adını veya v2.api.example.com gibi daha derindeki bir adı kendiliğinden kapsamaz.
“SSL sertifikası” ifadesi ürün adlarında ve günlük kullanımda yaygındır; SSL, TLS’den önce kullanılan protokoldür. Güncel şifreli web bağlantıları HTTPS ile TLS üzerinden kurulur. DNS, adları ağ hedefleriyle eşleştiren katmandır. Wildcard sertifikanın görevi yeni alt alan oluşturmak veya trafiği yönlendirmek değil, istemcinin bağlandığı adın sertifikadaki kimliklerden biriyle eşleşmesini sağlamaktır.
Wildcard Sertifikanın Kapsamı Nasıl Okunur?
RFC 9525’e göre sertifikadaki yıldız karakteri yalnız en soldaki etiketin tamamı olabilir ve yalnız bir etiketle eşleşir. Kısmi yıldız veya birden fazla yıldız geçerli sunucu kimliği sayılmaz.
| Sertifika girdisi | Bağlanılan ad | Sonuç | Neden |
|---|---|---|---|
*.example.com | www.example.com | Eşleşir | Yıldız tek bir doğrudan alt alan etiketini karşılar. |
*.example.com | example.com | Eşleşmez | Yıldızın karşılayacağı bir etiket yoktur. |
*.example.com | v2.api.example.com | Eşleşmez | Yıldızın yerine iki etiket gelmesi gerekir. |
*.eu.example.com | panel.eu.example.com | Eşleşir | Panel etiketi, belirtilen düzeydeki yıldızı karşılar. |
w*.example.com | www.example.com | Geçersiz model | Yıldız en soldaki etiketin tamamı değildir. |
*.*.example.com | a.b.example.com | Geçersiz model | Sertifika kimliğinde yalnız bir yıldız bulunabilir. |
Alan adı büyük-küçük harf farkı gözetmeden etiket etiket karşılaştırılır. Uygulamalar için uluslararasılaştırılmış alan adları (IDNA), Unicode ile gösterilen alan adı etiketlerini karşılaştırmadan önce A-etiketi biçimine dönüştürmeyi gerektirir. Bu biçim, uluslararasılaştırılmış etiketi xn-- ile başlayan bir gösterimle taşır. Böyle bir ad için sertifikadaki gerçek A-etiketini ve istemcinin doğruladığı adı birlikte denetlemek gerekir.
Kök Alan Adı ve Daha Derin Alt Alanlar
example.com kök alan adı ile *.example.com wildcard girdisi iki ayrı kimliktir. Hem kök alan hem doğrudan alt alanlar kullanılacaksa sertifikanın SAN (Subject Alternative Name) uzantısında iki girdinin de bulunması gerekir.
Daha derin adlarda da aynı kural geçerlidir. panel.eu.example.com için açık bir tam ad, *.eu.example.com girdisi veya o adı içeren başka bir SAN sertifikası gerekir. *.example.com bütün alt alan ağacını kapsayan bir kalıp değildir.
Herkese açık güvene sahip sertifika otoriteleri, *.com veya *.co.uk gibi kayıt otoritesinin yönettiği ya da kamuya açık sonek düzeyindeki geniş wildcard adları normal bir alan adı müşterisine veremez. Sertifika otoritesi, wildcard bölümünün kaydedilebilir alan sınırının altında olduğunu doğrulamalıdır.
SAN Alanı Esastır, Common Name Yeterli Değildir
Güncel sunucu kimliği doğrulamasında DNS adı, sertifikanın SAN uzantısındaki dNSName adlı DNS kimliği girdisiyle kontrol edilir. Sertifikanın CN (Common Name) alanında bir alan adı yazması tek başına yeterli değildir. RFC 9525, hizmet kimliği için Common Name kullanımını geçerli yöntem olmaktan çıkarmıştır.
Bir sertifikada birden fazla SAN girdisi bulunabilir. Örneğin example.com, *.example.com, *.eu.example.com ve service.example.net aynı sertifikada ayrı kimlikler olarak yer alabilir. İstemci her bağlantıda yalnız erişmek istediği adla eşleşen girdiyi dikkate alır.
Sertifikanın ad kapsamı, sertifika zincirinin güvenilirliği veya süresinin geçerliliğiyle aynı kontrol değildir. Ad eşleşse bile zincir eksikse, sertifika süresi dolmuşsa, sertifika iptal edilmişse veya istemci sertifika otoritesine güvenmiyorsa bağlantı yine başarısız olabilir.
Wildcard Sertifika DNS Kaydı Oluşturmaz
DNS, bir adı hangi sunucuya veya hizmete yönlendireceğini belirler. Wildcard sertifika ise ulaşılan TLS uç noktasının o adı sunmaya yetkili olduğunu doğrulamaya yarar. Sertifika almak yeni bir DNS kaydı, sanal sunucu veya uygulama oluşturmaz.
Benzer biçimde wildcard DNS kaydı da sertifikanın ad kapsamını genişletmez. *.example.com DNS kaydı çok sayıda adı aynı hedefe yönlendirebilir; ancak o hedef doğru SAN girdisini taşıyan sertifikayı sunmuyorsa istemci ad uyuşmazlığı görür.
SNI (Server Name Indication), istemcinin TLS görüşmesi sırasında ulaşmak istediği sunucu adını bildirmesini sağlar. Aynı IP adresinde farklı adlara farklı sertifikalar sunulabilir. Alan adı için yapılan testte SNI ile gerçek sunucu adı gönderilmeli, sertifikanın SAN girdileri de aynı adla karşılaştırılmalıdır; yalnız SNI göndermek kimlik doğrulaması yapmaz. Doğrudan IP adresiyle bağlantıda ise DNS adı değil, SAN içindeki iPAddress türündeki adres doğrulanır.
Tek Alanlı, Wildcard ve Çok Alanlı Sertifikalar Arasındaki Farklar
- Tek alanlı sertifika: Yalnız açıkça belirtilen bir tam adı kapsar; başka hizmetlerle anahtar paylaşılmıyorsa anahtar sızıntısının ve yenileme hatasının etkisi bu hizmetle sınırlı kalır.
- Wildcard sertifika: Belirli bir üst alanın tek etiket derinliğindeki alt alanlarını kapsar; sık oluşturulan benzer alt alanlarda sertifika yönetimini kolaylaştırabilir.
- Çok alanlı SAN sertifikası: Farklı alan adlarını, kök alanları veya farklı derinliklerdeki belirli adları tek sertifikada açıkça listeler.
- Hibrit sertifika: Aynı SAN listesinde hem tam adlar hem izin verilen wildcard adları bulunabilir.
Seçim yalnız sertifika sayısına göre yapılmamalıdır. Hizmetlerin aynı ekip, güvenlik bölgesi ve TLS sonlandırma noktası tarafından yönetilip yönetilmediği; özel anahtarın kaç sisteme gideceği ve tek yenileme hatasının kaç adı etkileyeceği daha önemli olabilir.
Gereğinden geniş bir SAN listesi de çok sayıda hizmetin yenilenmesini aynı sertifikaya bağlar. Bir hizmet kaldırıldığında adı sonraki sertifikadan çıkarmak, yetkisiz yeni ad eklenmesini önlemek ve her ekip için sertifika talep yetkisini sınırlandırmak gerekir. “Tek sertifika daha kolaydır” yaklaşımı, sahiplik ve anahtar sınırları farklı olan sistemlerde karar vermek için yeterli değildir.
Wildcard Sertifika Nasıl Doğrulanır ve Alınır?
CA (Certification Authority), sertifika vermeden önce istenen alan adı üzerinde yetki veya denetim bulunduğunu doğrular. ACME (Automatic Certificate Management Environment) kullanan Let’s Encrypt’te wildcard talepleri DNS üzerinden doğrulanır. Yaygın DNS-01 yönteminde ACME istemcisi, _acme-challenge.example.com altında geçici bir TXT kaydı yayımlar ve sertifika otoritesi bu değeri DNS üzerinden kontrol eder.
Alan adı denetiminin doğrulanması, başvuru sahibinin o anda DNS üzerinde gerekli değişikliği yapabildiğini gösterir; web uygulamasının güvenli olduğunu veya alan adının ticari sahibi olduğunu kanıtlamaz. CSR (Certificate Signing Request), açık anahtarı ve istenen kimlikleri taşır; özel anahtar sertifika otoritesine gönderilmemelidir.
DNS-01 yenilemesini elle yürütmek kırılgandır. DNS sağlayıcısının API’si ile otomasyon kuruluyorsa kimlik bilgilerine yalnız gereken bölge ve kayıtlar için en az yetki verilmelidir. Tam DNS hesabı yetkisini her web sunucusuna dağıtmak, wildcard sertifikanın anahtar riskine ikinci bir geniş yetki riski ekler.
Doğrulama sorgusu CNAME kaydıyla başka bir ada yönlendirilebilir veya doğrulama alt alanı NS kaydıyla ayrı bir DNS bölgesine devredilebilir; istemcinin ve sertifika otoritesinin bu modeli desteklediği doğrulanmalıdır. Eski TXT değerleri temizlenmeli, DNS yayılım süresi hesaba katılmalı ve otomatik yenileme denemesi gerçek sona erme tarihinden önce izlenmelidir.
CAA Kaydında issuewild ile Wildcard Yetkilendirmesi
CAA (Certification Authority Authorization) DNS kaydı, hangi sertifika otoritelerinin alan adı için sertifika verebileceğini sınırlar. issue etiketi normal alan adları için, issuewild etiketi wildcard adları için yetki tanımlar.
İlgili CAA kayıt kümesinde en az bir issuewild değeri varsa wildcard talebi değerlendirilirken issue değerleri yok sayılır ve issuewild öncelik kazanır. issuewild yoksa issue yetkisi wildcard talebine de uygulanabilir. Kullanılacak sertifika otoritesinin resmi CAA tanımlayıcısı esas alınmalıdır.
CAA, sertifika verilmeden önce sertifika otoritesinin yaptığı bir yetki kontrolüdür. Tarayıcı mevcut bir sertifikayı her bağlantıda CAA kaydıyla yeniden doğrulamaz. CAA kaydının sonradan değiştirilmesi daha önce verilmiş bir sertifikayı otomatik olarak iptal etmez.
Özel Anahtar Paylaşımı Neden Risklidir?
Sertifika kamuya dağıtılan kimlik belgesidir; gizli tutulması gereken unsur ona karşılık gelen özel anahtardır. Aynı wildcard sertifika ve özel anahtar birden fazla sunucuya, CDN’e, yük dengeleyiciye veya barındırma sağlayıcısına kopyalanırsa uç noktalardan birinin ele geçirilmesi ortak anahtarın açığa çıkmasına yol açabilir. Anahtar ele geçirilirse saldırgan sertifikanın kapsadığı adlar için kimliğe bürünme girişiminde bulunabilir.
Farklı ekiplerin, müşterilerin veya güvenlik bölgelerinin yönettiği hizmetlere aynı özel anahtarı dağıtmak yerine yalnız gereken adları içeren ayrı sertifika ve anahtarlar kullanmak riski daraltır. Ayrı anahtarlar üretip her sertifikada aynı geniş wildcard kapsamını bırakmak ise ad düzeyinde ayrım sağlamaz; çalınan anahtar kendi sertifikasının kapsadığı diğer adlar için de kimliğe bürünmede kullanılabilir. Merkezi TLS sonlandırma anahtarı tek korumalı noktada tutabilir; buna karşılık o noktanın kesintisi veya ele geçirilmesi daha çok hizmeti etkileyebilir.
Aynı sertifikanın farklı uygulama protokollerinde kullanılması da gereksiz ortak risk doğurabilir. Protokolün wildcard kimliğini kabul edip etmediği ve sertifikanın genişletilmiş anahtar kullanım alanları ayrıca doğrulanmalıdır. Wildcard desteği her TLS kullanan protokol için otomatik bir garanti değildir.
Sertifika Yenileme ve İptal İşlemleri
Wildcard sertifika sertifika sayısını azaltabilir; fakat tek sertifikanın süresinin dolması onu kullanan bütün uç noktaları aynı anda etkileyebilir. Otomatik yenileme yalnız yeni sertifikanın alınmasını değil, doğru uç noktalara dağıtılmasını, hizmetlerin yeniden yüklenmesini ve yayımdaki sertifikanın değiştiğinin doğrulanmasını kapsamalıdır. Sertifikanın ve anahtarın bulunduğu uç noktaların envanterini tutun; süre dolması, yenileme ve dağıtım hataları için uyarı oluşturun. Yenileme başarısızlığında yalnız geçerli ve anahtarı açığa çıkmamış bir sertifikaya dönülebilir; iptal edilmiş veya ele geçirilmiş sertifika geri dönüş seçeneği değildir.
Özel anahtarın açığa çıktığından şüpheleniliyorsa yalnız sertifikayı yeniden indirmek yeterli değildir. Yeni bir anahtar çifti üretilmeli, yeni sertifika dağıtılmalı, eski sertifika iptal ettirilmeli ve eski anahtarın bulunduğu bütün kopyalar belirlenmelidir.
Sertifika Şeffaflığı ile Beklenmeyen Sertifikaları İzleme
Tarayıcıların herkese açık sertifikalar için uyguladığı CT (Certificate Transparency) politikaları, sertifikanın veya ön sertifikanın CT günlüklerine kaydedilmesini gerektirir. Bu günlükler sertifika verilmesini izlemeye yardımcı olur ve SAN içindeki tam adları veya wildcard girdisini kamuya gösterebilir. CT izleme, beklenmeyen sertifika verilmesini erken fark etmek için CAA ile birlikte kullanılabilir; özel anahtarı korumanın yerine geçmez.
Yayımdaki Sertifikanın Kapsamı Nasıl Doğrulanır?
Yayımdaki sertifika, sorgulanan sunucu adıyla ve SNI bilgisi gönderilerek alınmalıdır. Sertifikanın SAN girdileri, geçerlilik tarihleri, sertifika zinciri ve sunulan uç nokta birlikte incelenir. Yalnız dosya sistemindeki sertifikaya bakmak, yük dengeleyicinin veya CDN’nin gerçekte hangi sertifikayı sunduğunu kanıtlamaz.
Tarayıcının sertifika görüntüleyicisinden sunulan SAN adlarını, geçerlilik tarihlerini ve zinciri inceleyebilirsiniz. Daha ayrıntılı bir TLS testinde yalnız SNI göndermekle kalmayın; ad eşleşmesi ve güven zinciri doğrulamasının da açık olduğundan emin olun. Sonuç yalnız sorgulanan ad, DNS yanıtı ve o anda ulaşılan uç nokta için geçerlidir; her önemli sunucu adı ayrı kontrol edilmelidir.
