DV, OV, EV ve Wildcard Arasındaki Fark
Yeni bir pazaryeri için sertifika seçerken hız, kuruluş doğrulaması ve alan adı kapsamı birlikte değerlendirilir. DV, OV ve EV doğrulama düzeylerini, Wildcard ise alan adı kapsamını belirtir.
Bu rehber normal, genel DNS alan adları kullanan e-ticaret ve SaaS sistemlerine odaklanır. Seçim için üç ayrı soruyu yanıtlayın: hangi kimlik bilgileri doğrulanmalı, hangi host adları kapsanmalı ve anahtarlarla yenileme sürecini kim yönetecek? Sektör adı veya lansmanın yakınlığı tek başına sertifika türünü belirlemez. Geçerli sözleşme, ödeme sağlayıcısı ve kuruluş politikasındaki somut gereksinimleri esas alın.
Önce SSL/TLS ve doğrulama düzeylerini, ardından Wildcard kapsamını ele alacağız. Son bölümde bunları e‑ticaret ve SaaS senaryolarına uygulayacağız.
Şifreleme, Kimlik Doğrulama ve Alan Adı Kapsamı
DV, OV ve EV etiketi bir şifreleme derecesi değildir. Aynı uygun TLS yapılandırması ve algoritmalarla bu türler benzer aktarım koruması sağlayabilir. Fark, CA’nın sertifikayı vermeden önce doğruladığı bilgiler ve sertifikadaki kimlik alanlarıdır. HTTPS aktarımı korur; sertifika türü tek başına uygulamanın güvenliğini, satıcının dürüstlüğünü veya ödeme sürecinin uyumunu kanıtlamaz.
DV alan adı kontrolünü veya yetkilendirmesini doğrular. OV, alan adı doğrulamasına ek olarak kuruluşun kimlik ve adres bilgilerini kontrol eder. EV; hukuki, fiziksel ve operasyonel varlık ile başvuru yetkileri için daha ayrıntılı kurallar uygular. Wildcard bu sıralamanın dördüncü düzeyi değildir; sertifikanın kapsadığı adları belirler. Kuruluş bilgisinin sertifikada yer alması ile tarayıcının bunu nasıl gösterdiği de farklı konulardır.
Blog, dokümantasyon, giriş paneli veya mağaza için önce gerekli adları ve kimlik doğrulama şartlarını belirleyin. Kuruluş doğrulaması gerekmiyorsa DV uygun bir seçenek olabilir. Partner veya satın alma süreci doğrulanmış kuruluş bilgisi istiyorsa OV, açıkça EV düzeyi istiyorsa EV değerlendirilir. Bunu bir “küçük site DV, büyük site EV” kuralına çevirmeyin; aynı kuruluş farklı ihtiyaçlar için farklı doğrulama düzeyleri kullanabilir.
DV: Alan Adı Kontrolünün Doğrulanması
DV Ne Doğrular?
DV, başvuranın ilgili alan adı üzerinde kontrol veya yetkisini CA’nın izin verdiği yöntemle kanıtlamasını gerektirir. Yöntemler CA’ya ve güncel kurallara bağlıdır; bütün ürünlerde aynı e-posta, dosya veya DNS seçeneğinin bulunduğunu varsaymayın. Let’s Encrypt ve ACME belgeleri bu CA’nın desteklediği challenge akışlarını açıklar. Düzenleme bazen hızlı olabilir, ancak DNS yayılımı, erişim, kota veya inceleme nedeniyle sabit birkaç dakikalık teslim süresi garanti edilemez.
DV Hangi Gereksinimleri Karşılayabilir?
Kuruluş kimliği doğrulaması gerekmeyen uygulamalarda DV, otomasyona uygun bir seçim olabilir. Buna mağazalar ve kullanıcı girişi bulunan hizmetler de dahildir; DV yalnız kişisel bloglarla sınırlı değildir. Ödeme sağlayıcısına yönlendirmek veya hazır ödeme bileşeni kullanmak tek başına sertifika ve uyum gereksinimlerini belirlemez. Gerçek veri akışını ve geçerli şartları kontrol edin, ardından gerekli TLS koruması ve yenileme desteği bulunan ürünü seçin.
DV’nin Kapsamadığı Kuruluş Bilgileri
DV, sertifikada kuruluş kimliğinin doğrulandığı anlamına gelmez. Böyle bir bilgi gerekiyorsa uygun OV/EV ürününü ve CA’nın hangi bilgileri doğruladığını inceleyin. Kullanıcı güveni veya satış artışını yalnız sertifika etiketine bağlamayın. Operasyon açısından DV de sahiplik kaydı, güvenli özel anahtar saklama, çalışan doğrulama yolu ve yenileme sonrası kontrol ister; otomasyon kurulmuş olması kendiliğinden sorunsuz yenileme garantisi değildir.
OV: Kuruluş Kimliğinin Doğrulanması
OV’de Ek Olarak Neler Doğrulanır?
OV, alan adı kontrolüne ek olarak sertifikada yer alacak kuruluş kimliğini ve adresini doğrular. CA/Browser Forum kuralları resmî kayıtlar, güvenilir veri kaynakları veya diğer kabul edilen kanıtları tanımlar; her başvurunun aynı evrak veya telefon adımını izlemesi gerekmez. Doğrulanmış bilgiler sertifika ayrıntılarında bulunabilir. OV’nin adres çubuğunda ayrı bir güven rozeti veya site içeriğine onay sağlamasını beklemeyin.
OV Gereksinimini Belirleme
B2B portalı, partner girişi veya kurumsal uygulama için OV; ilgili süreç doğrulanmış kuruluş bilgisini gerçekten istiyorsa anlamlıdır. Gereksinimin hangi hostları kapsadığını, sertifikada hangi kuruluşun görünmesi gerektiğini ve CA ürününün bunu karşılayıp karşılamadığını belirleyin. Ana alanın OV olması diğer bütün alt alanlarda da OV gerektirmez; kapsamı yazılı gereksinim ve işletim modeline göre planlayın.
OV Düzenleme ve Yenileme Süreci
Kuruluşun resmî adı, adresi, temsilci yetkileri ve erişilebilir iletişim bilgilerini güncel tutun. CA’nın kabul ettiği doğrulama yöntemi, tekrar doğrulama ihtiyacı ve otomasyon desteği ürün bazında değişebilir. OV yenilemesinin her seferinde tamamen manuel veya her zaman tamamen otomatik olduğunu varsaymayın. Sağlayıcıdan desteklenen yenileme/API akışını ve olası inceleme süresini doğrulayarak lansman ve yenileme payını ayırın.
EV: Genişletilmiş Kuruluş Doğrulaması
EV’nin Doğrulama Kapsamı
EV, kuruluşun hukuki, fiziksel ve operasyonel varlığı ile alan adı kontrolü ve başvuruyu onaylayan kişilerin yetkilerini daha ayrıntılı kurallarla doğrular. Bu doğrulama uygulama güvenliği denetimi veya işletmenin hizmet kalitesi garantisi değildir. İlgili sözleşme ya da politika EV istiyorsa tam kapsamını inceleyin; finans, sağlık veya kamu alanında çalışmak tek başına bütün hostlar için EV zorunluluğu oluşturmaz.
EV ve Açıkça Tanımlanmış Gereksinimler
EV, açık bir kuruluş doğrulama gereksinimini karşıladığında değerlendirilebilir. Tarayıcıların görünümü sürüme göre değişir; sürekli yeşil adres çubuğu veya herkesin fark edeceği özel bir işaret vaat etmeyin. Bu rehberdeki normal DNS alan adlarında EV wildcard kullanılamaz; gereken adlar açıkça listelenmelidir. EV kurallarındaki özel .onion istisnası, buradaki genel web alan adı senaryosundan ayrıdır.
EV’nin Sağlamadığı Garantiler
EV seçimi hatalı sertifika düzenlenmesini tamamen engellemez, daha güçlü TLS şifrelemesini kendiliğinden kurmaz ve dönüşüm artışı garantilemez. Belge toplama ve CA incelemesini lansman planına ekleyin, ancak her EV siparişinin her OV siparişinden daha uzun süreceği gibi sabit süre karşılaştırmaları yapmayın. Gereksinim daha düşük doğrulama düzeyiyle karşılanıyorsa daha yüksek düzeyi yalnız varsayılan “güven artışı” için zorunlu saymayın.
Wildcard: Tek Etiket Düzeyinde Alt Alan Kapsamı
Wildcard Hangi Adlarla Eşleşir?
*.example.com bir etiket düzeyini kapsar: app.example.com ve api.example.com eşleşir; example.com kökü ve app.eu.example.com eşleşmez. Kök gerekiyorsa ayrıca SAN olarak ekleyin; daha derin adlar için uygun ayrı kapsam gerekir. Yeni bir ad geçerli wildcard kapsamıyla eşleşiyorsa sırf o ad açıldı diye yeni sertifika almak gerekmez. Yine de adın doğru sunucuya yönlendiği ve sunucunun bu sertifikayı sunduğu doğrulanmalıdır.
Anahtar Dağıtımı ve Yenileme Yetkileri
Wildcard anahtarının erişebildiği kapsamı ve nerelere dağıtıldığını envanterde tutun. Aynı anahtarın çok sayıda sunucuya verilmesi tek sızıntıda daha geniş bir değişiklik gerektirebilir. Let’s Encrypt wildcard düzenlemek için DNS-01 ister; otomatik yenilemede sınırlı yetkili DNS API erişimi veya desteklenen challenge yönlendirmesi gerekir. DNS yayılımı ve etkin TXT değerlerinin korunması izlenmelidir. Diğer CA ürünlerinde izin verilen doğrulama yöntemini ayrıca kontrol edin.
Normal DNS wildcard ürünleri DV veya OV düzeyinde bulunabilir; kullanılabilirlik sağlayıcıya bağlıdır. EV gereksinimi varsa hostları açık SAN adlarıyla gruplayın veya ayrı sertifikalar planlayın. Kritik bir adın ayrı sertifikası olması, aynı adı kapsayan geniş bir wildcard anahtarının yetkisini kaldırmaz. İzolasyon için yalnız sertifika sayısını değil kalan wildcard kapsamını, özel anahtar erişimini ve TLS sonlandırma mimarisini de değiştirmeniz gerekebilir.
E-Ticaret İçin Sertifika Seçimi
Yeni Mağaza ve Ödeme Sağlayıcısı
Yeni bir mağaza için gerekli kök/www adlarını, ödeme yönlendirmesini ve kuruluş doğrulama şartlarını çıkarın. DV şartları karşılıyorsa uygun bir başlangıç olabilir; ödeme sağlayıcısının kullanılması bütün sorumlulukları ortadan kaldırmaz. HTTPS yönlendirmeleri, güvenilir zincir, uygulama güvenliği ve yenileme kontrolleri doğrulama düzeyinden ayrı gereksinimlerdir. Kullanıcının ödeme sağlayıcısına geçişini açık gösterin; sertifika türünü sayfa hızı veya satış sonucu garantisi olarak sunmayın.
B2B ve Partner Gereksinimleri
Partnerler belirli kuruluş doğrulamasını istiyorsa bunu host ve tüzel kişi kapsamıyla belgelendirin. Mevcut DV yerine uygun OV düzenlenip kontrollü biçimde yüklenebilir; alan adını değiştirmek gerekmez. Yeni zincirin istemcilerce güvenildiğini ve hedef sunucuda sunulduğunu sınayın. Sertifika değişimi tek başına satış sürecini hızlandırmaz veya müşteri itirazlarını gidermez; teknik teslim sonucu ile ticari beklentiyi ayırın.
Ödeme Akışının Kapsamını Doğrulama
Ödeme sayfasının hangi bileşenlerde çalıştığını ve hangi tarafın kart verisini işlediğini belirleyin. Kendi alanınızda form bulunması veya dış sağlayıcı kullanılması tek başına DV/OV/EV kararı ya da PCI uygunluğu sonucu vermez. İlgili ödeme programı, sözleşme ve güvenlik gereksinimlerini gerçek veri akışına göre değerlendirin. HSTS, çerezler, yönlendirmeler ve uygulama korumaları ayrıca yapılandırılır; kuruluş doğrulama düzeyi bunların yerine geçmez.
Pazaryerinde Alt Alanlar ve Anahtar Sınırları
Pazaryerindeki satıcı paneli, katalog ve diğer alt alanların aynı idari sınırda olup olmadığını belirleyin. Wildcard eşleşen adları topluca kapsayabilir; ayrı sertifika ve anahtarlar bazı dağıtımları bağımsızlaştırabilir. Ancak çalınan geniş kapsamlı wildcard anahtarı hâlâ kritik adı kapsıyorsa ayrı sertifika o adı korumaz. Anahtar sızıntısında kapsam içindeki bütün dağıtımları belirleyip yeni anahtar/sertifika ve iptal işlemini koordine edin.
SaaS: Kiracı Alt Alanları ve Müşteriye Ait Alanlar
Müşterinin Kendi Alan Adında Doğrulama
Müşterinin portal.customer.example gibi kendi adını SaaS’e yönlendirmesi, platform wildcard’ınızın bu adı kapsadığı anlamına gelmez. Gerekli ad için uygun sertifika ve CA’nın desteklediği doğrulama yolu gerekir. Uygulama CNAME’i tek başına bütün doğrulamayı tamamlamaz: yönlenen hostta HTTP-01 veya gerektiğinde ayrı challenge DNS yönlendirmesi gibi akışlar çalışmalıdır. Let’s Encrypt HTTP-01 için dışarıdan port 80 erişimi ve isteği karşılayabilecek tüm ön uçlarda doğru challenge yanıtı gerekir. Müşteri alan adı kontrolü ve yenileme erişimi sürdürülebildiğinde, gereksinimleri karşılayan DV otomasyonu bir seçenek olabilir.
Yönetim Panellerinde Kimlik ve Erişim
Yönetim ve partner panellerinde OV/EV ihtiyacını doğrulanmış kuruluş bilgisi şartıyla belirleyin. Bu sertifikalar panele kimin giriş yapabileceğini denetlemez; uygulama yetkilendirmesi ve yönetici erişimi ayrıca tasarlanmalıdır. Kiracı alt alanlarında wildcard veya ayrı anahtarlı sertifikalar arasında karar verirken anahtarın nerede sonlandığını ve kimlerin erişebildiğini değerlendirin. Kurumsal görünüm gerekçesiyle erişim sınırlarını ikinci plana atmayın.
Yenileme ile Dağıtımı Ayrı Kontrol Etme
Node.js, Nginx ve TLS dağıtım rehberi uygulama ortamındaki yükleme adımlarına örnek sağlar. Seçilen yığın ne olursa olsun yenilemeyi gerçek sertifika ömrü ve destekleniyorsa ARI aralığıyla planlayın, kota/Retry-After bilgisine uyun ve başarısız deneme payı bırakın. Yeni sertifika alındıktan sonra anahtar/SAN/zincir kontrolü, yapılandırma testi, desteklenen yeniden yükleme ve yeni bağlantıda doğrulama gerekir. Kesintisizlik ölçülmeden garanti edilemez.
CA Kuralları ve TLS Yapılandırma Kaynakları
CA/Browser Forum temel gereksinimleri CA’nın doğrulama ve sertifika düzenleme kurallarını açıklar; belirli bir uygulama veya ödeme akışı için tam uyum değerlendirmesi değildir. Let’s Encrypt belgeleri o CA’nın ACME koşullarını, Mozilla TLS yapılandırma aracı ise seçilen sunucu ve uyumluluk hedefi için bir başlangıcı sağlar. Doğrulama düzeyi, sertifika kapsamı ve TLS yapılandırmasını ayrı kaynaklarla denetleyin.
Sertifika Seçiminde Yaygın Yanılgılar
Wildcard’ın Kök Alanı Kapsadığı Varsayımı
Canlıya geçmeden gereken adları SAN listesiyle tek tek eşleştirin. *.example.com kökü ve daha derin alt alanları kapsamaz; yönlendirilen bir hostun sertifikası da ilk bağlantıda doğru olmalıdır. Kökten www’ye yönlendirme yapmak, kökün sertifika ihtiyacını kaldırmaz. Alan adı kapsamı hatasını protokol ayarını değiştirerek gidermeye çalışmayın.
EV ile Sürekli Yeşil Adres Çubuğu Beklentisi
Firefox EV göstergesini adres çubuğundan site bilgileri alanına taşımıştır; Chrome da bağlantı simgesinin site güvenilirliği anlamına gelmediğini açıklar. Arayüz tarayıcı ve sürüme bağlıdır. EV’yi herkesin göreceği yeşil çubuk beklentisiyle seçmeyin; esas fark sertifikadan önceki kuruluş doğrulaması ve gerekiyorsa bunun belgelendirilmesidir.
DV’nin Daha Zayıf Şifreleme Sağladığı İddiası
Doğrulama düzeyi ile aktarım şifrelemesini ayırın. DV’nin eksik kuruluş bilgisi, aynı TLS ayarları altında daha zayıf algoritma kullandığı anlamına gelmez. Tersine, EV etiketi eski TLS sürümünü veya güvenli olmayan uygulamayı düzeltmez. Protokol, algoritma, zincir ve istemci desteğini bağımsız kontrol edin; kullanıcıya gösterilen ticari bilgiler için de doğru ve açık içerik sağlayın.
Ayrı Sertifikanın Wildcard Anahtarından İzole Olduğu Varsayımı
Anahtar izolasyonunu sertifika dosyasının adına bakarak değerlendirmeyin. Hangi anahtarın hangi hostları doğrulayabildiğini, hangi sistemlerde saklandığını ve kimlerin onu kullanabildiğini inceleyin. Geniş wildcard yetkisi devam ederken kritik hosta ayrı sertifika eklemek tek başına bu yetkiyi daraltmaz. Sızıntıda yeni anahtarla dağıtım ve etkilenen sertifikanın iptali gerekir; kısa ömür otomatik olarak bu müdahalenin yerine geçmez.
Sertifika Seçimi İçin Kontrol Listesi
Kararı şu sırayla verin: gerekli hostları ve wildcard eşleşmesini çıkarın; yazılı kuruluş doğrulama şartını belirleyin; CA/ürünün izin verdiği yöntemleri ve teslim koşullarını doğrulayın; anahtar erişimi ile yenileme sahibini atayın; gerçek TLS uç noktalarında kabul testini yapın. Şartları karşılayan DV, OV veya EV seçimi ile wildcard kapsamı birbirinden bağımsız kararlardır. Satış artışı, daha güçlü şifreleme veya kesintisiz hizmet vaadi yerine doğrulanabilir teknik ve sözleşmesel sonuçları esas alın.
