Güvenlik

SSL Sertifika Türleri: DV, OV ve EV Arasında Doğru Seçim

Sitenizin gerçek senaryosuna göre SSL sertifika türlerini seçmeye yönelik pratik bir kılavuz; DV, OV ve EV arasındaki farklardan yaygın tarayıcı hatalarına ve sertifika zinciri kontrolüne kadar.

Güvenlik

Tarayıcı açıldı, kilit simgesinin üzeri çizilmiş ve "Not Secure" yazıyor. Ya da daha kötüsü: Kullanıcı "NET::ERR_CERT_DATE_INVALID" mesajını görüyor ve sayfayı kapatıyor. Şu anda ücretsiz bir DV sertifikası ile ücretli bir OV sertifikası arasında karar vermeniz gereken bir sayfadaysanız, bu metin tam size göre. Doğru karar, sertifikanın fiyatına değil, sitenizin kullanıcıya neyi kanıtladığına bağlıdır.

Üç sertifika seviyesi, üç kimlik kanıtlama seviyesi

"SSL sertifika türleri" dediğimizde, aslında şifreleme algoritmasından değil, doğrulama seviyesinden bahsediyoruz. Her üç seviye de aynı şifrelemeyi kullanır; fark, CA'nın imzalamadan önce izlediği süreçtedir.

  • DV (Domain Validation): Yalnızca alan adı sahipliği kontrol edilir. Genellikle bir DNS TXT kaydı veya web sunucusundaki bir dosya ile. Birkaç dakika içinde düzenlenir.
  • OV (Organization Validation): Kuruluşun tüzel kişiliği kontrol edilir; şirket kaydı, adres, telefon numarası. Birkaç iş günü sürer.
  • EV (Extended Validation): Daha derin tüzel ve operasyonel inceleme. Eskiden tarayıcı adres çubuğunda yeşil şeridi etkinleştirirdi.

O yeşil şerit artık yok

Eğer biri size "yeşil şerit almak için EV satın alın" dediyse, bilgisi 2018'den kalma. Chrome 77 ve Firefox 70'ten itibaren tarayıcılar yeşil şerit gösterimini kaldırdı. Artık yalnızca kilide tıklayarak kuruluş adını görebilirsiniz. Yani EV için "daha fazla görsel güven" argümanı artık geçerli değil. Geriye kalan, kurumsal uyumluluk gereksinimleridir.

Hangi site için hangi seviyeyi seçmeliyiz

Kısa cevap: Sitelerin %90'ı için DV yeterlidir. Siteniz bir blog, küçük bir mağaza veya bir SaaS ise ve kullanıcı sizinle banka hesabı açmıyorsa, DV alın ve fazla parayı yedeklemeye harcayın. OV'yi kurumsal müşteriniz varsa ve hukuk ekibi sertifikayı tedarikçi kontrol listesinde istiyorsa seçin. EV'yi yalnızca sözleşme veya düzenleyici açıkça zorunlu kıldığında tercih edin.

KriterDVOVEV
Düzenlenme süresiDakika1 ila 3 iş günü3 ila 7 iş günü
Kuruluş kimliği kontrolüHayırEvetEvet, daha derin
WildcardEvetEvetSınırlı
Tarayıcı yeşil şeridiHayırHayırKaldırıldı
Uygun olduğu durumÇoğu siteB2B ve kurumsalSözleşmesel zorunluluk

Kimsenin bahsetmediği maliyet

OV ve EV'nin gizli bir maliyeti vardır: Yenileme döngüsü. Her seferinde kuruluş belgelerinin yeniden onaylanması gerekir ve WHOIS'te kayıtlı telefon numarası değişmişse süreç durur. OV sertifikasıyla çalışan bir sitenin, yenileme günü onay e-postasına yanıt verilmediği için 48 saat süresiz sertifikayla ayakta kaldığını gördüm. DV'de bu olmaz çünkü doğrulama otomatiktir.

Sunucuda sertifika zinciri kontrolü

Sertifikayı kurmak işin yarısıdır. Diğer yarısı, ara zincirin (Intermediate Chain) doğru olmasıdır. Zincir eksikse, masaüstü tarayıcılar sorunsuz geçebilir ama mobil uygulama veya curl hata verebilir. Bunu basit bir komutla kontrol edin:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Çıktıda Verify return code: 0 (ok) satırını arayın. Sıfırdan farklı bir sayı görürseniz, zincirde sorun var. Son kullanma tarihini kontrol etmek için:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Çıktı notAfter=Mar 14 12:00:00 2026 GMT gibi bir şey verir. Bu tarihi kişisel takviminize değil, izleme sisteminize kaydedin.

Burada hata yapıyorlar

En sık gördüğüm hata: Sertifikayı ana alan adına kurup www'yi unutmak. Kullanıcı www.example.com'u açar, sertifika example.com için düzenlenmiştir ve tarayıcı NET::ERR_CERT_COMMON_NAME_INVALID hatası verir. Belirtisi de şudur: Site bazı kullanıcıların mobilinde açılır, bazılarında açılmaz; çünkü bazıları www ile yazar, bazıları yazmaz. Çözüm: Ya Wildcard sertifika alın, ya SAN'da her iki adı da ekleyin, ya da www'den ana alan adına 301 yönlendirmesi koyun.

Yaygın hatalar ve gerçek kökenleri

Sertifikada sorun olduğunda, tarayıcı mesajı genellikle yanıltıcıdır. Bu hızlı haritayı elinizde tutun:

  • ERR_CERT_DATE_INVALID: Sunucu saati veya sertifika tarihi. Önce timedatectl status kontrol edin.
  • ERR_CERT_AUTHORITY_INVALID: Ara zincir eksik veya self-signed sertifika kurulu.
  • ERR_SSL_PROTOCOL_ERROR: Genellikle web sunucusu ile 443 portundaki trafiği yakalayan bir ön proxy arasındaki çakışma.
  • Hatasız gri kilit: Mixed Content kaynakları; http:// ile yüklenen resim veya betik.

Son durum için tarayıcı konsolunu açın ve Mixed Content uyarılarını arayın. WordPress siteniz varsa, bu genellikle resim adreslerini hardcode eden eski bir eklentiden gelir. WordPress güvenliği; wp-config'ten kendileri açık olan eklentilere kadar kılavuzu tam da bu tür sorunları kapsıyor.

Yenileme otomasyonu: İlk günden yapmanız gereken

Günümüz sertifikaları en fazla 398 gün geçerlidir ve küresel eğilim 90 güne doğru gidiyor. Yani manuel yenileme artık bir seçenek değil. Let's Encrypt kullanıyorsanız, Certbot'u bir timer ile ayarlayın:

systemctl list-timers | grep certbot
certbot renew --dry-run

İkinci komut, gerçek bir değişiklik yapmadan tüm yenileme sürecini simüle eder. Hata verirse, orada durun; çünkü gerçek yenileme gününde de hata verecektir. Son kullanmaya 14 gün kala bir izleme uyarısı da koyun.

CDN veya proxy kullandığınızda

Trafiğiniz bir ara katmandan geçiyorsa, iki sertifikanız vardır: Biri kullanıcı ile kenar arasında, biri kenar ile kaynak sunucu arasında. Yaygın hata, kaynak sertifikasının süresinin dolması ama kullanıcının hiçbir şey görmemesidir; çünkü kenar hâlâ kendi geçerli sertifikasını gösterir. Ta ki kenarın kaynağa bağlanıp 526 hatası aldığı güne kadar. Hizmetlerin anlık durumunu görmek ve sorunun nereden geldiğini teşhis etmek için hizmetlerin anlık durumu iyi bir başlangıç noktasıdır.

CA seçimi: Gerçekten önemli olan

CA markası güvenlik açısından neredeyse hiçbir fark yaratmaz. Önemli olan: Otomasyon için ACME desteği, Wildcard desteği ve teknik destekte yanıt verme geçmişi. İyi otomasyona sahip ucuz bir CA, manuel süreçli pahalı bir CA'dan daha iyidir. Ekibinizin kaynakları sınırlıysa bunu ciddiye alın.

Az söylenen bir nokta: SSL sertifikası yalnızca taşıma katmanını korur. Sunucunuz hacimsel saldırılara karşı korunmuyorsa, HTTPS'e sahip olmak hiçbir işe yaramaz. DDoS korumasını sertifika konusundan ayrı planlayın. Ayrıca ekibinizin sunuculara SSH erişimi varsa, SSH güvenliği; port değiştirmekten fail2ban ve açık anahtara kadar kılavuzunu sertifika işiyle paralel yürütün; bu ikisi genellikle birlikte ihmal edilir.

Sık sorulan sorular

DV sertifikası bir e-ticaret sitesi için güvenli mi?

Evet, şifreleme açısından OV ve EV'den hiçbir farkı yoktur. Üçü de aynı güçte TLS kullanır ve kullanıcı verisi aynı şekilde şifrelenir. Fark yalnızca düzenleyicinin kimlik doğrulama düzeyindedir. Ödeme sağlayıcınızın özel bir sözleşmesel zorunluluğu yoksa, DV yeterlidir.

Sertifikayı kurduktan sonra tarayıcı neden hâlâ güvensiz gösteriyor?

Çoğu durumda Mixed Content nedeniyle; yani ana sayfa HTTPS ile yükleniyor ama kaynakların bir kısmı (resim, betik, yazı tipi) http:// ile çağrılıyor. Tarayıcı konsolunu açın ve Mixed Content uyarılarını görün. Eğer Mixed Content değil de sertifika hatasıysa, ara zinciri openssl s_client ile kontrol edin.

Wildcard ve Multi-Domain sertifika arasındaki fark nedir?

Wildcard bir alan adını ve bir seviye altındaki tüm alt alan adlarını kapsar, örneğin *.example.com. Multi-Domain (veya SAN) birbirinden tamamen farklı birkaç alan adını tek sertifikada toplar, örneğin example.com, example.ir ve shop.example.net. Çok sayıda alt alan adınız varsa Wildcard daha iyidir; birkaç ayrı markanız varsa SAN daha uygundur.

Sertifikayı ne sıklıkla yenilemeliyim?

Bugün izin verilen maksimum geçerlilik 398 gündür, ancak sektör eğilimi 90 güne doğru gidiyor. Pratikte yenilemeyi tamamen otomatikleştirmeli ve yalnızca son kullanma izlemesi yapmalısınız. Ekibinizin birden fazla hizmeti varsa, dokümantasyon ve bilgi tabanını yenileme prosedürlerini ve her sertifikanın sahipliğini kaydetmek için güncel tutun; öyle ki sorumlusu değiştiği gün kimse hangi sertifikanın hangi hizmete ait olduğunu bilmesin.

Şu anda sunucunuzda bir sertifikanız varsa, başka bir şey yapmadan önce şu komutu çalıştırın: echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates -subject. Son kullanma tarihi 30 günden azsa veya subject kullanıcının yazdığı alan adıyla eşleşmiyorsa, önce onu düzeltin. Diğer tartışmalar bu aşamadan sonra anlam kazanır. Altyapı üzerinde sertifika kurulumu ve yönetimi için, ServerNet sunucu güvenlik hizmetleri inceleyebileceğiniz bir seçenektir.

ServerNet Destek

ServerNet mühendislik ve yayın ekibi — altyapı, ağ ve web barındırma uzmanları.

Güvenlik Hizmetleri
Paylaş:

Yorumlar 0

Henüz yorum yok — ilk siz olun!

Yorum bırakın

İlgili hizmet

Güvenlik Hizmetleri

OSCP sertifikalı uzmanlarla sızma testi, altyapı sıkılaştırma ve 7/24 güvenlik izleme.