SSL Sertifikası Nedir? DV, OV, EV ve Wildcard Farkı

Bir web sitesine https:// ile girdiğinizde tarayıcınız sayfadan önce sunucunun sertifikasını ister. Sertifikanın içinde üç temel bilgi vardır: hangi alan adlarına ait olduğu, sunucunun açık anahtarı ve bu ikisini birbirine bağlayan CA imzası. Tarayıcı imzayı kendi güvendiği kök sertifikalara kadar takip eder, adres çubuğundaki adı sertifikadaki adlarla eşleştirir ve tarihe bakar. Üçü de tutarsa bağlantı kurulur. Biri tutmazsa ziyaretçi tam sayfa bir uyarıyla karşılaşır.

Kafede, havalimanında ya da otel ağında bir iletişim formu doldurduğunuzu düşünün. HTTPS yoksa aynı ağdaki biri ya da trafiğin geçtiği herhangi bir cihaz, forma yazılan parolayı, T.C. kimlik numarasını ve adresi düz metin olarak okuyabilir. Şifreleme bunu bitirir. Aynı şifreli kanal bütünlük de sağlar: paket yolda değiştirilirse bağlantı kopar, bu yüzden ücretsiz ağların sayfaya reklam ya da betik sıkıştırması mümkün olmaz.

Kimlik doğrulama ise sertifikanın daha az fark edilen tarafı. Adres çubuğuna ornek.com yazan ziyaretçi, ornek.com için gerçekten sertifika alabilmiş birinin sunucusuna bağlanır. Saldırgan DNS’i zehirleyip trafiği kendi makinesine çekse bile o alan adına geçerli bir sertifika sunamaz ve tarayıcı bağlantıyı durdurur.

Konu (Subject, CN)

CN=ornek.comSertifikanın ana adı. Tarayıcılar artık eşleştirmede bu alana değil SAN listesine bakar.

SAN listesi

DNS:ornek.com, DNS:www.ornek.comSertifikanın geçerli olduğu bütün adlar. www, alt alanlar ve ek alan adları buraya yazılır.

Yayımlayan (Issuer)

Bir CA’nın ara sertifikasıSertifikayı imzalayan ara CA. Zincir buradan köke yürür.

Geçerlilik

Not Before / Not AfterBaşlangıç ve bitiş anı. 2026’da düzenlenen sertifikada en fazla 200 gün.

Açık anahtar

RSA 2048 veya ECDSA P-256El sıkışmada sunucunun kimliğini kanıtlamak için kullanılır. Eşi olan özel anahtar sunucuda kalır.

Kurum (O)

OV ve EV’de şirket unvanıDV sertifikada bu alan boştur; şirket adını göstermek bu alanın işidir.

Adı hâlâ SSL olsa da bugün kullanılan protokol TLS’tir. SSL 2.0 ve 3.0 yıllar önce kırıldı ve kapatıldı, TLS 1.0 ile 1.1 de artık kullanım dışı sayılıyor. Sağlıklı bir sunucu bugün TLS 1.2 ve TLS 1.3 konuşur. Sertifika ise protokolden bağımsızdır: “SSL sertifikası” ile “TLS sertifikası” aynı dosyadır, piyasa eski adı bırakmadığı için iki isim birlikte yaşıyor.

Sık karıştırılan bir nokta var. Kilit simgesi, sitenin güvenilir bir işletmeye ait olduğunu söylemez. Oltalama sitelerinin büyük bölümü de geçerli ve ücretsiz bir sertifikayla yayın yapar, çünkü DV sertifika yalnız alan adını kontrol ettiğinizi kanıtlar. Sertifika kanalı korur, karşıdaki tarafın niyetini değil. Sızma testlerinde oltalama senaryosu hazırlarken bizim de ilk yaptığımız iş, sahte alan adına birkaç dakikada ücretsiz bir sertifika almak oluyor.

Sertifika satın alma, kurulum ve yenileme takibini tek yerden yürütmek isterseniz lisans satış hizmetimizde SSL ürünleri Microsoft 365 ve diğer lisanslarla aynı panelde izleniyor. Satın almadan önce neyi, neden aldığınızı netleştirmek için aşağıdaki bölümler yeterli.

Tarayıcı ile sunucu arasındaki ilk birkaç milisaniyeye TLS el sıkışması denir. TLS 1.3’te bu iş tek gidiş-dönüşte biter. Tarayıcı desteklediği şifreleme yöntemlerini ve anahtar paylaşım verisini gönderir; sunucu seçtiği yöntemi, sertifikasını ve sertifikadaki anahtarın sahibi olduğunu kanıtlayan bir imzayı yollar. İki taraf bu sırada ortak bir oturum anahtarı türetir ve sonraki her paket bu anahtarla şifrelenir.

Önemli bir ayrıntı: verinin kendisi sertifikadaki anahtarla şifrelenmez. Sertifika yalnız “karşımdaki gerçekten bu alan adının sahibi mi?” sorusuna cevap verir. Oturum anahtarları her bağlantıda yeniden üretildiği için, bir gün sunucunun özel anahtarı çalınsa bile TLS 1.3 ile kaydedilmiş eski trafik çözülemez. Buna ileriye dönük gizlilik (forward secrecy) denir.

1. 1ClientHelloTarayıcı desteklediği TLS sürümlerini, şifre takımlarını ve anahtar paylaşımını gönderir. SNI alanında hangi alan adına gittiğini de söyler; aynı IP adresinde onlarca site olabilir.
2. 2ServerHello ve sertifikaSunucu yöntemi seçer, site sertifikasını ve ara sertifikayı gönderir, ardından özel anahtarıyla el sıkışmayı imzalar.
3. 3DoğrulamaTarayıcı zinciri kendi kök deposuna kadar yürütür, adresi SAN listesinde arar, tarihleri ve imzaları kontrol eder.
4. 4Finishedİki taraf ortak anahtarı teyit eder. Bundan sonra HTTP istekleri şifreli tünelden akar.

Güven zinciri: kök, ara ve site sertifikası

Tarayıcınız sitenizin sertifikasını doğrudan tanımaz. Tanıdığı şey, işletim sisteminin ya da tarayıcının içine önceden yüklenmiş kök sertifikalardır; listeyi Mozilla, Apple, Microsoft ve Google kendi programlarıyla yönetir. Kök CA’lar site sertifikası imzalamaz; onun yerine ara sertifika (intermediate) imzalar, sitenizin sertifikasını imzalayan da bu ara sertifikadır. Doğrulama zinciri şöyle kurulur: site sertifikası, ara sertifika, kök. Halkalardan biri eksikse zincir kopar.

Sunucunun görevi kendi sertifikasıyla birlikte ara sertifikayı da göndermektir. Kökü göndermesine gerek yok, istemcide zaten var. CA’nın size verdiği paketteki ca-bundle, chain.pem ya da fullchain.pem dosyası bu yüzden önemli. Masaüstü tarayıcılar eksik ara sertifikayı çoğu zaman kendileri tamamlar. Hata da tam bu yüzden site sahibinin gözünden kaçar.

# 1) Sunucunun gönderdiği zincir ve doğrulama sonucu
openssl s_client -connect ornek.com:443 -servername ornek.com -showcerts </dev/null
# "Certificate chain" altında en az 2 sertifika (site + ara) görünmeli.
# En altta "Verify return code: 0 (ok)" yazmıyorsa zincir eksik ya da hatalıdır.

# 2) Site sertifikasının adları ve tarihleri
openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

DV, OV ve EV, sertifika otoritesinin size sertifika vermeden önce ne kadar soru sorduğunu anlatır. Şifreleme algoritması, anahtar uzunluğu ve tarayıcıdaki kilit üçünde de aynıdır. Biri size “EV daha sağlam şifreler” diyorsa yanlış bilgi veriyor. Fark, sertifikanın içine kimin yazıldığında.

DV (Domain Validation) yalnız alan adını kontrol ettiğinizi doğrular. DNS’e bir TXT kaydı eklersiniz, sitenin belirli bir yoluna bir dosya koyarsınız ya da alan adının yetkili e-posta adresine gelen bağlantıya tıklarsınız. Süreç otomatikse dakikalar sürer, sertifikada şirket adı yer almaz. Let’s Encrypt gibi ücretsiz CA’ların verdiği sertifikaların hepsi DV’dir.

OV (Organization Validation) buna kurum kontrolünü ekler. CA, şirketin gerçekten var olduğunu resmî kayıtlardan, adresini ve telefonunu bağımsız bir kaynaktan doğrular. Türkiye’de bu genellikle Ticaret Sicili Gazetesi kaydı, vergi levhası ve kamuya açık bir rehberdeki numaradan yapılan geri arama demektir. Sertifikanın O alanına şirket unvanı, L ve C alanlarına şehir ve ülke yazılır.

EV (Extended Validation) en sıkı prosedürdür. OV kontrollerine ek olarak şirketin faal olduğu, başvuruyu yapan kişinin imza yetkisi ve imzalı başvuru formu istenir; bazı durumlarda avukat ya da mali müşavir onay mektubu talep edilir. Sertifikaya kuruluş yeri ve sicil numarası da yazılır.

Süreler örnektir; CA’ya, evrakın hazır olmasına ve telefon doğrulamasının ilk denemede yapılıp yapılmamasına göre değişir. CA/Browser Forum’un 2025 kararıyla kurum bilgisi doğrulamasının tekrar kullanım süresi de kısaldı: OV ve EV sahipleri kurum kontrolünü artık yaklaşık yılda bir yeniden yaşıyor.

EV’nin parlak dönemi 2019’da bitti. Eylül 2019’da Chrome 77, ekim ayında da Firefox 70, adres çubuğundaki yeşil şirket adını kaldırıp sertifika ayrıntısına taşıdı; tarayıcı ekiplerinin araştırmaları kullanıcıların bu göstergeye bakmadığını göstermişti. Bugün EV ile OV arasındaki farkı görmek için ziyaretçinin kilide tıklayıp sertifika ayrıntısını açması gerekiyor. Yine de EV’nin anlamlı olduğu yerler kaldı. Bazı banka ve ödeme kuruluşu entegrasyonları, EV’yi açıkça yazan ihale şartnameleri ya da tedarikçisinden EV isteyen büyük kurumlar bunlara örnek. Bu durumların dışında EV için ödenen fark çoğunlukla prosedüre gidiyor.

Wildcard sertifika, alan adının başına yıldız koyar: *.ornek.com. Bu tek sertifika shop.ornek.com, blog.ornek.com, panel.ornek.com ve yarın açacağınız kampanya.ornek.com için geçerlidir. Yeni alt alan için yeni sipariş gerekmez; sık alt alan açan ajanslar ve her müşterisine ayrı adres veren SaaS ürünleri bu yüzden wildcard’ı sever.

Kuralın iki sınırı var ve ikisi de sık unutuluyor. Birincisi, yıldız yalnız tek seviyeyi kapsar: *.ornek.com, a.b.ornek.com için geçerli değildir, onun için *.b.ornek.com gerekir. İkincisi, yıldız boş geçilemez: *.ornek.com çıplak ornek.com adresini kapsamaz. Çoğu ticari CA kök alanı siparişe ek ad olarak kendiliğinden ekler; Let’s Encrypt’te ise iki adı birlikte istemeniz gerekir. Siparişte bunu kontrol edin.

EV wildcard diye bir ürün yok, EV kuralları yıldızlı ada izin vermiyor. Hem kurum adı hem çok sayıda alt alan istiyorsanız iki yolunuz var: OV wildcard ya da alt alanları tek tek yazdığınız bir EV SAN sertifikası.

Wildcard’ın asıl riski teknik değil, operasyonel. Tek sertifika, tek özel anahtar demek. O anahtar web sunucusuna, e-posta sunucusuna, test ortamına, yük dengeleyiciye ve bir ajansın staging makinesine kopyalandığında, en zayıf makine bütün alt alanların güvenliğini belirler. Test sunucusu ele geçirilirse saldırgan aynı anahtarla odeme.ornek.com adına da geçerli bir sertifika sunabilir.

Wildcard ne zaman yanlış seçimdir? Yalnız www ve bir panel alt alanınız varsa, iki adı içeren bir SAN sertifikası hem daha ucuz hem daha dar kapsamlıdır. Alt alanlar farklı ekiplerde ya da farklı tedarikçilerdeyse her birine ayrı sertifika vermek, birinin hatasının diğerine taşmasını önler. Her sunucunun kendi sertifikasını ACME ile otomatik aldığı bir düzende wildcard ihtiyacı zaten azalır.

SAN sertifikası, birbirinden farklı alan adlarını tek sertifikada toplar: ornek.com, ornek.com.tr, ornekmarka.com ve kampanya-ornek.com aynı dosyada yer alabilir. Markasını hem .com hem .com.tr ile koruyan, üstüne bir de kampanya alanı açan şirketlerde bu düzen çok yaygın. Her ad SAN listesine bir satır olarak yazılır; çoğu CA ilk birkaç adı paket fiyatına katar, sonrasını ad başına ücretlendirir.

Klasik SAN örneği şirket içi Exchange sunucusudur: Outlook istemcileri sertifika uyarısı vermesin diye mail.ornek.com ve autodiscover.ornek.com aynı sertifikada olmalıdır. Bir not düşeyim: e-postanız Exchange Online’daysa (Microsoft 365), autodiscover kaydı Microsoft’un sunucularına yönlenir ve o sertifikayı Microsoft yönetir. Bu SAN ihtiyacı yalnız kendi posta sunucusunu işleten şirketlere özgü. Planlar arasındaki farkları Microsoft 365 Business karşılaştırmasında, sunucu tarafındaki lisans hesabını Windows Server lisanslama rehberinde anlattık.

Kapsam türleri yan yana

Multi-domain wildcard iki yaklaşımı birleştirir: *.ornek.com ve *.ornek.com.tr aynı sertifikada olur. Ajanslarda ya da çok markalı yapılarda pratiktir, ama yukarıdaki anahtar paylaşım riski burada katlanır; tek anahtar artık birden çok markanın bütün alt alanlarını temsil eder.

SAN’ın kolaylığı ile riski aynı yerden gelir. Tek sertifikayı tek tarihte yenilersiniz ve envanter sadeleşir. Ama o sertifikanın süresi kaçarsa ya da iptal edilmesi gerekirse listedeki her site aynı anda etkilenir. Ayrıca SAN listesini okuyan herkes hangi alan adlarının aynı şirkete ait olduğunu görür; henüz duyurmadığınız bir markayı ortak sertifikaya koymayın.

Kısa cevap: çoğu site için evet. Let’s Encrypt’in verdiği sertifika ile ücretli bir DV sertifika arasında şifreleme, tarayıcı uyumluluğu ve kilit simgesi açısından fark yoktur. Fark; süre, destek, doğrulama türü ve garanti başlıklarındadır.

Ücretsiz sertifikanın tek gerçek şartı otomasyondur. Let’s Encrypt sertifikası bugün 90 gün geçerli ve CA bu süreyi önce 64, sonra 45 güne indirme takvimini açıkladı. Bu sürelerle elle yenileme er geç unutulur. Plesk’te SSL It! eklentisi, cPanel’de AutoSSL, Linux’ta certbot ya da acme.sh, Windows’ta win-acme bu işi kendiliğinden yapar. Otomasyon çalışıyorsa ücretsiz sertifika ücretli olandan daha az bakım ister.

W3’ün web hosting paketlerinde Let’s Encrypt sertifikası alan adları ve alt alanlar için otomatik yenilenerek geliyor; Business ve üstü paketlerde wildcard da dahil. Hosting faturasını başka hangi kalemlerin belirlediğini hosting fiyatları ve paket seçimi yazısında, sunucu türü kararını web hosting, VPS, bulut ve dedicated farkı rehberinde ele alıyoruz.

Tarayıcı üreticileri ile sertifika otoritelerinin ortak kural koyucusu CA/Browser Forum, Nisan 2025’te kabul ettiği SC-081 kararıyla herkese açık TLS sertifikalarının azami süresini kademeli olarak kısalttı. Oylamada Apple, Google, Microsoft ve Mozilla’nın dördü de evet dedi. Takvim, siparişin verildiği tarihe değil sertifikanın düzenlendiği tarihe bakar.

Gerekçe basit. Sertifika ne kadar uzun yaşarsa içindeki bilgi o kadar eskir: alan adı el değiştirir, şirket unvanı değişir, özel anahtar sızar. İptal (revocation) mekanizmaları da pratikte güvenilir çalışmıyor. Kısa ömür, yanlış düzenlenmiş ya da sızmış bir sertifikanın zararını kendiliğinden sınırlar. Bedelini ise yenilemeyi elle yapanlar öder.

Takvimin daha az konuşulan yarısı doğrulama verisinin tekrar kullanımı. Bugün alan adı doğrulamasını bir kez yapıp aynı sonucu 200 güne kadar yeni sertifikalarda kullanabiliyorsunuz. 2029’da bu süre 10 güne iniyor; yani pratikte her yenilemede alan adı kontrolü baştan yapılacak. E-postadaki onay bağlantısına tıklayarak doğrulama yapan bir iş akışı o noktada sürdürülemez, DNS kaydını API ile yazabilen bir otomasyon gerekir.

Ticari CA’lar takvime kendi tamponlarını ekliyor. Örneğin DigiCert 24 Şubat 2026’dan bu yana, sınırın bir gün altında kalmak için en fazla 199 gün veriyor. Let’s Encrypt ise kendi takvimini ayrıca açıkladı: varsayılan profil 10 Şubat 2027’de 64 güne, 16 Şubat 2028’de 45 güne iniyor. İsteyenler Mayıs 2026’dan beri 45 günlük profili, Ocak 2026’dan beri de altı günlük kısa ömürlü sertifikaları seçebiliyor.

“3 yıllık SSL” satan sayfaları hâlâ görürsünüz. Ürün ortadan kalkmadı, anlamı değişti. Çok yıllık bir sipariş artık çok yıllık abonelik demek: ödemeyi bir kez yaparsınız, CA abonelik boyunca size en geç 200 günde bir (2027’de 100, 2029’da 47 günde bir) yeni sertifika düzenler ve her seferinde onu sunucuya kurmanız gerekir. Lisans satış sayfamızdaki “1–3 yıl” ifadesi de bu abonelik süresini anlatıyor.

Yedi soruyu yanıtlayın. Sihirbaz doğrulama düzeyini ve kapsamı ayrı ayrı belirler, ücretsiz sertifikanın yetip yetmeyeceğini söyler, 2026, 2027 ve 2029 kurallarına göre yılda kaç yenileme yapacağınızı hesaplar ve kurulumunuza özel riskleri listeler. Sonuç genel kurallara dayanır; şartnameniz ya da sözleşmeniz başka bir şey istiyorsa o geçerlidir.

Ücretli bir sertifikanın yaşam döngüsü her CA’da aynı beş adımdan geçer. Ücretsiz sertifikada ilk üç adımı ACME istemcisi sizin yerinize birkaç saniyede yapar. Yine de neyin olup bittiğini bilmek, bir şey bozulduğunda nereye bakacağınızı gösterir.

1. 1Özel anahtar ve CSR oluşturunCSR (sertifika imzalama isteği), açık anahtarınızı ve sertifikaya yazılacak adları içeren dosyadır. Özel anahtar bu adımda sunucuda üretilir ve sunucudan çıkmamalıdır. Plesk’te Websites & Domains → alan adı → SSL/TLS Certificates (Türkçe arayüzde Web Siteleri ve Alan Adları → SSL/TLS Sertifikaları), cPanel’de Security → SSL/TLS, IIS’te sunucu düğümü → Server Certificates → Create Certificate Request menüsü bu işi arayüzden yapar. Komut satırı örneği aşağıda.
2. 2Siparişi verin, doğrulamayı tamamlayınCSR’ı CA’nın ya da bayinin paneline yapıştırırsınız. DV için üç yöntemden biri seçilir: DNS’e TXT ya da CNAME kaydı, sitenin /.well-known/pki-validation/ yoluna dosya veya admin@, webmaster@ gibi yetkili bir adrese gelen e-posta onayı. Wildcard sertifikada dosya yöntemi kullanılamaz. OV ve EV’de buna kurum evrakı ile telefon doğrulaması eklenir. DNS kayıtlarınızın nerede yönetildiğinden emin değilseniz domain ve hosting bağlama rehberimiz nameserver ile DNS kaydı farkını adım adım anlatıyor.
3. 3Sertifikayı ve ara sertifikayı kurunCA size site sertifikasını ve ara sertifika paketini gönderir. Nginx’te ikisi tek dosyada birleştirilir: önce site sertifikası, sonra ara sertifika. Apache 2.4.8 ve sonrasında da aynı birleşik dosya kullanılabilir. IIS’te bekleyen istek tamamlanır, ardından site → Bindings → https bağlamasında sertifika seçilir. Paylaşımlı hostingte sertifika ve CA paketi panelde ayrı kutulara yapıştırılır.
4. 4HTTP’den HTTPS’e kalıcı yönlendirme ekleyinTüm http:// ve www/kök varyantlarını tek adımda nihai https:// adresine 301 ile gönderin. Site birkaç gün HTTPS üzerinden hatasız çalıştıktan sonra HSTS başlığını ekleyin. HSTS tarayıcıya bu alan adına bir daha şifresiz bağlanmamasını söyler; geri alması zor olduğu için önce kısa bir max-age ile deneyin. Taşıma sırasında yönlendirme hatalarının SEO etkisini site taşıma rehberimizde ayrıntılı işledik.
5. 5Dışarıdan test edin, takvime yazınQualys SSL Labs Server Test zinciri, protokol sürümlerini ve şifre takımlarını puanlar; komut satırında testssl.sh aynı işi yapar. Hedef: TLS 1.0 ve 1.1 kapalı, zincir tam, sertifika tüm adları kapsıyor. Ardından bitiş tarihini envantere ve izleme aracına yazın.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout ornek.com.key -out ornek.com.csr \
  -subj "/C=TR/L=Istanbul/O=Ornek Ltd. Sti./CN=ornek.com" \
  -addext "subjectAltName=DNS:ornek.com,DNS:www.ornek.com"

# DV siparişinde O/L alanları yok sayılır; OV/EV'de resmî unvanla aynı olmalı.
# CSR'ı paylaşın; ornek.com.key dosyası sunucuda kalsın (chmod 600).

server {
  listen 80;
  server_name ornek.com www.ornek.com;
  return 301 https://ornek.com$request_uri;
}
server {
  listen 443 ssl;
  server_name www.ornek.com;
  ssl_certificate     /etc/ssl/ornek.com/fullchain.pem;
  ssl_certificate_key /etc/ssl/ornek.com/ornek.com.key;
  return 301 https://ornek.com$request_uri;
}
server {
  listen 443 ssl;
  server_name ornek.com;
  ssl_certificate     /etc/ssl/ornek.com/fullchain.pem;   # site + ara sertifika
  ssl_certificate_key /etc/ssl/ornek.com/ornek.com.key;
  ssl_protocols TLSv1.2 TLSv1.3;
  add_header Strict-Transport-Security "max-age=300" always;  # önce kısa süreyle deneyin
  # ...
}

sudo certbot --nginx -d ornek.com -d www.ornek.com
sudo certbot renew --dry-run      # yenilemenin gerçekten çalıştığını sınayın
systemctl list-timers | grep certbot   # zamanlayıcı kurulu mu?

SSL sertifikası fiyatları arasında en ucuz DV ile çok adlı bir EV arasındaki fark ilk bakışta şaşırtıcıdır, ama fiyatı belirleyen kalem sayısı sınırlı. Burada rakam vermiyorum: sertifikalar çoğunlukla dolar bazlı fiyatlanır ve TL karşılığı kura, CA’nın kampanyasına ve abonelik süresine göre değişir. Güncel fiyat ve KDV’li TL teklif için lisans satış sayfamıza bakabilirsiniz.

• 01Doğrulama türüDV, OV ve EV sırasıyla pahalanır. Fark, CA’nın yaptığı insan emeğine dayalı kontrollerden gelir; şifreleme aynıdır.
• 02KapsamTek alan, SAN (ek ad başına ücret), wildcard ve multi-domain wildcard sırasıyla pahalanır. Wildcard fiyatı genellikle birkaç tek alan sertifikasına denk gelir.
• 03CA markasıAynı DV ürünü farklı markalarda farklı fiyatlanır. Tarayıcı açısından hepsi güvenilir köklere bağlıdır; fark destek, yönetim paneli ve marka algısıdır.
• 04Abonelik süresiÇok yıllık abonelik yıllık maliyeti düşürür ve fiyatı (çoğunlukla dolar bazında) sabitler, ama yeniden düzenleme işini azaltmaz.
• 05Garanti tutarıCA’nın hatalı düzenlediği bir sertifika yüzünden zarar gören tarafa ödeyeceği azami tutardır. Koşulları dar olduğu için seçim ölçütü yapmayın.
• 06Kur ve KDVDolar bazlı ürünlerde TL fiyatı kurla değişir; teklifte KDV’nin dahil olup olmadığına bakın.
• 07Kurulum ve takipCSR hazırlığı, kurulum ve yenileme takibi ayrı bir hizmet kalemi olabilir; teklifleri bu toplamla karşılaştırın.

Paranın boşa gittiği seçimler

• ×Tek alan adlı kurumsal site için EV almak: ziyaretçi farkı görmez, siz her yıl daha uzun bir doğrulama süreci yaşarsınız.
• ×İki alt alan için wildcard almak: www ve panel için iki adlı bir SAN ya da iki ücretsiz sertifika yeter.
• ×ACME kurulabilecek bir sunucu için ücretli DV almak: aynı şifrelemeyi ücretsiz ve daha az bakımla alırsınız.
• ×Garanti tutarı yüksek diye pahalı ürün seçmek.
• דSEO için” ücretli sertifika almak: arama motoru ücretli ve ücretsiz DV arasında ayrım yapmaz.

Chrome’un Türkçe arayüzünde “Bağlantınız gizli değil”, Firefox’ta “Olası güvenlik riski” uyarısıyla açılan sayfa, tarayıcının sertifika kontrollerinden birinin başarısız olduğunu söyler. Sayfanın altındaki hata kodu sorunun ne olduğunu çoğu zaman açıkça yazar; destek talebi açmadan önce o kodu not edin.

Hatanın sahibi bazen site, bazen ziyaretçinin cihazıdır. Herkeste aynı anda çıkıyorsa sorun sunucudadır. Yalnız tek bir bilgisayarda, tek bir ağda ya da yalnız şirket ağında çıkıyorsa cihaz saatine, antivirüsün HTTPS taramasına veya kurumsal güvenlik duvarına bakın.

• NET::ERR_CERT_DATE_INVALIDSertifikanın süresi dolmuş ya da cihazın saati yanlış.
  Site sahibiSertifikayı yenileyin ve otomatik yenilemenin neden çalışmadığını bulun; tek seferlik düzeltme yetmez.

  ZiyaretçiCihazın tarih ve saatini otomatik ayara alın.
• NET::ERR_CERT_COMMON_NAME_INVALIDAdres sertifikanın ad listesinde yok. Klasik örnek: sertifika yalnız www.ornek.com için, ziyaretçi ornek.com yazmış.
  Site sahibiEksik adı sertifikaya ekleyip yeniden düzenleyin. Yönlendirme yapacak adres için de geçerli sertifika gerekir.

  ZiyaretçiAdresi kontrol edin; sorun büyük ihtimalle sitede.
• NET::ERR_CERT_AUTHORITY_INVALIDZincir tamamlanamadı: ara sertifika eksik, sertifika kendinden imzalı ya da araya bir cihaz giriyor.
  Site sahibiAra sertifikayı (fullchain) kurun; kendinden imzalı sertifikayı herkese açık sitede kullanmayın.

  ZiyaretçiOtel ya da şirket ağındaysanız başka bir ağdan deneyin, antivirüsün HTTPS taramasını kontrol edin.
• Karışık içerik (mixed content)Sayfa HTTPS, ama içindeki görsel, betik ya da font http:// ile yükleniyor. Kilit bozulur, betikler engellenir.
  Site sahibiKaynak adreslerini https:// ya da göreli yola çevirin; veritabanındaki eski içerik linklerini toplu güncelleyin.

  ZiyaretçiYapacak bir şey yok; site düzeltmeli.
• ERR_TOO_MANY_REDIRECTSHTTPS yönlendirmesi döngüye girmiş. Klasik senaryo: Cloudflare “Flexible” moddayken sunucuya HTTP ile gider, sunucu isteği yeniden HTTPS’e yönlendirir ve döngü başlar.
  Site sahibiCDN ile sunucu arasını da HTTPS yapın (Full / Strict), yönlendirmeyi tek bir yerde tanımlayın.

  ZiyaretçiÇerezleri temizlemek bazen geçici çözümdür; kalıcı düzeltme sitededir.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCHTarayıcı ile sunucu ortak bir TLS sürümü ya da şifre takımında anlaşamadı; çok eski ya da hatalı yapılandırılmış sunucu.
  Site sahibiTLS 1.2 ve 1.3’ü açın, sunucu yazılımını güncelleyin, 443 portunun gerçekten bu ada sertifika sunduğunu kontrol edin.

  ZiyaretçiTarayıcıyı ve işletim sistemini güncelleyin.

Karışık içerik özellikle eski WordPress sitelerinde, HTTPS’e geçişten aylar sonra bile ortaya çıkar; yazılara gömülü http:// görseller veritabanında durur. Tarayıcı geliştirici araçlarının Console sekmesi “Mixed Content” uyarısıyla hangi dosyanın sorun çıkardığını söyler.

Arama motoru açısından da HTTPS’in tutarlı olması gerekir. Google HTTPS’i 2014’ten beri hafif bir sıralama sinyali olarak kullanıyor; asıl zarar ise uyarı sayfasından geri dönen ziyaretçiden ve bozulan taramadan gelir. HTTPS ve yönlendirme kontrollerinin teknik SEO tarafını teknik SEO audit kontrol listemizde bulabilirsiniz.

Bir şirkete kaç sertifikası olduğunu sorduğumuzda aldığımız cevap çoğu zaman “bir tane, web sitesinin” olur. Sonra CT kayıtlarına bakarız: e-posta sunucusu, VPN, muhasebe programının web arayüzü, ajansın kurduğu kampanya sitesi, yıllar önce açılmış bir test alt alanı. 47 günlük döneme hazırlığın ilk adımı bu listeyi çıkarmak; bilmediğiniz sertifikayı yenileyemezsiniz.

Envanter için crt.sh üzerinde alan adınızı aratın; o alan adı için düzenlenmiş herkese açık sertifikaları tarihleriyle görürsünüz. Buna iç ağdaki cihazları ekleyin (güvenlik duvarı, NAS, yazıcı, sanallaştırma paneli); bunlar CT kayıtlarında görünmez. Her satır için aşağıdaki alanları tutun ve bir sorumlu kişi atayın.

alan_adi,tur,kapsam,ca,bitis,sunucu,yenileme,sorumlu,not
ornek.com,DV,ornek.com+www,Let's Encrypt,2026-12-19,web-01 (Plesk),ACME otomatik,bt-sorumlusu,
*.ornek.com,OV,wildcard+kok,Ticari CA,2027-03-02,lb-01; mail-01,elle,bt-sorumlusu,anahtar 2 sunucuda
vpn.ornek.com,DV,tek alan,Ticari CA,2026-11-30,guvenlik-duvari,elle (ACME yok),ag-ekibi,cihaz takvimine ekle
kampanya.ornek.com,DV,tek alan,Let's Encrypt,2026-12-02,ajans sunucusu,ACME otomatik,ajans,kampanya bitince kapat

Otomasyon tarafında ACME protokolü artık standart. Let’s Encrypt’in yanında birçok ticari CA da ACME uç noktası sunuyor; yani ücretli bir OV sertifikayı da certbot ya da win-acme ile otomatik yenileyebilirsiniz. Güncel ACME istemcilerinin desteklediği ARI (ACME Renewal Information) özelliği, yenileme zamanını CA’nın önermesine izin verir; toplu iptal gibi olağan dışı durumlarda istemci kendiliğinden erken yeniler.

Son katman izleme. Otomatik yenileme sessizce bozulabilir; bu yüzden bitiş tarihini sunucunun içinden değil, ziyaretçinin gördüğü gibi dışarıdan kontrol eden bir izleme kurun ve bitişe 14 gün kala alarm verdirin. W3 lisans panelinde SSL dahil lisanslar için bitişten 60, 30 ve 7 gün önce e-posta ve SMS hatırlatması var; ACME ile yenilenen sertifikalarda asıl güvence yine de dış izleme alarmıdır.

Bir de CAA kaydı ekleyin. DNS’e yazdığınız bu kayıt, alan adınız için hangi CA’ların sertifika düzenleyebileceğini söyler; CA’lar düzenlemeden önce bu kaydı kontrol etmek zorundadır. Adınıza başka bir CA’dan sertifika alınması böylece zorlaşır.

ornek.com.  IN  CAA  0 issue "letsencrypt.org"
ornek.com.  IN  CAA  0 issue "sectigo.com"
ornek.com.  IN  CAA  0 iodef "mailto:guvenlik@ornek.com"

Yeni bir VPS’e sertifika kuruyorsanız işin geri kalanı (SSH sertleştirme, güvenlik duvarı, otomatik güncellemeler) için Linux sunucu güvenliği: ilk 24 saat rehberimiz iyi bir tamamlayıcı. TLS yapılandırmanızın ve sertifika yönetiminizin dışarıdan nasıl göründüğünü görmek isterseniz bu, güvenlik ve sızma testi çalışmalarımızın ilk adımlarından biri; sürecin nasıl işlediğini sızma testi rehberimizde anlattık.