Bu ürün için bir açıklama (slogan) mevcut değildir.
SSL yok
HTTPS olmadan ziyaretçi güveni kaybolur
Şifrelenmeyen http:// bağlantılarda tarayıcılar “Güvenli değil” uyarısı gösterir; formlar ve ödeme adımlarında tereddüt oluşur. Sayfaya https ile girmek istediğinizde ek onay isteyebilir.
http://siteniz.com
Google Chrome ve Mozilla Firefox gibi tarayıcılarda adres çubuğunda uyarı görünür; arama motorları da güvenli site sinyalini zayıflatır. Müşteri verisi ve marka itibarı riske girer.
Çözüm: Alan adınızı doğrulayan bir DV SSL ile dakikalar içinde https://’e geçin; uyarılar kalkar, trafik şifrelenir.
DV SSL
DV SSL ile hızlı doğrulama, güçlü şifreleme
Sertifika otoritesi yalnızca alan adına sahip olduğunuzu doğrular; evrak beklemeden TLS ile yayına alırsınız.
https://siteniz.com
Adres çubuğunda kilit ve https:// görünür; ziyaretçiler bağlantının şifrelendiğini anlar. Formlar, girişler ve API trafiği için standart güven katmanı sağlar.
Otomatik kurulum ve yenileme ile dakikalar içinde yayına alın; operasyonel yükü düşürün, kesinti riskini azaltın.
DV SSL Sertifikası Nedir?
Alan adı validasyonlu (Domain Validation DV) SSL sertifikası nedir, nerelerde ve hangi durumlarda kullanılmalıdır sorusunu sormadan tercih etmemelisiniz; DV’de sertifika otoritesi yalnızca alan adı üzerinde teknik kontrolünüz olduğunu doğrular (HTTP dosyası, DNS TXT veya e-posta yöntemleri). Şirket unvanı, adres veya yasal varlık incelemesi yoktur; bu yüzden süreç hızlıdır ve maliyet genelde OV/EV’den düşüktür. Kurumsal blog, pazarlama sitesi, API gateway (public), staging, iç araçlar ve çoğu web uygulaması için ideal başlangıçtır. Tarayıcıda kilit ve TLS şifrelemesi OV ile aynı kriptografik aile üzerinden çalışır; fark, sertifikada görünen kimlik iddiasının kapsamıdır.
- Tarayıcı ve sunucu arasında güvenli bir bağlantı kurar;
- Müşterilerinizin size sağladığı hassas bilgileri korumak için iletişimi şifreler;
- Tarayıcıda web adresinizin yanına bir kilit simgesi yerleştirir;
- Bir kuruluşun kimliğini doğrular...
Avantajlarını listeleyecek olursak; Hızlı yayına alma ve otomasyona uygun yenileme, Wildcard ile çoklu alt alan yönetiminde operasyonel rahatlık,
Bütçe kontrolü; çok sayıda hostname için ekonomik ölçeklemedir.
Sınırlar / dezavantajları listeleyecek olursak; Sertifika şirketinizi otomatik ispatlamaz; B2B sözleşmelerinde OV/EV istenebilir,
Yanlış yapılandırılmış CDN veya çoklu sunucuda doğrulama dosyası hataları sık görülür,
Süre dolunca anlık kesinti; takvim ve izleme şartdır.
* Alan adınız, SSL sertifikasını satan aynı ya da ayrı sağlayıcıda olabilir. Satın alacağınız sertifika sadece Apache, Nginx, IIS kullanan bir web sunucusunda çalışır.
DV SSL ile güvenliği hızlıca yayına alın
Alan adı doğrulamalı (DV) sertifikalar, sertifika otoritesinin yalnızca alan adı üzerindeki teknik kontrolünüzü doğruladığı çözümlerdir; şirket evrakı beklemeden HTTPS’e geçebilirsiniz.
Ziyaretçileriniz ile sunucunuz arasındaki trafik güçlü TLS şifrelemesiyle korunur; tarayıcıda adres çubuğunda kilit ve https:// görünür. Kurumsal vitrin, blog, API uçları ve çoğu web uygulaması için pratik ve ölçeklenebilir bir başlangıç noktasıdır. HTTPS kullanan siteler, arama motorlarında “güvenli web” sinyali açısından da avantajlıdır. DV SSL’in öne çıkan özellikleri:
Dakikalar içinde alan adı doğrulama
TLS ile uçtan uca şifreli iletişim
HTTPS ve güvenli kilit simgesi
OV/EV’ye göre genelde daha uygun maliyet
Yenileme ve çoklu sunucuya uygun kurulum
Tek alan, SAN ve Wildcard seçenekleri
Satın alma süreci nasıl ilerler?
Doğrulama yöntemleri, siparişten canlıya kurulum ve sertifika türü seçimi tek bakışta; ayrıntılar için aşağıdaki kutulara göz atın.
HTTP ile doğrulama
CA’nın verdiği token dosyasını tam yol üzerinden erişilebilir kılın. CDN önbelleği, 301 yönlendirme ve “www / apex” ayrımı doğrulamayı bozabilir; gerekirse geçici cache bypass kuralı kullanın.
DNS TXT kaydı
Belirtilen host için TXT değerini DNS’e ekleyin. Birden fazla DNS sağlayıcısı veya düşük TTL senaryolarında yayılım süresi uzayabilir; doğrulamayı tekrar denemeden önce tüm uçlarda kaydı doğrulayın.
E-posta ile doğrulama
WHOIS veya CA’nın sabit admin adreslerinden birine onay linki gelir. Kutuya erişimi kontrollü tutun; iletinin süresi dolmadan işlemi tamamlayın ve kimlik avı maillerine karşı gönderen adresini doğrulayın.
Siparişten canlıya üç adım
1) Özel anahtarı sunucuda tutarak CSR üretin; CN/SAN listesini eksiksiz yazın. 2) Sipariş sonrası CA panelinden doğrulama yöntemini seçip tamamlayın. 3) PEM veya PFX’i web sunucusu, yük dengeleyici veya CDN’e kurun; ara sertifika zincirini atlamayın.
Yenileme ve anahtar rotasyonu
ACME dışı ticari DV’lerde yenileme çoğu zaman yeniden doğrulama ister; takvim ve izleme şarttır. Üretimde aynı özel anahtarı sonsuza dek kullanmak yerine rotasyon planlayın; otomasyon varsa önce staging’de deneyin.
CDN ve çoklu sunucu
Origin arkasında doğrulama dosyası sunarken edge önbelleğini göz önünde bulundurun; gerekirse DNS doğrulamasına geçmek daha az sürtünmeli olabilir. Aynı sertifikayı birden fazla makinede kullanıyorsanız dağıtımı ve yenileme tarihini merkezi takip edin.
Wildcard DV
*.alanadiniz.com genelde bir alt seviye alt alan adlarını kapsar; kök (apex) çoğu üründe ayrı sertifika veya SAN gerektirir. *.*.a.b gibi ikinci seviye wildcard’lar yaygın değildir; ürün sayfasındaki kapsamı mutlaka okuyun.
Tek alan ve SAN (UCC)
Birden fazla tam nitelikli alan adını tek sertifikada toplar; wildcard’a gerek yoksa maliyet ve denetim açısından sık tercih edilir. Liste dolduğunda yeniden sipariş veya yükseltme gerekebilir; baştan hostname envanterinizi netleştirin.
Bu gruptan “daha iyisi” ne zaman OV/EV olur?
İş ortağı sözleşmesi, banka entegrasyonu, kamu ihale şartnamesi veya müşteri portalında şirket adının sertifikada doğrulanmış görünmesi isteniyorsa OV veya EV düşünün. Yalnızca HTTPS ve performans odaklıysanız DV yeterlidir.
Sıkça sorulan sorular (DV SSL)
DV (Domain Validation), sertifika otoritesinin yalnızca alan adı üzerinde kontrolünüzü kanıtlamanızı istediği sertifika türüdür; şirket evrakı veya telefon doğrulaması istenmez. Web siteniz, API’niz, paneliniz veya e‑ticaret ödeme sayfanız için standart HTTPS ihtiyacınız varsa ve sözleşme/banka şartnamesi “kurum adının sertifikada görünmesi” gibi bir zorunluluk getirmiyorsa DV genelde en hızlı ve maliyet açısından verimli başlangıçtır. Şifrelemenin “gücü” DV/OV/EV arasında aynı TLS protokolüyle aynı potansiyelde kurulur; fark, kimlik doğrulama derinliği ve bazı arayüzlerde gösterilen kurumsal bilgidir.
Doğrulama yöntemi ve DNS kayıtları hazırsa birçok DV ürünü dakikalar ila birkaç saat içinde yayınlanır. Gecikme çoğunlukla şu noktalardan gelir: yanlış DNS bölgesi (child zone), TTL nedeniyle yavaş yayılan TXT/CNAME, CDN veya WAF’ın doğrulama dosyasını önbelleğe alması, e‑posta doğrulamasında yetkili kutuya erişim gecikmesi. Sipariş öncesi hangi hostname’leri kapsayacağınızı netleştirip doğrulama yöntemini buna göre seçmek süreyi kısaltır.
DV’de genellikle şirket belgesi istenmez; amaç alan adı kontrolünü kanıtlamaktır. Yaygın DCV yöntemleri: yetkili bir adrese gelen doğrulama bağlantısı, belirtilen URL’de HTTP(S) dosyası barındırma ve DNS’e TXT/CNAME ekleme. E‑posta hızlı olabilir ancak kutuya erişim ve filtreler risk taşır; HTTP dosyası panel üzerinden kolaydır fakat CDN/proxy arkasında dikkat ister; DNS, altyapı karmaşıksa biraz daha “kurulum” ister ama edge önbelleği sorunlarını sık sık bertaraf eder. Birden fazla yöntem sunuluyorsa altyapınıza en az sürtünen yolu seçin.
OV ve EV, şirket bilgisinin otorite tarafından da kontrol edildiği seviyelerdir; müşteri sözleşmesi, banka/BKM entegrasyon şartı, ihale dokümanı veya kurumsal portalda doğrulanmış organizasyon adı talebi varsa OV/EV mantıklıdır. “Sadece DV” risk değil, yanlış beklenti riskidir: DV, sitenin “meşru işletme” olduğunu kanıtlamaz; yalnızca o hostname için TLS sunabilirsiniz. Yanlış ürün beklentisi yoksa çoğu web uygulaması için DV teknik olarak yeterlidir.
Arama motorları açısından asıl sinyal HTTPS’in doğru kurulması, karışık içerik (mixed content) olmaması ve yönlendirmelerin tutarlı olmasıdır. DV/OV/EV ayrımı “hangi TLS sınıfı daha üst sıra getirir” şeklinde net bir ayrıştırma sunmaz; fark çoğunlukla kullanıcı güveni ve kurumsal gerekliliklerdedir. SEO hedefiniz varsa önceliğiniz sertifika sınıfından çok tam zincir (intermediate), doğru hostname kapsamı ve süresi dolmayan sertifikadır.
Apex (kök / naked) dendiğinde kastedilen, alt alan adı öneki olmayan adrestir: örneğin
ornek.com. Buna karşılık www.ornek.com, api.ornek.com gibi adresler alt alan adıdır. Wildcard DV sertifikaları tipik olarak *.ornek.com desenini kapsar; bu desen ornek.com kökünü kapsamaz (yıldız bir seviye için geçerlidir ve kökü “alt alan” saymaz). Bu yüzden çoğu senaryoda kök ile birlikte wildcard istiyorsanız SAN’da kökü eklemeniz, ayrı bir sertifika almanız veya kök+www’yi açıkça listeleyen bir ürün seçmeniz gerekir. Sipariş öncesi ürün sayfasındaki kapsamı mutlaka doğrulayın.SAN (Subject Alternative Name), aynı sertifikada birden fazla tam nitelikli hostname’i listeler; farklı kök alanlar veya
www + api + checkout gibi sabit bir envanter için uygundur. Wildcard, tek desenle çok sayıda tek seviyeli alt alanı kapsar; dinamik alt alan üretiyorsanız pratik olabilir. Maliyet, yenileme disiplini ve “hangi isimlerin gerçekten trafik aldığı” envanterine göre seçim yapın; ürün bazında SAN slot sınırı ve wildcard kuralları değişebilir.İkisi de trafik alıyorsa çoğu üründe ikisini de SAN listesine eklemeniz gerekir; yalnızca birini yazmak diğerinde uyarı üretir. Yönlendirme stratejinizi (kökten www’ye veya tersi) netleştirip sertifikada kapsadığınız hostname’lerle hizalayın; böylece hem doğrulama hem de kullanıcı deneyimi tutarlı olur.
CSR, sunucuda ürettiğiniz talebin metnidir; içindeki isimler siparişteki hostname’lerle birebir uyumlu olmalıdır. Özel anahtar asla paylaşılmamalı, sürüm konteline konmamalı ve yedekleri şifreli tutulmalıdır; sızdırılırsa sertifikayı iptal edip yeniden üretmek gerekir. RSA 2048+ veya ECDSA gibi güncel algoritma seçimini ürün ve sunucu desteğine göre yapın; yanlış CN/SAN ile üretilmiş CSR, yayın sonrası isim uyumsuzluğu hatasına yol açar.
Tarayıcı uyarılarının sık nedenleri: ara sertifika (intermediate) zincirinin eksik servis edilmesi, yanlış sanal host’a sertifika bağlanması, süresi dolmuş veya henüz geçerli olmayan sertifika ve URL’deki hostname’in sertifikadaki listede olmaması. Test için mobil ve masaüstü farklı ağlardan kontrol edin; CDN kullanıyorsanız edge sertifikası ile origin sertifikasını karıştırmayın. Sorun giderme adımı olarak önce zinciri ve hostname eşleşmesini doğrulamak en hızlı yoldur.
HTTP dosyası doğrulamasında token’ın doğru origin’de ve doğru path’te görünmesi gerekir; CDN önbelleği bazen eski içerik veya 301 döngüsü üretir. Çözüm olarak kısa süreli cache bypass kuralı, doğrulama path’ini önbellek dışı bırakma veya doğrudan DNS doğrulamasına geçiş sık kullanılır. Birden fazla edge varsa yayılımı ve yönlendirme kurallarını göz önünde bulundurun.
Çoğu DV sürecinde yenilemede alan adı doğrulaması yeniden istenir; bu normaldir. Anahtar sızdıysa veya sunucu değiştiyse reissue talep edebilirsiniz; ücretsiz reissue penceresi ve kota ürün/CA politikasına göre değişir. Takvim uyarıları ve otomasyon (API, panel entegrasyonu) ile süresi dolmayı beklemeden hareket etmek kesinti riskini azaltır.
TLS, iletişimi şifreler; kullanıcıya “bu sitenin iyi niyetli bir marka olduğu” garantisi vermez. Kötü niyetli bir site de alan adı kontrolünü geçerek DV alabilir; bu yüzden marka koruması, e‑posta güvenliği (SPF/DKIM/DMARC), tarayıcı güvenliği ve kullanıcı eğitimi ayrı katmanlardır. Finans veya hesap işlemleri için DV yeterli olabilir; fakat kimlik güveni mesajı vermek istiyorsanız OV/EV ve süreçlerinizi gözden geçirin.
İkisi de sunucu ve CDN yapılandırması meselesidir; sertifika sınıfından bağımsız olarak performans ve güvenlik sertleştirmesi sağlar. OCSP stapling, sertifika doğrulama isteklerini hafifletir; HSTS, downgrade saldırılarını zorlaştırır. Üretim ortamında özellikle HSTS’yi kademeli ve test ederek açın; yanlış yapılandırma erişim kilitlerine yol açabilir.
Güven kökü tarayıcı güven deposunda bulunan bir otoriteden gelen standart DV sertifikaları modern tarayıcılarda geniş uyumluluk sunar. Mobil uygulamalarda ek kısıtlar (sertifika sabitleme / pinning) veya eski istemci kitlesi varsa algoritma ve zincir seçimini test edin. Özetle: doğru zincir, güncel protokol ve doğru hostname kapsamı “çalışır” deneyimin omurgasıdır.