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.
| Kriter | DV | OV | EV |
|---|---|---|---|
| Düzenlenme süresi | Dakika | 1 ila 3 iş günü | 3 ila 7 iş günü |
| Kuruluş kimliği kontrolü | Hayır | Evet | Evet, daha derin |
| Wildcard | Evet | Evet | Sınırlı |
| Tarayıcı yeşil şeridi | Hayır | Hayır | Kaldırıldı |
| Uygun olduğu durum | Çoğu site | B2B ve kurumsal | Sö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. Öncetimedatectl statuskontrol 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.
Yorumlar 0
Henüz yorum yok — ilk siz olun!