SSL/TLS Sertifika Türleri: DV, OV ve EV Sertifika Karşılaştırması
DV, OV, EV doğrulama seviyeleri; Single Domain, Wildcard, Multi-Domain (SAN/UCC) kapsamı; X.509 anatomisi, TLS handshake, CT logları, 90 gün geçerlilik süresi, HSTS, OCSP stapling ve Buyukweb cPanel AutoSSL bağlamı.
SSL/TLS Sertifika Türleri: DV, OV ve EV Sertifika Karşılaştırması
Web tarayıcısının adres çubuğundaki o küçük asma kilit ikonu, bir gün "Bu site güvenli değil" uyarısına dönüşürse ziyaretçinizin yarısı geri tuşuna basar. SSL/TLS sertifikası, modern web'de "olsa iyi olur" değil; arama motoru sıralaması, ödeme entegrasyonları, HTTP/2 ve HTTP/3 desteği, KVKK uyumu ve marka güveni dahil her şey bu sertifikanın varlığına ve doğru türde seçilmesine bağlı. Peki DV, OV ve EV arasındaki fark gerçekte ne? Bir kurumsal site EV almalı mı yoksa yüz katı ucuza gelen DV yeterli mi? Wildcard ile SAN sertifika arasındaki seçim nasıl yapılır? Bu rehberde, hem hosting müşterilerimizin sıkça sorduğu hem de teknik karar matrisinde kritik olan tüm bu sorulara birer birer cevap veriyorum.
Buyukweb perspektifi: Tüm cPanel hosting paketlerimiz (yıllık ₺350-2.000 aralığı) ücretsiz Let's Encrypt AutoSSL ile geliyor — sertifika domain hesabınıza bağlandığı andan itibaren otomatik kurulur, 60 günde bir otomatik yenilenir, tüm subdomain'leriniz kapsanır. Bursa Tier 3 veri merkezimizde TLS 1.2 + TLS 1.3 standart, eski sürümler kapalı. VDS müşterilerimiz kendi sertifika otomasyonlarını (certbot, acme.sh) kurabilir; ihtiyaç halinde kurumsal müşteriler için ticari CA üzerinden DV/OV/EV sertifika tedariği destek hattımız üzerinden yönlendirilebilir. 0850 302 60 70 numarasından danışabilirsiniz.
SSL/TLS Nedir, Neden Bu Kadar Önemli?
Önce isimlendirmedeki kafa karışıklığını çözelim: SSL (Secure Sockets Layer) protokolünün son sürümü 3.0, 2015'te RFC 7568 ile resmen kullanım dışı bırakıldı. Yerini alan TLS (Transport Layer Security) protokolüdür; ama "SSL sertifikası" deyimi sektörde yerleşmiş bir alışkanlık olarak kaldı. Bugün "SSL sertifikası" dendiğinde aslında bir TLS sertifikası anlatılır. Bu rehberde de okuyucu alışkanlığına göre çoğu yerde "SSL/TLS" diyeceğim.
Sertifikanın yaptığı iki temel iş var:
- Şifreleme: Tarayıcı ile sunucu arasındaki tüm veri (form bilgileri, çerezler, oturum tokenları) şifreli kanaldan akar. Aradaki bir saldırgan ham metni göremez.
- Kimlik doğrulama: Sunucunun gerçekten o alan adının sahibi olduğunu kanıtlar. Yani
buyukweb.comadresine bağlandığınızda gerçekten Buyukweb'in sunucusuna bağlandığınıza, ortada bir adam-arada (MITM) saldırganı olmadığına emin olabilirsiniz.
Modern web'de SSL/TLS olmadan:
- Google Chrome, Firefox, Safari "Bu site güvenli değil" uyarısı gösterir; ziyaretçinin önemli bir kısmı geri döner.
- HTTP/2 ve HTTP/3 (QUIC) sadece HTTPS üzerinde çalışır — performans avantajı yok olur.
- Service Worker, PWA, push notification, Geolocation API, modern Web API'leri çoğu HTTPS gerektirir.
- Arama motorları HTTPS'yi sıralama sinyali olarak kullanır (2014'ten beri Google).
- Ödeme sistemleri (Stripe, iyzico, PayTR vb.) sadece HTTPS sayfalarla entegre olur.
- KVKK / GDPR kişisel verinin şifreli iletimi için TLS zorunlu kabul edilir.
Yani 2026'da bir web sitesi HTTPS değilse, pratikte üretim ortamına çıkmamış demektir.
TLS Handshake: Tarayıcı Sunucuya Nasıl Güvenir?
Adres çubuğuna https://buyukweb.com yazıp Enter'a bastığınızda arka planda TLS handshake denilen bir el sıkışma akışı çalışır. Bu akış sertifikanın değeri ve şifrelemenin nasıl kurulduğunu anlamak için kritik:
TLS 1.3 Handshake (basitleştirilmiş):
İstemci (tarayıcı) Sunucu (web server)
| |
| 1. ClientHello |
| - desteklenen TLS sürümleri |
| - desteklenen cipher suite listesi |
| - rastgele istemci nonce |
| - key share (ephemeral ECDHE pub) |
|---------- TCP/QUIC üzerinden ----------> |
| |
| 2. ServerHello |
| - seçilen TLS sürümü (1.3) |
| - seçilen cipher suite |
| - rastgele sunucu nonce |
| - key share (ephemeral ECDHE pub) |
| <--------------------------------------- |
| |
| 3. Sertifika |
| - X.509 sertifika zinciri |
| - leaf + intermediate(s) |
| <--------------------------------------- |
| |
| 4. CertificateVerify |
| - sunucu private key ile imza |
| <--------------------------------------- |
| |
| 5. Finished |
| <--------------------------------------- |
| |
| 6. Finished |
|---------------------------------------> |
| |
| Şifreli uygulama verisi başlar |
| <----- AES-GCM / ChaCha20-Poly1305 ----> |
Birkaç önemli detay:
- TLS 1.3 handshake'i 1 RTT (round-trip time) ile tamamlanır; TLS 1.2'de 2 RTT idi. Modern CDN edge + TLS 1.3 ile handshake gecikmesi 30-50 ms seviyesine düşer.
- Asimetrik kripto (sertifikanın public key'i) sadece handshake'in başında, simetrik session key'i güvenli üretmek için kullanılır. Asıl veri akışı AES-GCM veya ChaCha20-Poly1305 gibi simetrik AEAD şifreler ile akar — bu çok daha hızlıdır.
- Forward Secrecy: Modern cipher suite'lerde ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) zorunludur. Yani sunucu private key'i bir gün sızdırılsa bile, geçmiş trafik çözülemez; çünkü her oturumun key share'i ephemeral (kullan-at) anahtardır.
- 0-RTT (TLS 1.3): Tarayıcı sunucuyu daha önce ziyaret ettiyse, ek bir round trip beklemeden uygulama verisini gönderebilir. Replay saldırılarına karşı dikkatli kullanılmalı (genelde idempotent isteklere izin verilir).
Sertifika işte tam bu noktada — handshake'in 3. adımında — tarayıcıya gönderilir. Tarayıcı sertifikayı kök CA listesine karşı doğrular, geçerli ise handshake tamamlanır; geçersizse "güvenli değil" uyarısı çıkar ve bağlantı genellikle kesilir.
Sertifika Anatomisi: X.509 Standardı
Bir SSL/TLS sertifikası aslında X.509 standardına uygun bir dijital belgedir. Açıp baktığınızda şu alanları görürsünüz:
| Alan | Açıklama | Örnek |
|---|---|---|
| Subject | Sertifikanın ait olduğu kimlik | CN=buyukweb.com, O=Buyukweb, C=TR |
| Common Name (CN) | Ana alan adı | buyukweb.com |
| Subject Alternative Name (SAN) | Ek alan adları | www.buyukweb.com, mail.buyukweb.com |
| Issuer | Sertifikayı veren CA | CN=R3, O=Let's Encrypt |
| Validity Period | Geçerlilik aralığı | Not Before: 2026-01-15 — Not After: 2026-04-15 |
| Serial Number | Sertifikanın benzersiz ID'si | 03:b1:cf:... |
| Signature Algorithm | İmza algoritması | sha256WithRSAEncryption / ecdsa-with-SHA256 |
| Public Key Info | Sertifika sahibinin public key'i | RSA 2048-bit / ECDSA P-256 |
| Fingerprint (Thumbprint) | Sertifikanın hash özeti | SHA-256: 5f:a8:... |
| Extensions | Anahtar kullanım, EKU, CRL/OCSP URL'leri | digitalSignature, keyEncipherment |
Common Name (CN) ve Subject Alternative Name (SAN)
Tarihsel olarak alan adı sertifikanın Common Name alanında yazılırdı; ama 2017'den itibaren Chrome 58 ve diğer modern tarayıcılar artık CN'ye bakmıyor — sadece SAN alanı geçerli sayılıyor. Bu yüzden modern bir sertifikada alan adı her zaman SAN listesinde olmalıdır (CN dolu olsa bile).
Pratik etkisi: Eğer eski bir sertifika sadece CN ile geliyorsa modern tarayıcı reddeder. Let's Encrypt, DigiCert, Sectigo gibi tüm güncel CA'lar SAN'ı standart koyar.
# OpenSSL ile bir sertifikanın SAN listesini görme
openssl s_client -connect buyukweb.com:443 -servername buyukweb.com < /dev/null 2>/dev/null \
| openssl x509 -noout -text \
| grep -A1 "Subject Alternative Name"
Bir DV sertifikası tipik olarak example.com + www.example.com SAN ile gelir. Multi-Domain (SAN/UCC) sertifika ise onlarca farklı domaini tek dosyada barındırır. Wildcard sertifika *.example.com SAN ile gelir.
Sertifika Zinciri (Chain of Trust)
Sunucunuzdan gelen sertifika tek başına yetmez; kök CA'ya ulaşan bir zincir gerekir:
[Kök CA — tarayıcı güven deposunda]
↓ imzalar
[Intermediate CA — operasyonel günlük imza]
↓ imzalar
[Leaf (sizin sertifikanız) — sunucuya yüklü]
Kök CA özel anahtarı çok değerli olduğundan, çevrimdışı (offline HSM) tutulur; günlük imzalama işleri için intermediate CA'lar kullanılır. Sunucunuz tarayıcıya leaf + intermediate(s) gönderir; tarayıcı kök CA'yı kendi güven deposundan tanır ve zinciri doğrular.
Yaygın hata: Sertifikayı kuran ama intermediate'i koymayan sunucular tarayıcıda "incomplete chain" / "missing chain" hatası verir. SSL Labs testinde "Chain issues: Incomplete" görürseniz fullchain.pem'i yükleyin (cert.pem + intermediate.pem birleşik).
Doğrulama Seviyesi: DV vs OV vs EV
İşte bu rehberin omurgası. Sertifika otoriteleri, sertifika vermeden önce kimliğinizi nasıl doğrulayacağına karar verir. Üç temel seviye var:
| Özellik | DV (Domain Validation) | OV (Organization Validation) | EV (Extended Validation) |
|---|---|---|---|
| Doğrulama kapsamı | Sadece alan adı sahipliği | Alan adı + tüzel kişilik | Alan adı + tüzel kişilik + fiziksel adres + telefon callback + ek kontroller |
| Doğrulama yöntemleri | DNS TXT, HTTP-01, EMAIL | Ticari sicil sorgusu, telefon, D-U-N-S | Hepsi + CAB Forum EV Guidelines (sıkı manuel inceleme) |
| Süre | Dakikalar / saatler | 1-3 iş günü | 5-10 iş günü |
| Maliyet (yıllık) | Ücretsiz (Let's Encrypt) - düşük | Orta | Yüksek |
| Tarayıcı görünümü | Asma kilit + "Güvenli" | Asma kilit + "Güvenli" | Asma kilit + "Güvenli" (eski yeşil bar 2018-2020'de kaldırıldı) |
| Tipik kullanım | Blog, kurumsal site, e-ticaret çoğu, SaaS | B2B kurumsal, kurumsal güvenlik politikası gerektirenler | Finans, bankacılık, devlet, kurumsal kontrat zorunluluğu |
| Sigorta/garanti | Yok veya çok düşük | Orta düzey | Yüksek (genelde milyonlarca $/€) |
DV (Domain Validation) — Sadece Domain Sahipliği
DV sertifikası "bu alan adı sizin mi?" sorusunun tek doğrulama hedefidir. CA, üç yöntemden biriyle bunu test eder:
1. HTTP-01 Challenge: CA, http://example.com/.well-known/acme-challenge/RASTGELE-TOKEN URL'ine bir GET isteği gönderir; o URL'de doğru içerik varsa, alan adı sahipliği kanıtlanmış sayılır. Web sunucusu çalışıyorsa en kolay yöntem.
2. DNS-01 Challenge: CA, _acme-challenge.example.com TXT kaydında bir değer ister; siz DNS'e koyarsınız, CA sorgulayıp doğrular. Wildcard sertifika için zorunlu olan tek yöntem budur. HTTP-01 wildcard'a izin vermez.
3. EMAIL Validation: CA, WHOIS'taki teknik iletişim adresine veya [email protected], [email protected], [email protected] gibi standart adreslere onay maili gönderir. Modern CA'lar bu yöntemi çok azaltıyor (WHOIS gizliliği nedeniyle).
Pratikte Let's Encrypt'in ACME istemcileri (certbot, acme.sh, lego, win-acme) bu doğrulamayı otomatik yapar. Bir DV sertifika 2-30 saniyede alınır.
DV'nin sınırı: alan adı sahipliği dışında hiçbir şey doğrulanmaz. Yani sahtebank.com adlı bir domaini bir saldırgan alabilir ve o domain için DV sertifikası alabilir. Tarayıcı asma kilit gösterir ama bu sitenin gerçek bir banka olduğunu kanıtlamaz — sadece alan adının sahibinin sertifikayı verdiğini kanıtlar. DV'nin görevi şifreleme + alan adı kimliği; "bu site şirket olarak gerçek mi?" sorusunu yanıtlamak DV'nin işi değil.
DV ne zaman yeterli? Bloglar, kurumsal tanıtım siteleri, çoğu e-ticaret, SaaS uygulamaları, API endpoint'leri, dahili paneller, geliştirme/test ortamları. Yani müşterilerimizin %95'i için. Buyukweb cPanel paketlerimizde Let's Encrypt AutoSSL otomatik bunu yapar.
OV (Organization Validation) — Şirket Tüzel Kişiliği
OV sertifikasında CA, alan adı sahipliğinin yanında şirketin gerçekten var olduğunu doğrular. Tipik adımlar:
- Ticari sicil kaydı kontrolü (TÜRKPATENT, Ticaret Bakanlığı, Mersis)
- D-U-N-S numarası (Dun & Bradstreet) ile global doğrulama
- Şirketin kayıtlı telefon numarasına telefon callback
- Şirket adresinin fatura/resmi belge ile doğrulanması
- Yetkili kişi imzasının elle alınması (bazı CA'lar)
Süreç 1-3 iş günü. Çıkan sertifikanın Subject alanında alan adının yanı sıra O=Şirket A.Ş., L=İstanbul, C=TR gibi tüzel kimlik bilgileri yer alır. Tarayıcıdan sertifikaya tıklayan kullanıcı bu bilgileri okuyabilir.
OV'nin pratik değeri sınırlı: Tarayıcılar OV ile DV arasında görsel hiçbir fark göstermiyor; ikisi de aynı asma kilit + "Güvenli" ile gözüküyor. Tüzel kimliği görmek için kullanıcının sertifikaya tıklaması gerekir ki bu pratik bir akış değil. OV'nin gerçek değeri B2B sözleşmelerde ortaya çıkar:
- Kurumsal müşterilerinizin bilgi güvenliği denetiminde "tüm sertifikalarımız OV+ doğrulamalıdır" kuralı varsa.
- ISO 27001, PCI DSS uyumluluk dökümanlarında OV/EV koşulu varsa.
- Devlet projeleri / kamu ihaleleri kontratta OV/EV zorunlu kılıyorsa.
Bu senaryolar dışında, tipik bir KOBİ / e-ticaret / SaaS için OV'nin DV üzerine kattığı değer müşteri algısı düzeyinde sıfır'dır. DV ile aynı şifreleme, aynı tarayıcı görünümü, aynı SEO etkisi.
EV (Extended Validation) — En Sıkı Doğrulama
EV sertifikası, CAB Forum'un Extended Validation Guidelines'ına göre verilen en sıkı doğrulama seviyesidir. OV'deki tüm adımlar + ek kontroller:
- Yetkili kişinin fiziksel adresinin bağımsız doğrulanması
- İmza yetkilisinin ticari sicilde gerçekten yetkili olduğunun kontrolü
- Bazı CA'lar yüz yüze görüşme veya noter onayı ister
- Şirketin operasyonel geçmişi (en az 3 yıl)
- Vergi mükellefiyet durumu
- Çakışan/benzer marka kontrolleri
Süreç 5-10 iş günü, bazen 2-3 hafta. Maliyet OV'ye göre 2-5 katı.
EV'in "Yeşil Bar" Tarihi
EV sertifikası 2007-2018 arasında tarayıcılarda özel bir görsel ile geliyordu: adres çubuğunda yeşil arka plan + şirket adı + ülke kodu. Bu "yeşil bar" pazarlamacılar tarafından "EV almalısınız" argümanının çekirdeğiydi.
Ama 2018-2020 arasında büyük tarayıcılar yeşil barı kaldırdı:
- Chrome 77 (Eylül 2019) — EV görsel ayrımı default olarak kaldırıldı.
- Safari 12.1.1 (Mayıs 2019) — EV adres çubuğu işareti minimuma indi.
- Firefox 70 (Ekim 2019) — EV özel ikon ve adres bar değişimi kaldırıldı.
Sebep: araştırmalar EV'in kullanıcı davranışını anlamlı şekilde değiştirmediğini gösterdi. Stanford ve Google'ın 2019 araştırması, EV gösterimi ile DV arasında kullanıcı güveni / dönüşüm oranı açısından istatistiksel anlamlı fark bulamadı. Yeşil bar kaldırıldıktan sonra EV pazar payı ciddi şekilde düştü; bugün hâlâ kullananlar genelde sözleşme zorunluluğu yaşayan finans/devlet sektörü.
EV Ne Zaman Hâlâ Anlamlı?
EV'nin görsel avantajı tarihte kaldıysa da, bazı senaryolarda hâlâ tercih ediliyor:
- Bankacılık / finans sektörü: PCI DSS denetiminde, BDDK düzenlemelerinde EV zorunlu olabilir.
- Devlet siteleri: Bazı kamu kurumları kendi iç politikalarında EV koşulu koyuyor.
- Yüksek değerli e-ticaret: Lüks segment, üyelik kartı vb. müşteri algısının önemli olduğu yerler.
- Kurumsal B2B kontratları: Bazı tedarikçi sertifikasyon süreçleri EV gerektirir.
- Sigorta/garanti ihtiyacı: EV sertifikaları genelde yüksek meblağlı tazminat sigortası ile gelir (sertifika hata verir veya çalınırsa CA tarafından karşılanır).
Buyukweb'de bir kurumsal müşterimiz OV/EV alacaksa, ticari CA üzerinden tedarik sürecine destek hattımızdan yönlendiriyoruz. Sertifika alındıktan sonra cPanel SSL/TLS panelinden CSR oluşturup CRT ve intermediate'i yükleme işlemi 5 dakikalık bir iş.
Sertifika Kapsamı: Single, SAN, Wildcard, Wildcard+SAN
Doğrulama seviyesi (DV/OV/EV) yanında, sertifikanın kaç alan adını kapsadığı ikinci kritik karardır. Dört temel tip var:
| Tip | Kapsam | Tipik kullanım |
|---|---|---|
| Single Domain | Sadece tek alan adı (genelde www. SAN'a eklenir) | Tek site, blog, tanıtım |
| Multi-Domain (SAN/UCC) | Birden çok farklı domain tek sertifikada | Mail sunucu, çoklu marka, kurumsal panel |
| Wildcard | Bir domain + tüm aynı seviye subdomain'leri | SaaS, müşteri subdomain'leri, dev/staging |
| Wildcard + Multi-Domain | Birden çok wildcard tek sertifikada | Kurumsal grup şirketleri |
Single Domain — Tek Site
En basit ve en yaygın. Sertifika genellikle iki SAN ile gelir: example.com + www.example.com. Modern CA'ların hemen tamamı www subdomain'ini otomatik dahil eder.
Subject Alternative Names:
DNS: example.com
DNS: www.example.com
Buyukweb cPanel AutoSSL bunu otomatik yapar; ekstra hiçbir konfigürasyon gerekmez.
Multi-Domain / SAN / UCC — Çoklu Domain Tek Sertifika
SAN (Subject Alternative Name) sertifikası, birden fazla farklı alan adını tek sertifikada birleştirir. UCC (Unified Communications Certificate) terimi Microsoft Exchange / Lync ekosisteminde aynı şeyi anlatır.
Subject Alternative Names:
DNS: marka1.com
DNS: www.marka1.com
DNS: marka2.com.tr
DNS: www.marka2.com.tr
DNS: shop.marka1.com
DNS: mail.marka1.com
Tipik kullanım:
- Mail sunucu (
mail.example.com+autodiscover.example.com+autoconfig.example.com+mta-sts.example.com) - Microsoft Exchange / UC (
mail.example.com+autodiscover.example.com+legacy.example.com+owa.example.com) - Çoklu marka sahibi şirketler (
marka1.com,marka2.com.tr,marka3.nettek sertifikada) - Bölgesel domain çeşitleri (
example.com+example.com.tr+example.de+example.it)
SAN sertifikası tipik olarak 3-100 domain arasında destekler. Domain ekleme/çıkarma için sertifikanın reissue edilmesi gerekir.
Avantajı: Bir tek sertifika ile çok domain. Dezavantajı: Bir domain için reissue gerekirse hepsinin geçerlilik süresi sıfırlanmaz ama yönetim biraz daha dikkat ister.
Wildcard — Tüm Subdomain'ler
Wildcard sertifika, bir domain ve aynı seviye tüm subdomain'lerini tek imzayla kapsar:
Subject Alternative Names:
DNS: example.com
DNS: *.example.com
Yani shop.example.com, blog.example.com, api.example.com, musteri1.example.com, musteri999.example.com — hepsi bu tek sertifika ile çalışır. Yeni subdomain açtığınızda yeni sertifika almanız gerekmez.
Sınır: Wildcard sadece bir seviye derinlik kapsar. Yani *.example.com → shop.example.com çalışır, ama v1.api.example.com çalışmaz. Onun için *.api.example.com ayrı sertifika veya daha geniş kapsamlı yapı gerekir.
Tipik kullanım:
- SaaS uygulamaları (her müşterinin
musteri.app.comsubdomain'i) - Bayi/franchise sistemleri (her bayi:
istanbul.brand.com,ankara.brand.com) - Dev/staging/test ortamları (
dev.example.com,staging.example.com) - Bölgesel alt yapılar (
tr.example.com,de.example.com) - CDN/edge noktaları (
cdn1.example.com,cdn2.example.com)
Wildcard riskleri:
- Tek private key, binlerce subdomain. Anahtar sızdırılırsa hepsi etkilenir. Yüksek güvenlikli kurumsal politikalarda wildcard yerine her subdomain için ayrı SAN tercih edilebilir.
- Wildcard sertifikası alabilmek için DNS-01 challenge zorunlu (HTTP-01 yetmez); DNS yönetiminizin otomasyon API'sı veya manuel TXT kaydı koyma yeteneği olmalı.
- cPanel AutoSSL wildcard üretmez (her subdomain için ayrı leaf sertifika alır); wildcard isterseniz DNS-01 ile certbot veya benzeri ACME istemcisi kullanmanız gerekir. Buyukweb VDS'te bu kurulum standart.
Wildcard sertifika hakkında daha derin bir anlatım için Wildcard SSL Sertifikası ve DNS-01 Challenge rehberimize bakabilirsiniz.
Wildcard + Multi-Domain — En Geniş Kapsam
Bazı kurumsal grup şirketleri birden çok marka için tek sertifika ister: *.marka1.com + *.marka2.com.tr + *.marka3.net aynı sertifikada. Bu en pahalı seçenek ve genelde sadece ticari CA (DigiCert, Sectigo, GlobalSign) tarafından sunulur. Let's Encrypt birden çok wildcard'ı tek sertifikada destekler ama yine ticari muadillerine göre süre/hesap-rate-limit kısıtları olabilir.
Karar Matrisi: Validation × Kapsam
İki ekseni birleştirelim; gerçek dünya senaryolarınızla eşleştirelim:
| Senaryo | Doğrulama | Kapsam | Tipik tedarik |
|---|---|---|---|
| Kişisel blog | DV | Single | Let's Encrypt (ücretsiz, cPanel AutoSSL) |
| Kurumsal tanıtım sitesi | DV | Single | Let's Encrypt (cPanel AutoSSL) |
| Küçük/orta e-ticaret | DV | Single | Let's Encrypt (cPanel AutoSSL) |
| Çoklu subdomain (shop., blog., api.) | DV | Wildcard veya SAN | Let's Encrypt DNS-01 (VDS) veya AutoSSL leaf-per-sub (cPanel) |
| SaaS, müşteri başına subdomain | DV | Wildcard | Let's Encrypt DNS-01, certbot otomasyon (VDS) |
| Mail sunucusu (4-5 hostname) | DV | SAN | Let's Encrypt (certbot multi-domain) |
| Kurumsal çoklu marka | DV veya OV | SAN | Let's Encrypt / Ticari CA |
| B2B kurumsal müşteri OV koşulu | OV | Single/SAN | Ticari CA (DigiCert, Sectigo, GlobalSign vb.) |
| ISO 27001 / PCI DSS denetimli | OV | Single/SAN/Wildcard | Ticari CA |
| Bankacılık / finans | EV | Single/SAN | Ticari CA (EV Guidelines) |
| Devlet / kamu | EV | Single/SAN | Ticari CA (genelde yerel akredite) |
| Kurumsal grup, çoklu marka wildcard | OV/EV | Wildcard + SAN | Ticari CA (premium) |
Pratikte Buyukweb müşterilerinin %90+'ı için DV + Single veya DV + Wildcard yeterlidir. Kalan %10 kurumsal müşteri OV/EV ticari CA tedariği için destek hattımız üzerinden yönlendirilir.
Sertifika Otoriteleri (CA) Ekosistemi
Bir sertifika, sadece kendi başına geçerli değildir; güvendiğiniz bir CA tarafından imzalanması gerekir. Modern tarayıcılar (Chrome, Firefox, Safari, Edge) işletim sistemi veya tarayıcı kök CA deposunda 150-200 civarında CA tanır. Bunlar üç kategoriye ayrılır:
Açık (Free/ACME) CA Ekosistemi
ACME protokolü üzerinden otomatik, ücretsiz veya çok düşük maliyetli DV sertifika veren CA'lar:
- Let's Encrypt — Pazar lideri (500M+ aktif sertifika), ISRG yönetimi, Mozilla/EFF/Cisco destekli.
- ZeroSSL — SectiGo bağlantılı, ACME ve manuel arayüz seçenekleri, 90 günlük DV.
- Buypass Go SSL — Norveç merkezli, 180 günlük DV (Let's Encrypt'in iki katı süre).
- Google Trust Services — Google'ın halka açık ACME CA'sı, 90 günlük DV.
Ticari CA — DV/OV/EV Tüm Skala
Kurumsal kullanım için DV/OV/EV ve premium SAN/Wildcard veren ticari CA'lar (sektörel referans):
- DigiCert — Premium kurumsal, dünya pazar liderlerinden, EV uzmanı.
- Sectigo (eski adıyla Comodo CA) — Geniş ürün yelpazesi, OV/EV uygun fiyat.
- GlobalSign — Avrupa merkezli, kurumsal odaklı, S/MIME ve kod imzalama da.
- Entrust — Bankacılık ve devlet pazarlarında güçlü.
- GeoTrust, Thawte, RapidSSL — DigiCert grubu altında orta segment markalar.
- IdenTrust — Devlet ve sağlık sektörü odaklı.
Buyukweb olarak müşterilerimizden gelen kurumsal OV/EV taleplerini bu ticari CA'lardan biri üzerinden tedarik sürecine yönlendiriyoruz. DV için ekstra ücretli CA tercih etmiyoruz çünkü Let's Encrypt ile teknik fark sıfır, sadece operasyonel ek yük olur.
Kök ve Intermediate CA
Her CA'nın çevrimdışı tutulan bir kök ve operasyonel intermediate(ler)i var. Örneğin Let's Encrypt:
ISRG Root X1 (kök, çevrimdışı)
↓ imzalar
R3 (intermediate, online operasyon)
↓ imzalar
sizin sertifikanız (leaf)
2024-2025'te Let's Encrypt yeni intermediate R10, R11'e geçiş yaptı. Eski R3 kademeli olarak emekli ediliyor. Bunlar arka planda otomatik yönetilen detaylardır; ACME istemcisi güncel kalırsa zincir otomatik düzgün gelir.
CAB Forum: Sektör Standartlarının Belirleyicisi
CA/Browser Forum (CAB Forum), sertifika otoriteleri ve tarayıcı üreticilerinin birlikte standart belirlediği bir konsorsiyumdur. CAB Forum'un Baseline Requirements (BR) dokümanı, dünyada her halka açık SSL/TLS sertifikasının uyması gereken minimum kuralları tanımlar. EV sertifikaları için ayrı EV Guidelines belgesi mevcut.
Önemli kararlardan bazıları:
- Sertifika geçerlilik süresinin azaltılması (8 yıl → 39 ay → 825 gün → 397 gün → 90 gün gündemde)
- CT (Certificate Transparency) loglarına kayıt zorunluluğu
- CN'nin sertifikada zorunlu olmaması (sadece SAN yeterli)
- DNS CAA kaydı zorunlu kontrol (CA, sertifika vermeden önce CAA'ya bakmalı)
CAB Forum kararları her CA'yı bağlar; ihlal halinde tarayıcı kök listesinden çıkarma yaptırımı olabilir (örneğin 2018-2020 arasında Symantec CA başta olmak üzere birkaç CA güven kaybı nedeniyle pazardan çekildi).
Certificate Transparency (CT) Logları
Certificate Transparency, halka açık SSL/TLS sertifikalarının kamuya açık, append-only log sistemine kaydedilmesini sağlayan bir RFC standardıdır (RFC 6962, sonra RFC 9162). Amaç: CA'ların yetkisiz veya hatalı sertifika vermesini erkenden tespit etmek.
Çalışma şekli:
- CA bir sertifika imzalar.
- CA, bu sertifikayı en az iki CT log sunucusuna gönderir (Google CT, Cloudflare CT, DigiCert CT vb.).
- CT log, sertifikayı kendi append-only Merkle tree'sine ekler ve bir SCT (Signed Certificate Timestamp) döndürür.
- CA, SCT'leri sertifikaya gömer veya TLS handshake'de gönderir.
- Tarayıcı (Chrome), SCT'leri kontrol eder; CT loglarına gönderilmemiş sertifika kabul edilmez (Chrome 2018'den beri Apple Safari 2018'den beri zorunlu).
CT loglarının pratik etkisi:
- Sertifika monitoring — Şirketinizin alan adı için habersiz sertifika çıkarılırsa erkenden bilirsiniz. crt.sh, Google Transparency Report, Facebook CT Monitor, SSLMate Cert Spotter gibi araçlar sürekli izleme yapar.
- CAA + CT kombinasyonu — DNS'te
CAAkaydı ile "bu domain için sadece şu CA'lar sertifika imzalayabilir" diyebilirsiniz; CT logları ile bu kuralın uygulandığını doğrularsınız. - Saldırı tespiti — Phishing veya MITM saldırıları için saldırganların kullandığı sertifikalar CT'de görünür; güvenlik ekipleri bunu izleyerek erken uyarı alır.
Buyukweb müşterileri için pratik öneri: Şirketinizin ana alan adlarını
crt.shüzerinden aylık manuel veya otomatik (cron + curl) kontrol edin. Tanımadığınız bir CA tarafından sertifika verildiğini görürseniz hemen CA'ya revocation talebi açın.
Sertifika Geçerlilik Süresi: Kısalma Tarihi
Sertifika geçerlilik süreleri yıllardır kademeli olarak kısalıyor. Sebep güvenlik: süresi uzun bir sertifika çalınırsa daha uzun süre kötüye kullanılabilir; revocation (iptal) mekanizmaları (CRL, OCSP) pratikte yeterince hızlı yayılmadığı için kısa süreler doğal bir savunma katmanı sağlıyor.
Tarihsel ilerleme:
| Yıl | Maksimum geçerlilik | Karar mercii |
|---|---|---|
| 1999 öncesi | 8-10 yıl | CA inisiyatifi |
| 2015 | 39 ay (1185 gün) | CAB Forum BR |
| Mart 2018 | 825 gün (~27 ay) | CAB Forum BR |
| Eylül 2020 | 397 gün (~13 ay) | Apple unilateral karar, CAB Forum izledi |
| 2024 sonu / 2025 | 90 gün (pratik norm Let's Encrypt'te zaten) | Apple, Google, Mozilla baskısı |
| Yakın gelecek | 47 gün hedef (Apple/Google önerisi) | CAB Forum ballot devam ediyor |
90 gün norm olunca otomatik yenileme şart hale geliyor. Manuel yıllık yenileme alışkanlığı olan eski IT ekipleri için bu adaptasyon zorlayıcı; çözüm:
- cPanel AutoSSL (Buyukweb cPanel paketleri) — tamamen otomatik, müdahale gerekmez.
- VDS'te certbot / acme.sh + cron veya systemd timer — 60 günde bir yenileme deneyimi.
- Plesk SSL It! — Let's Encrypt entegre, panel üzerinden açma/kapama.
Buyukweb cPanel ortamında her gece AutoSSL süresi 30 günden az kalan domainleri tarar ve otomatik yenileme dener. Müşterinin tarafında konfigürasyon sıfır. VDS müşterileri kendi otomasyonlarını kuruyor; certbot
certbot renew --dry-runile yenileme testini periodik çalıştırıp Healthchecks.io gibi cron monitoring servisiyle uyarı alabilirler.
TLS Sürümleri: Hangi Sürüm Açık Olmalı?
Sertifikanız doğru tipte olsa bile, sunucunun TLS yapılandırması zayıfsa skor düşer. 2026 itibariyle:
| TLS sürümü | Durum | Buyukweb politikası |
|---|---|---|
| SSL 2.0 | Kullanım dışı (1996) | Kapalı |
| SSL 3.0 | Kullanım dışı (POODLE 2014) | Kapalı |
| TLS 1.0 | Deprecated 2021 (RFC 8996) | Kapalı |
| TLS 1.1 | Deprecated 2021 (RFC 8996) | Kapalı |
| TLS 1.2 | Aktif standart | Aktif (geniş uyumluluk için) |
| TLS 1.3 | Modern tercih (RFC 8446, 2018) | Aktif (varsayılan) |
PCI DSS v4 zaten TLS 1.0/1.1 kapatılmasını zorunlu kılar. Modern tarayıcıların hiçbiri (Chrome, Firefox, Safari, Edge 2026 sürümleri) TLS 1.1 ve altı ile bağlanmaz.
Cipher Suite Seçimi
Cipher suite, handshake sırasında kullanılacak anahtar değişimi + simetrik şifreleme + hash algoritmalarının kombinasyonudur. 2026'da önerilen seçimler:
TLS 1.3 cipher suites (önerilen, sıralı tercih):
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS 1.2 cipher suites (geriye uyumluluk için):
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
Kritik özellikler:
- ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) — Forward secrecy sağlar.
- AEAD modu (AES-GCM, ChaCha20-Poly1305) — Tek geçişte hem şifreleme hem kimlik doğrulama.
- SHA256/384 hash — MD5/SHA1 modern bir cipher suite'te kalmamalı.
Mozilla SSL Configuration Generator (ssl-config.mozilla.org) Nginx, Apache, HAProxy, Traefik için "Modern", "Intermediate", "Old" profilleri sunar. Buyukweb cPanel sunucularında Intermediate profil varsayılan (geniş uyumluluk); VDS müşterileri kendi tercihlerini seçer.
SSL Labs (ssllabs.com/ssltest) A+ skoru için kontrol listesi:
- TLS 1.2 + 1.3 aktif, eski sürümler kapalı.
- Modern cipher suite'ler (ECDHE + AEAD).
- HSTS aktif (en az 6 ay max-age).
- OCSP stapling aktif.
- Sertifika zinciri tam (intermediate dahil).
- CAA DNS kaydı tanımlı.
- Subdomain'ler de aynı şekilde yapılandırılmış.
HSTS: HTTP Strict Transport Security
HSTS (RFC 6797), tarayıcılara "bu domain için sadece HTTPS kullan, HTTP'ye düşme" diyen bir response header'dır:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
max-age=63072000— 2 yıl (saniye). Tarayıcı bu süre boyunca HTTPS zorla.includeSubDomains— Tüm subdomain'lere de uygula.preload— Tarayıcının HSTS Preload List'ine eklenmek istiyorum (hsts-preload.appspot.com).
HSTS Preload List, Chrome / Firefox / Safari / Edge kaynak kodunda sabit kodlu bir listedir. Listede olan domainler ilk ziyaretten itibaren HTTPS zorlu olur (klasik HSTS'te ilk ziyaret sırasında MITM riski vardı).
Uyarı: HSTS açıkken sertifika hatası kullanıcının sitenize hiç erişememesine yol açar (bypass yok). Yeni site açarken HSTS'i 6 ay test sonra preload'a almayı düşünün; sertifika otomasyonunuza ve operasyonel istikrarınıza güveniyorsanız.
Buyukweb cPanel paketlerinde HSTS header'ı .htaccess üzerinden eklenebilir:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>
OCSP Stapling ve Must-Staple
Sertifikanın iptal edilip edilmediğini kontrol etmek için iki klasik mekanizma var: CRL (Certificate Revocation List) ve OCSP (Online Certificate Status Protocol). CRL pratikte yavaş ve büyük; OCSP daha hızlı ama yine de tarayıcı her bağlantıda CA'ya gidip "bu sertifika hâlâ geçerli mi?" sormak zorunda — gizlilik ve performans sorunu.
OCSP Stapling bu sorunu çözer: sunucu, OCSP cevabını periyodik olarak CA'dan alır ve TLS handshake sırasında tarayıcıya "iliştirir" (staple). Tarayıcı CA'ya hiç gitmez; sertifika iptal durumu sunucudan gelir.
# Nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/ca-chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
# Apache
SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
Must-Staple (RFC 7633) bir adım öteye gider: sertifikanın kendisi "ben OCSP stapling olmadan sunulamam" deklarasyonunu içerir. Tarayıcı stapling görmezse bağlantıyı reddeder. Yüksek güvenlikli ortamlarda kullanılır; ama operasyonel disiplin gerektirir (stapling cache'i düşerse site erişilemez olur).
OCSP stapling Buyukweb cPanel/Plesk sunucularında varsayılan aktif. VDS müşterilerinin Nginx/Apache config'inde yukarıdaki satırları eklemesi yeterli.
Mixed Content Sorunu
Sayfa HTTPS ama içinde HTTP üzerinden yüklenen kaynaklar varsa mixed content uyarısı çıkar. Modern tarayıcılar bunu giderek sıkılaştırıyor:
- Active mixed content (script, iframe, stylesheet) — Chrome bloklar, sessizce yüklemez.
- Passive mixed content (image, video, audio) — Chrome otomatik HTTPS'e yükseltmeyi dener, başarısızsa bloklar.
- Form action HTTP'ye — Chrome 89+ uyarı gösterir.
WordPress sitelerinde tipik mixed content kaynağı: eski yazıların içeriğinde absolute HTTP linkler veya HTTP'den eklenmiş eski tema görselleri. Çözüm:
- Better Search Replace eklentisi ile veritabanında
http://example.com→https://example.comtoplu değişim. - Really Simple SSL eklentisi otomatik HTTPS yönlendirme + mixed content fixer.
.htaccessüzerinden global HTTP → HTTPS 301 redirect:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Sertifika Hatası Tipleri ve Hızlı Tanı
Üretimde karşılaşılan tipik sertifika hataları ve çözümleri:
| Hata kodu (Chrome) | Sebep | Çözüm |
|---|---|---|
NET::ERR_CERT_DATE_INVALID |
Süre dolmuş veya henüz başlamamış | Yenileme, sistem saatini kontrol |
NET::ERR_CERT_AUTHORITY_INVALID |
CA tarayıcı listesinde yok | Self-signed mi? CA'dan tekrar al |
NET::ERR_CERT_COMMON_NAME_INVALID |
SAN listesinde domain yok | Doğru SAN ile yeniden imzala |
NET::ERR_CERT_REVOKED |
Sertifika iptal edilmiş (CRL/OCSP) | Yeni sertifika al |
NET::ERR_CERT_WEAK_KEY |
RSA 1024 veya zayıf algoritma | RSA 2048+ veya ECDSA ile yeniden imzala |
NET::ERR_CERT_SYMANTEC_LEGACY (eski) |
Symantec güvensiz CA | Yeni CA'dan al |
SSL_ERROR_BAD_CERT_DOMAIN (Firefox) |
SAN uyumsuz | Doğru SAN ile yeniden imzala |
| Incomplete chain | Intermediate eksik | fullchain.pem (cert + intermediate) yükle |
Hızlı diagnose komutları:
# Sertifika bilgilerini gör
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| openssl x509 -noout -text
# Süre kontrolü
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| openssl x509 -noout -dates
# Zincir kontrolü
openssl s_client -showcerts -connect example.com:443 -servername example.com
# Online testler
# https://www.ssllabs.com/ssltest/
# https://crt.sh/?q=example.com
# https://www.sslshopper.com/ssl-checker.html
Ne Zaman Ücretli SSL? Karar Soruları
Müşterilerimizin sıkça sorduğu soru: "Buyukweb cPanel'imde ücretsiz Let's Encrypt var, neden ücretli SSL alayım?" Karar için kontrol listesi:
DV/Let's Encrypt yeterli (müşterilerin ~%95'i):
- Tek/orta marka, KOBİ veya kişisel.
- Müşteri sözleşmelerinizde OV/EV koşulu yok.
- ISO 27001, PCI DSS gibi formel denetimden geçmiyorsunuz.
- Bankacılık / finans / devlet sektöründe değilsiniz.
- Sigorta/garanti ihtiyacınız (sertifika kaynaklı tazminat) düşük.
OV gerekebilir:
- B2B kurumsal müşterilerinizin tedarikçi denetim listesinde "OV+ sertifika" koşulu var.
- ISO 27001 veya PCI DSS denetim sürecindeyseniz.
- Kurumsal kimlik (Subject'te şirket adı) sertifikanızda görünmeli.
EV gerekebilir:
- Bankacılık / finans sektörü, BDDK düzenlemesi var.
- Devlet projesi, kamu ihalesi.
- Çok yüksek değerli e-ticaret, lüks segment.
- Sözleşme açıkça EV gerektiriyor.
- Sigorta/garanti gereksinimi (CA yüksek meblağlı tazminat poliçesi sağlar).
Buyukweb müşterileri için kurumsal OV/EV tedariği ticari CA üzerinden destek hattımız (0850 302 60 70) tarafından koordine edilir; cPanel SSL/TLS panelinden CSR oluşturma + CRT + intermediate yükleme 5 dakikalık bir iştir.
Türkiye Bağlamı: ESHS ve Web SSL Farkı
Türkiye'de ESHS (Elektronik Sertifika Hizmet Sağlayıcısı) terimini duyuyorsanız, web SSL ile karıştırmayın. ESHS, 5070 sayılı Elektronik İmza Kanunu kapsamında TÜBİTAK Kamu SM ve diğer akredite kurumlar tarafından verilen e-imza sertifikalarıdır:
- E-imza — Şahıs/kurum kimlikli, akıllı kart veya USB token üzerinde, hukuki belge imzalama (e-Devlet işlemleri, e-fatura, elektronik tebligat).
- Web SSL/TLS — Web sitesi sertifikası, public root CA'lar tarafından, tarayıcı güven deposu üzerinden.
İki tamamen farklı dünyadır:
| Boyut | ESHS / E-imza | Web SSL/TLS |
|---|---|---|
| Amaç | Belge / işlem imzalama (hukuki bağlayıcı) | Web bağlantı şifreleme + alan adı kimliği |
| Kapsayıcı çerçeve | 5070 Sayılı Kanun (TR) | CAB Forum BR (global) |
| Veriliş | Akredite ESHS (Kamu SM, E-Güven, TURKTRUST vb.) | Halka açık CA (Let's Encrypt, DigiCert, Sectigo vb.) |
| Tarayıcı güveni | Tarayıcı ile alakasız | Tarayıcı kök CA listesi gerekir |
| Saklama | Akıllı kart, USB token, HSM | Sunucu disk + private key korumalı |
Web SSL/TLS için TÜBİTAK Kamu SM halka açık SSL imzalamaz. Web sertifikası ihtiyacınız varsa global CA'lar (Let's Encrypt + ticari) tek seçenektir.
cPanel AutoSSL Bağlamı: Buyukweb Müşterileri İçin
Buyukweb cPanel hosting paketlerinde Let's Encrypt AutoSSL standart ve müşteri tarafında konfigürasyon gerektirmez. Detaylar:
- Otomatik kurulum: Domain hesabınıza bağlandığı an, AutoSSL daemon gece taramasında DV sertifika talep eder.
- Tüm subdomain'ler: cPanel'deki addon domain, subdomain, alias domain, parked domain — hepsi otomatik kapsanır.
- Otomatik yenileme: Süresi 30 günden az kalan sertifikalar her gece otomatik yenilenir. Hata olursa cPanel hesabınıza mail bildirim gelir.
- TLS 1.2 + 1.3 varsayılan aktif, eski sürümler kapalı.
- HSTS opsiyonel —
.htaccessüzerinden açabilirsiniz. - OCSP Stapling aktif.
cPanel SSL/TLS panelinde:
- Manage SSL Sites — Mevcut sertifikaları görme, manuel ekleme.
- CSR Generator — Ticari CA için CSR oluşturma.
- Install SSL — Ticari CA'dan aldığınız CRT'yi yükleme.
- AutoSSL — Otomatik yenileme durumu, hata logları.
cPanel AutoSSL'in özel kullanımı için detaylı adımlar için cPanel SSL Sertifikası Kurulumu (Let's Encrypt) rehberimize göz atabilirsiniz.
Wildcard sertifika cPanel AutoSSL ile gelmez (her subdomain için ayrı leaf alır). Wildcard isteyen VDS müşterileri certbot DNS-01 challenge ile alabilir; detay için Wildcard SSL ve DNS-01 Challenge rehberi.
VDS Üzerinde SSL/TLS Yönetimi
Buyukweb VDS sunucularında tam root erişimi var; sertifika yönetimi tamamen size kalıyor. Tipik kurulumlar:
Certbot (Resmi Let's Encrypt Client)
# Ubuntu/Debian
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
# RHEL/AlmaLinux/Rocky
sudo dnf install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
# Cron ile otomatik yenileme (genelde paket otomatik kurar)
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx"
Acme.sh (Hafif Alternative)
curl https://get.acme.sh | sh -s [email protected]
~/.acme.sh/acme.sh --issue -d example.com -d www.example.com --webroot /var/www/html
~/.acme.sh/acme.sh --install-cert -d example.com \
--key-file /etc/nginx/ssl/example.com.key \
--fullchain-file /etc/nginx/ssl/example.com.fullchain.pem \
--reloadcmd "systemctl reload nginx"
Wildcard (DNS-01)
# Manuel DNS TXT
sudo certbot certonly --manual --preferred-challenges dns \
-d "*.example.com" -d example.com
# DNS API ile otomatik (örnek: Cloudflare API)
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d "*.example.com" -d example.com
Apache / Nginx Konfig Detayı
Apache SSL/TLS yapılandırma rehberimizde mod_ssl, VirtualHost, cipher suite ve HSTS konfigürasyonu detaylı işlendi.
Sıkça Sorulan Sorular (SSS)
1. Ücretsiz Let's Encrypt sertifikası ücretliden eksik bir şey mi?
Hayır. Şifreleme açısından sıfır fark. İkisi de aynı TLS protokolü, aynı cipher suite, aynı RSA/ECDSA anahtarları kullanır. Tarayıcılar her iki sertifika için de aynı "Güvenli" asma kilit gösterir. Fark sadece doğrulama seviyesi (Let's Encrypt sadece DV verir) ve iş süreci (Let's Encrypt 90 gün + otomatik yenileme, ticari CA 1 yıl + manuel yönetim). Müşterilerimizin %95'i için Let's Encrypt + cPanel AutoSSL kombinasyonu yeterli.
2. EV sertifikası almalı mıyım?
Genel cevap: Hayır, almayın. EV'nin görsel avantajı (yeşil bar) 2018-2020'de büyük tarayıcılardan kaldırıldı. Stanford ve Google araştırmaları EV'nin kullanıcı davranışını anlamlı şekilde değiştirmediğini gösterdi. EV hâlâ sadece üç senaryoda anlamlı: bankacılık/finans (PCI DSS, BDDK), devlet/kamu ihaleleri, kurumsal B2B sözleşme zorunluluğu. Bu kategorilerin dışındaysanız DV (Let's Encrypt) veya en fazla OV yeterli.
3. Wildcard mı SAN sertifika mı?
Birden çok subdomain'iniz var ve sayısı bilinmeyen veya sürekli artıyor (SaaS, müşteri panel) — Wildcard. Birden çok farklı domain (marka1.com + marka2.com.tr + shop.marka3.net) — SAN/Multi-Domain. Wildcard ile SAN'ın güvenlik trade-off'u: wildcard tek private key, sızdırılırsa tüm subdomain'ler etkilenir; SAN her domain ayrı ele alınabilir ama her ekleme/çıkarmada reissue gerekir. Kurumsal müşterilerimiz sıkı güvenlik politikalarında wildcard yerine SAN tercih ediyor; SaaS müşterilerimiz wildcard'ı kolay yönetim için seçiyor.
4. Sertifikamı her hosting sağlayıcıda kullanabilir miyim?
Evet. SSL/TLS sertifikası sunucudan/sağlayıcıdan bağımsızdır. Ticari CA'dan aldığınız bir DV/OV/EV sertifikayı özel anahtar + sertifika + intermediate dosyalarıyla hangi sunucuya kurarsanız orada çalışır. Buyukweb cPanel müşterilerimiz SSL/TLS paneli üzerinden 5 dakikada import edebilir; VDS müşterileri Nginx/Apache config'ine path olarak ekler. Private key'i hiçbir zaman paylaşmayın, hosting sağlayıcı değiştirseniz bile yeni yere taşıyın.
5. Mixed content uyarısı alıyorum, ne yapayım?
Sayfanızdaki HTTP linkleri bulun (Chrome DevTools → Console + Network tabı). En yaygın kaynaklar: (a) eski blog yazılarındaki absolute HTTP linkler, (b) HTTP'den eklenmiş tema görselleri, (c) HTTP üzerinden yüklenen 3. taraf script'ler. WordPress'te Better Search Replace veya Really Simple SSL eklentileri toplu çözüm sağlar. Manuel düzeltme için .htaccess üzerinden global HTTPS redirect ekleyin (yukarıdaki örnek). Mixed content tipik olarak migration sonrası ortaya çıkar.
6. HSTS açtım ama site kapandı, geri çeviremiyor muyum?
HSTS'in en büyük riski budur. Eğer preload flag'ı aktif ve HSTS Preload List'e kayıt yaptırdıysanız, tarayıcılar 6 aydan kısa sürede listeden çıkarmaz. Geri dönüş süreci: (1) sertifika sorunu çözün ve site HTTPS'de düzgün çalışır hale getirin, (2) HSTS header'da max-age=0 ile yeni response gönderin, (3) Preload List'ten çıkarma talebi (hsts-preload.appspot.com submit removal) — birkaç ay sürebilir. Pratik tavsiye: yeni site açarken HSTS'i 6 ay test sonra ve preload olmadan ekleyin, oturduğundan emin olduğunuzda preload'a alın.
7. Otomatik yenileme nasıl test edilir?
certbot renew --dry-run komutu, gerçek yenileme yapmadan tüm süreci simüle eder. Sorun varsa hata mesajı verir. Cron'un çalıştığını doğrulamak için /var/log/letsencrypt/letsencrypt.log veya /var/log/syslog (cron giriş satırları) bakılabilir. Healthchecks.io gibi cron monitoring servisleri yenileme atlandığında size mail/SMS bildirim atar — kritik production için şiddetle öneririm. Buyukweb cPanel paketlerinde AutoSSL hatası durumunda cPanel hesap e-postasına otomatik bildirim gelir.
8. Sertifika alırken nelere dikkat etmeliyim?
DV ise: Let's Encrypt yeterli, cPanel AutoSSL otomatik yönetir. Karar verilecek bir şey yok. OV/EV alıyorsanız: (a) CA'nın köklülüğü/güvenilirliği (DigiCert, Sectigo, GlobalSign, Entrust gibi köklü seçenekler), (b) garanti/sigorta miktarı (CA'nın sertifika hatası halinde tazminat tutarı), (c) revoke + reissue süresi (acil iptal durumunda CA kaç saatte yeni sertifika verir), (d) destek dili (Türkçe destek gerekirse Türkiye akredite bayi/distribütör), (e) SAN domain sayısı sınırı ve ekleme maliyeti. Buyukweb müşterileri için kurumsal OV/EV tedarik sürecinde destek hattımız bu seçenekleri size sunar.
Sonuç ve Sonraki Adımlar
SSL/TLS sertifikaları artık "lüks" değil, temel altyapının vazgeçilmez bir parçası. Doğru tür ve kapsam seçimi şu özetle yapılabilir:
- Çoğu site için DV + Single Domain → Let's Encrypt + cPanel AutoSSL (Buyukweb otomatik).
- Çoklu subdomain (SaaS, müşteri panel) → DV + Wildcard, VDS + certbot DNS-01.
- Çoklu domain (çoklu marka, mail sunucu) → DV + SAN, certbot multi-domain.
- B2B kurumsal güvenlik politikası → OV ticari CA.
- Bankacılık, finans, devlet → EV ticari CA + sıkı operasyonel disiplin.
Tüm planlarda ortak zorunlu unsurlar:
- TLS 1.2 + 1.3 aktif, eski sürümler kapalı.
- Modern cipher suite (ECDHE + AEAD, forward secrecy).
- HSTS header, en az 6 ay test sonra preload.
- OCSP Stapling aktif.
- Otomatik yenileme (90 gün norm, manuel yıllık yönetim YANLIŞ).
- CT log monitoring (crt.sh + alerting).
- CAA DNS kaydı ile CA whitelist.
Buyukweb cPanel paketlerimizde bu unsurların çoğu standart aktif; VDS müşterilerimiz kendi tercihlerini yapar. Sertifika geçerlilik süreleri 90 güne ve yakın gelecekte 47 güne inerken otomasyon vazgeçilmez hale geliyor — manuel yenileme alışkanlığı olan ekiplerin acilen bunu otomatize etmesi gerekiyor.
İlgili Büyükweb Hizmetleri
SSL/TLS'le beraber tüm web altyapınız Türkiye lokasyonlu, hızlı ve KVKK uyumlu çalışsın:
- cPanel Web Hosting (ücretsiz AutoSSL dahil)
- WordPress Hosting
- Plesk Web Hosting
- VDS Sunucu (custom SSL + Let's Encrypt)
- Reseller Hosting (SSL otomasyon dahil)
- Paket Karşılaştırma
İlgili teknik rehberler:
- Ücretsiz SSL ve Let's Encrypt ACME
- cPanel SSL Sertifikası Kurulumu
- Wildcard SSL ve DNS-01 Challenge
- Apache SSL/TLS Yapılandırma
Kurumsal OV/EV sertifika tedariği, wildcard kurulumu, ticari CA importu veya genel SSL/TLS sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden 7/24 destek sağlıyoruz.
Güvenlik & SSL İlgili Hizmetlerimiz
Bu yazıda anlatılan teknik konuyu profesyonel altyapıyla deneyimleyin
Etiketler:
