DV, OV ve EV SSL Sertifikaları Arasındaki Farklar: Kurumsal ve E‑Ticaret Siteleri İçin Yol Haritası

DV, OV ve EV SSL Seçimi Neden Bu Kadar Önemli?

Kurumsal bir web sitesi ya da gelir üreten bir e‑ticaret projesi yönetiyorsanız, “Herhangi bir SSL olsun da yeter” dönemi çoktan bitti. Tarayıcıdaki kilit simgesi artık tek başına güven demek değil; kullanıcılar, bankalar, ödeme kuruluşları, hatta B2B müşterileriniz sitenizin arkasında gerçekten kim olduğunu görmek istiyor. İşte tam bu noktada DV, OV ve EV SSL sertifikaları arasındaki farklar kritik hale geliyor.

Planlama toplantılarında sık duyduğumuz sorular hep aynı: “Küçük bir e‑ticaret için DV yeter mi?”, “Kurumsal sitemizde EV’ye gerçekten gerek var mı?”, “Teknik olarak hepsi aynı şifrelemeyi veriyorsa neden daha pahalı bir sertifika alayım?” DCHost ekibi olarak yüzlerce kurumsal site ve farklı ölçeklerde e‑ticaret projesiyle çalışırken gördük ki, doğru SSL türü hem güven algısını hem de iş süreçlerini doğrudan etkiliyor. Özellikle ödeme sayfaları, müşteri panelleri, bayilik portalları ve API uç noktalarında yapılacak yanlış bir tercih, gereksiz maliyetlere ya da güven kaybına yol açabiliyor.

Bu yazıda pazarlama cümlelerinden uzak durup konuyu netleştireceğiz: DV, OV ve EV SSL tam olarak neyi doğruluyor, teknik olarak neleri değiştiriyor, kurumsal ve e‑ticaret tarafında hangi senaryoda hangisini seçmek daha mantıklı? DCHost altyapısını kullansanız da kullanmasanız da, elinizde somut bir karar rehberi olsun istiyoruz.

Temel Kavramlar: SSL, TLS ve Doğrulama Türleri

Önce zemini sağlamlaştıralım. SSL sertifikası dediğimiz şey aslında teknik olarak TLS protokolünü kullanan dijital bir kimlik belgesidir. Tarayıcı ile sunucu arasındaki trafiği şifreler, ayrıca tarayıcıya “Ben gerçekten şu alan adına ait sunucuyum” der. SSL ve TLS isim olarak farklı görünse de, bugün pratikte “SSL” dendiğinde modern TLS sürümlerini de kapsayan genel bir isimlendirme kullanıyoruz.

Bir sertifikayı değerli yapan iki temel boyut var:

• Şifreleme gücü: Kullanılan protokol (TLS 1.2 / 1.3), anahtar uzunluğu, şifre paketleri vb.
• Kimlik doğrulama seviyesi: Sertifikanın kime verildiği ne kadar detaylı kontrol ediliyor? Sadece alan adının kontrolü mü, yoksa şirketin ticari varlığı da teyit ediliyor mu?

DV, OV ve EV SSL arasındaki fark, ikinci maddede yani kimlik doğrulama seviyesinde ortaya çıkar. Şifreleme tarafında doğru kurulum yapıldığında üçü de aynı güvenlik seviyesini sunabilir; fark, kullanıcının ve tarayıcının ne kadar “kime bağlandığından emin” olduğudur.

SSL kavramına daha temelden hakim olmak isterseniz, önce SSL sertifikası nedir ve web sitenizi nasıl güvence altına alır başlıklı rehberimize göz atmanız faydalı olabilir.

DV SSL Nedir? Avantajları, Sınırları ve Uygun Olduğu Senaryolar

DV (Domain Validation), yani Alan Adı Doğrulamalı SSL, doğrulama seviyesinin en temel halidir. Sertifika otoritesi yalnızca şu soruya cevap arar: “Bu alan adının kontrolü gerçekten bu başvuruyu yapan kişide mi?” Bunu genellikle DNS kaydı, HTTP doğrulama dosyası veya e‑posta ile test eder.

DV SSL’in başlıca özellikleri:

• Hızlı kurulum: Doğrulama otomatik olduğu için çoğu zaman dakikalar içinde aktif olur.
• Düşük maliyet: Kurumsal teyit yapılmadığı için sertifika ücretleri genellikle daha uygun seviyededir.
• Otomasyona uygun: ACME protokolü üzerinden otomatik yenileme ve kurulum süreçleri kolaydır.
• Tarayıcı davranışı: Tarayıcı kilit simgesi görünür, bağlantı HTTPS olur; ancak kullanıcı sertifika detayına bakmadıkça arkasında bir şirket bilgisi görmez.

DV SSL hangi siteler için idealdir?

• Kişisel bloglar, portföy siteleri
• Basit tanıtım siteleri, tek sayfalık landing page’ler
• İçerik ağırlıklı, kullanıcıdan hassas bilgi almayan projeler
• Test, staging ve geliştirme ortamları

Peki e‑ticaret için DV SSL yeterli mi? Teknik açıdan bakarsanız, güçlü TLS sürümleriyle kurulmuş bir DV SSL, ödeme sayfasındaki veriyi de OV veya EV kadar iyi şifreler. Ancak işin güven algısı ve uyumluluk tarafında tablo değişiyor. Kullanıcı sertifika detayında şirket adını göremediğinde, özellikle marka bilinirliği düşükse, “Bu site gerçekten yasal bir işletmeye mi ait?” soru işareti oluşabiliyor.

Özetle: Küçük çaplı, yeni başlayan bir e‑ticaret için DV, erken aşamada maliyeti düşük bir çözüm olabilir. Ancak kurumsal imaj, B2B ilişkiler, pazar yeri entegrasyonları ve uzun vadeli marka stratejisi düşündüğünüz anda DV genellikle kısa süreli bir ara çözüm olarak kalır.

OV SSL Nedir? Kurumsal Kimlik Doğrulaması ve B2B Güveni

OV (Organization Validation), yani Kurumsal Doğrulama seviyesinde sertifika otoritesi sadece alan adının kontrolünü değil, aynı zamanda arkasındaki şirketin gerçekten var olup olmadığını da teyit eder. Ticaret sicil kayıtları, vergi numarası, resmî adres ve çoğu zaman telefon doğrulaması bu sürece dahildir.

OV SSL’in öne çıkan noktaları:

• Şirket bilgisi sertifikaya yazılır: Sertifika detayını açan kullanıcı “Organization” alanında şirket adını görür.
• Daha yüksek kurumsal güven: B2B müşteriler, bayiler, tedarikçiler açısından “Bu alan adının arkasında gerçek bir tüzel kişilik var” mesajı netleşir.
• Orta seviye maliyet ve süre: DV’den daha pahalı ve başvuru süreci daha uzundur, ancak genelde birkaç gün içinde sonuçlanır.
• Özellikle paneller ve API’ler için tercih edilir: Yönetim panelleri, intranet, B2B portallar, SSO (Single Sign-On) servisleri gibi alanlarda kurumsal kimlik teyidi önemlidir.

OV SSL hangi kurumsal senaryolarda mantıklı?

• Şirketin ana kurumsal web sitesi (özellikle .com.tr, .com ve benzeri ana alanlar)
• Müşteri panelleri, bayilik ve distribütör portalları
• Kurumsal e‑posta, dosya paylaşım servisleri, VPN son noktaları
• API uç noktaları ve entegrasyon yapılan sistemler

Birçok kurumsal müşteri, ihale dokümanlarında veya bilgi güvenliği politikalarında, kritik sistemlerin en az OV seviyesinde kimlik doğrulaması yapılmış SSL ile yayınlanmasını şart koşuyor. Özellikle B2B iş yapan üretici, lojistik, yazılım ve danışmanlık şirketlerinde, OV sertifikalar hem iç denetim hem de dış denetim süreçlerinde artı puan getiriyor.

DCHost tarafında da, kurumsal siteler ve paneller için tür seçimi yaparken, marka itibarı ve regülasyon risklerini birlikte değerlendirip çoğu zaman minimum seviye olarak OV öneriyoruz.

EV SSL Nedir? En Üst Düzey Kurumsal Güven

EV (Extended Validation), yani Genişletilmiş Doğrulama, sertifika dünyasının en detaylı kimlik doğrulama sürecine sahip seviyesidir. Burada amaç sadece şirketin varlığını değil, aynı zamanda bu sertifika başvurusunu yapan kişinin şirket adına hareket etmeye yetkili olup olmadığını da net olarak teyit etmektir.

EV SSL başvuru sürecinde genellikle şunlar kontrol edilir:

• Resmî ticaret sicil kayıtları ve şirket türü
• Fiziksel adres, telefon ve iletişim bilgileri
• Sertifikayı talep eden kişinin yetkilendirilmiş olup olmadığı
• Bazı durumlarda noter onaylı belgeler ve imza sirküleri

Tarayıcı tarafındaki göstergeler yıllar içinde değişti; eskiden adres çubuğunda büyük yeşil bar ve şirket adı görünürken, günümüzde çoğu tarayıcı tasarımı sadeleştirdi. Yine de sertifika detayına bakan kullanıcılar, EV sertifikalarda “Extended Validation” ifadesini ve doğrulanmış şirket adını net bir şekilde görürler.

EV SSL hangi sektörlerde gerçekten anlamlı değer yaratır?

• Bankalar, finans kuruluşları, ödeme ve elektronik para şirketleri
• Sigorta, sağlık, kamu ihaleleri gibi yüksek regülasyonlu alanlar
• Yıllık ciro ve kullanıcı hacmi yüksek, marka değeri oturmuş e‑ticaret siteleri
• Hassas kişisel veri işleyen, KVKK/GDPR denetimlerine sık giren kurumlar

EV SSL, maliyeti ve bürokratik süreci nedeniyle herkes için gerekli değil. Fakat regülasyona tabi sektörlerde ve büyük markalarda, “Her noktada en üst düzey formal güven” stratejisinin önemli bir parçası oluyor. DCHost olarak finans, sağlık veya kamuya iş yapan müşterilerimizde, güvenlik denetimleriyle uyumu kolaylaştırmak için çoğu zaman EV seviyesini masaya yatırıyoruz.

DV, OV ve EV SSL Teknik Olarak Aynı mı?

Sık sorulan ve çoğu zaman kafa karıştıran noktalardan biri şu: “Hepsi TLS kullanıyor, hepsi 256 bit şifreleme sunuyor, o zaman neden daha pahalı bir sertifika alayım?”

Şu ayrımı netleştirelim:

• Şifreleme katmanı: Doğru kurulum yapılmış bir DV, OV veya EV sertifika, aynı protokol ve aynı şifre paketlerini kullanabilir. Örneğin TLS 1.3, modern ECDHE anahtar değişimi ve güçlü şifreler üçünde de mümkündür.
• Kimlik doğrulama katmanı: Fark tamamen burada. DV’de yalnızca alan adının kontrolü doğrulanırken, OV ve EV’de arkasındaki tüzel kişilik ve yetkili kişi/kişiler de teyit edilir.

Yani “DV teknik olarak daha zayıf, EV daha güçlü şifreleme sağlıyor” demek doğru değildir. Doğru cümle şudur: “DV, OV ve EV arasında fark; bağlantının ne kadar iyi şifrelendiğinde değil, kiminle iletişim kurduğunuzdan ne kadar emin olduğunuzdadır.”

Bu noktada hatırlatmakta fayda var: Kullanılan protokol sürümleri (TLS 1.0/1.1 devre dışı, TLS 1.2/1.3 aktif olması vb.) ve şifre paketleri, sertifika türünden bağımsız olarak sunucu yapılandırması ile ilgilidir. Bu konuyu daha derinlemesine ele aldığımız TLS 1.3 ve modern şifrelerin sunucu tarafında doğru kurulumu rehberine mutlaka göz atmanızı öneririz.

Kurumsal Web Siteleri İçin DV, OV ve EV Karşılaştırması

Kurumsal sitelerde genellikle doğrudan ödeme alınmaz, ancak marka itibarı, insan kaynakları başvuruları, bayi formları, iletişim talepleri gibi değerli süreçler yürür. Bu yüzden “Nasıl olsa ödeme almıyorum, DV yeter” bakışı çoğu zaman eksik kalır.

Aşağıdaki tablo, kurumsal bir web sitesi için üç sertifika türünün pratik karşılaştırmasını özetler:

DCHost müşterilerinde gördüğümüz örnekler üzerinden konuşursak:

• KOBİ seviyesinde bir kurumsal site: Henüz büyük kamu ihalelerine girmeyen, fakat bayi ağı, referanslar ve insan kaynakları süreçleri yürüten firmalarda OV SSL genellikle ideal dengeyi sağlar.
• Kurumsal holding yapıları: Ana holding alan adı ve yatırımcı ilişkileri gibi yüksek itibarlı sayfalarda çoğu zaman EV değerlendirilir; grup şirketlerinin standart kurumsal sitelerinde OV tercih edilir.
• Kamuya iş yapan teknoloji şirketleri: Güvenlik şartnamesine göre en az OV, bazı durumlarda kritik portallar için EV şart koşulabilir.

Kurumsal web sitenizin mimarisini daha bütüncül ele almak isterseniz, DNS, hosting ve SSL’in nasıl birlikte kurgulanması gerektiğini anlattığımız “Domain, DNS, sunucu ve SSL nasıl birlikte çalışır” rehberinden de yararlanabilirsiniz.

E‑Ticaret Siteleri İçin Doğru SSL Türü Nasıl Seçilir?

E‑ticaret tarafında konu daha kritik, çünkü burada doğrudan ödeme, kişisel veri ve dolandırıcılık riskleri söz konusu. Kullanıcı ödeme sayfasına geldiğinde saniyeler içinde karar veriyor: “Bu siteye kart bilgilerimi emanet eder miyim?”

Senaryolar üzerinden netleştirelim:

1. Yeni açılan, küçük ölçekli butik e‑ticaret

Yeni bir marka, sınırlı ürün portföyü, başlangıç bütçesi kısıtlı. Ödeme çoğunlukla güvenilir aracı ödeme kuruluşları üzerinden alınıyor. Bu aşamada:

• Başlangıçta DV SSL ile hızlıca yayına çıkmak mantıklı olabilir.
• Marka bilinirliğiniz arttıkça, özellikle B2B siparişler veya kurumsal satışlar başlamaya yakın OV SSL’e geçmek güven algısını artırır.

2. Orta ölçekli, niş alanda uzmanlaşmış e‑ticaret

Belirli bir sektörde (örneğin endüstriyel ürünler, medikal sarf malzemeler, B2B yazılım lisansları) uzmanlaşmış, tekrar eden kurumsal siparişler alan siteler için:

• Minimum seviyede OV SSL önerilir; böylece sipariş veren şirketler, sertifika detayında sizin gerçek bir tüzel kişilik olduğunuzu görebilir.
• Kurumsal panel, bayi portalı veya distribütör girişleri varsa, bu alt alanlarda da en az OV kullanılmasını tavsiye ediyoruz.

3. Yüksek hacimli, bilinirliği yüksek e‑ticaret

Geniş ürün yelpazesi, yoğun kampanyalar, TV reklamları, büyük trafik dalgalanmaları… Bu seviyede tartışma genellikle “EV gerekli mi?” noktasına gelir.

• Ödeme ve müşteri paneli tarafında EV SSL, güvenlik denetimlerine, PCI DSS süreçlerine ve banka/ödeme kuruluşu entegrasyonlarına psikolojik ve kurumsal düzeyde katkı sağlar.
• Ana vitrin ve içerik alanlarında OV, kritik ödeme ve hesap yönetimi sayfalarında EV kombinasyonu en sık gördüğümüz modeldir.

Bu resmin bir de uyumluluk tarafı var. Ödeme tarafındaki teknik gereksinimleri daha geniş açıdan ele aldığımız PCI DSS uyumlu e‑ticaret hosting rehberimizde, SSL türü, protokol sürümleri ve güvenlik başlıklarının birlikte nasıl kurgulanması gerektiğini detaylı anlatıyoruz.

Wildcard, Multi‑Domain ve Çoklu Ortam Senaryolarında Seçim

Gerçek hayatta işler genellikle tek alan adı ve tek sertifikadan ibaret değil. Aynı markanın birden çok alt alanı (www, api, panel, bayiler, cdn vb.) olabiliyor. Burada devreye wildcard ve SAN (multi‑domain) sertifikalar giriyor.

Kısa özet:

• Wildcard SSL: *.alanadiniz.com biçiminde bir sertifika ile tüm birinci seviye alt alanları kapsar (www, panel, api, shop vb.). Genellikle DV veya OV seviyesinde kullanılır.
• SAN / Multi‑Domain SSL: Bir sertifikatla birden fazla alan adı veya alt alanı (ör. site.com, shop.site.com, site.com.tr) kapsar. DV, OV ve EV kombinasyonları mümkündür.

Çok alan adlı yapılarda doğru seçim için, wildcard SSL mi SAN (multi‑domain) sertifika mı daha mantıklı sorusunu ayrı bir rehberde detaylı anlattık. Bu yazıda ise şu prensibi vurgulayalım: Birden fazla kritik sistemi tek sertifikaya bağlarken, olası bir yenileme/iptal sorununun hepsini aynı anda etkileyeceğini mutlaka hesaba katın.

Teknik Ayrıntılar: HTTPS Geçişi, Mixed Content ve Güvenlik Başlıkları

Doğru SSL türünü seçmek işin sadece ilk adımı. Kurumsal ve e‑ticaret sitelerinde asıl sorunlar, sertifika alındıktan sonra yanlış veya eksik sunucu yapılandırmalarından kaynaklanıyor.

HTTP’den HTTPS’e geçişi doğru yapmak

Yanlış yapılan yönlendirmeler, sonsuz döngüler, SEO kaybı ve tarayıcılarda “Güvenli değil” uyarıları… Bunların çoğu teknik olarak basit ama dikkat gerektiren ayrıntılardan doğuyor. Adım adım, 301 yönlendirmeleri, HSTS politikaları ve SEO etkilerini anlattığımız HTTP’den HTTPS’e geçiş rehberimize göz atarak bu süreci plansız değil, kontrollü yönetebilirsiniz.

Mixed content ve güvensiz içerik uyarılarını temizlemek

Sertifikanız doğru kurulsa bile, sayfa içinde HTTP ile çağrılan resim, JS veya CSS dosyaları varsa tarayıcı “Bu sayfa tamamen güvenli değil” uyarısı gösterir. Özellikle e‑ticaret sepet ve ödeme sayfalarında bu uyarılar kullanıcı güvenini ciddi şekilde düşürür. Bu sorunu tespit ve temizleme yollarını, SSL sonrası mixed content ve güvensiz içerik hatalarını düzeltme rehberinde adım adım anlattık.

HTTP güvenlik başlıklarını ihmal etmemek

HSTS, CSP, X‑Frame‑Options, Referrer‑Policy gibi HTTP güvenlik başlıkları, SSL’in sağladığı güvenlik katmanını tamamlar. Örneğin HSTS ile tarayıcıya “Bu alan adına asla HTTP ile bağlanma, her zaman HTTPS kullan” talimatı verebilir, CSP ile XSS risklerini azaltabilirsiniz. Bu başlıkları sunucu tarafında nasıl doğru kuracağınız konusunda, HTTP güvenlik başlıkları rehberimiz kapsamlı bir yol haritası sunuyor.

Çok Domainli ve Çok Ortamlı Yapılarda Sertifika Yönetimi

Ajanslar, SaaS üreticileri, çok markalı gruplar veya geniş domain portföyüne sahip şirketlerde, iş “Tek alan adım için bir SSL alayım” noktasından çıkıyor. Onlarca alan adı, staging/canlı ortam ayrımı ve farklı SSL türleri işin içine giriyor.

Bu noktada kritik başlıklar:

• Süre sonu takibi: Bitmeye yaklaşan sertifikaların önceden tespiti
• Otomasyon: ACME tabanlı otomatik yenileme, CI/CD süreçlerine entegrasyon
• Risk dağıtımı: Kritik alan adlarını tek bir wildcard veya SAN sertifikaya hapsetmeme

Çok sayıda domain yöneten ekipler için, onlarca alan adı için SSL sertifika süre sonu izleme ve otomatik yenileme stratejilerini anlattığımız rehber özellikle faydalı. Daha ileri seviyede, ACME, DNS‑01 ve çok kiracılı mimarilerle SSL sertifika otomasyonu yazımız da SaaS ve ajans senaryolarında yol gösterici olacaktır.

DCHost Müşterileri İçin Pratik Yol Haritası

DCHost tarafında SSL seçimi ve kurulumu, sadece bir ürün satışı olarak değil, güvenlik mimarisinin parçası olarak ele alınıyor. paylaşımlı hosting, VPS, dedicated sunucu veya colocation hizmetlerimizden hangisini kullanıyor olursanız olun, şu adımları birlikte netleştirmeyi tercih ediyoruz:

1. Proje analizini yapmak: Site türü (kurumsal, e‑ticaret, SaaS), trafik hacmi, kullanıcı profili, regülasyon gereksinimleri.
2. Alan adı mimarisini çıkarmak: Tek alan adı mı, çoklu alan adı mı, alt alan yapılandırması nasıl?
3. Uygun SSL türünü seçmek: Çoğu kurumsal site için OV, yüksek regülasyonlu ve yüksek hacimli e‑ticaret/SaaS projeleri için kritik alanlarda EV değerlendirmesi.
4. Kurulum ve test: Sertifikanın yüklenmesi, ara sertifikaların (intermediate) doğru zincirlenmesi, protokol/şifre ayarlarının optimize edilmesi.
5. HTTPS geçiş planı: 301 yönlendirmeler, HSTS, mixed content temizliği ve SEO etkisinin minimize edilmesi.
6. Otomatik yenileme ve izleme: Sertifika süre sonu uyarıları, mümkünse ACME tabanlı otomatik yenileme entegrasyonu.

Bu süreci birlikte tasarladığımızda, “Sertifika bitti, site düştü” ya da “Ödeme sayfasında tarayıcı uyarısı çıkıyor” gibi krizleri yaşamadan, SSL’i altyapınızın görünmez ama kritik bir parçası haline getirmek mümkün oluyor.

SSL türü seçimi konusunda daha fazla senaryo görmek isterseniz, özellikle e‑ticaret ve SaaS projeleri için hazırladığımız DV, OV, EV ve wildcard SSL arasında kaybolmadan doğru sertifikayı seçme rehberini de okumanızı öneririz.

Özet ve Sonraki Adımlar

DV, OV ve EV SSL sertifikaları arasındaki farkı tek cümleyle özetlemek gerekirse: Hepsi trafiği şifreler, ancak her biri “kime bağlandığınız” konusunda farklı seviyede güvence verir. Küçük projelerde DV maliyet açısından cazip olabilir; ancak kurumsal itibar, B2B ilişkiler, regülasyon ve yüksek hacimli e‑ticaret söz konusu olduğunda, OV ve EV seviyeleri hem kullanıcı güvenini hem de denetim süreçlerini ciddi şekilde rahatlatır.

DCHost olarak tavsiyemiz; sertifika kararını sadece fiyat ve şifreleme gücü üzerinden değil, marka stratejiniz, hukuki yükümlülükleriniz ve teknik mimariniz üzerinden birlikte değerlendirmek. Alan adlarınızı, hosting mimarinizi ve mevcut HTTPS durumunuzu birlikte gözden geçirerek; hangi alan adında DV, hangisinde OV veya EV’nin daha mantıklı olduğunu netleştirebiliriz.

Eğer halihazırda başka bir sağlayıcıda barınan bir siteniz varsa ve DCHost altyapısına geçmeyi düşünüyorsanız, DNS, HTTP→HTTPS yönlendirmeleri ve sertifika taşıma sürecini de kesinti yaşamadan planlayabiliriz. Tek yapmanız gereken, elinizdeki domain ve proje listesini çıkarıp “Bu sitelerin SSL durumunu birlikte gözden geçirelim” demek. Gerisi için teknik ekibimiz sizinle aynı masada, aynı tarafta.