Tecof • 14 Eylül 2026
SSL Sertifikası Nedir? E-ticaret Güvenliği İçin Neden Şart?
Kısaca
SSL sertifikası, bir alan adının gerçekten iddia ettiği kişiye ait olduğunu üçüncü bir tarafın onayladığı dijital bir kimlik dosyasıdır; tarayıcı ile sunucu arasındaki trafiği şifreleyen TLS protokolünü başlatan anahtardır. Teknik olarak "SSL" adı 2015'te emekli oldu, bugün kullanılan protokolün adı TLS; ama sektör alışkanlığı sertifikaya hâlâ SSL sertifikası diyor. E-ticaret tarafında ise mesele artık şifrelemenin ötesinde: sanal POS başvurunuz, Google sıralamanız, KVKK uyumunuz ve müşterinin sepeti terk edip etmemesi aynı sertifikaya bağlı. 2026 itibarıyla soru "sitemde SSL olmalı mı" değil, "sertifika zincirim, yenilenmem ve izlemem bir gece yarısı çöktüğünde bunu kaç dakikada fark ediyorum" sorusudur.
Salı sabah 09.15. Ev tekstili satan orta ölçekli bir mağazanın Google Analytics ekranında dün aynı saatte 340 olan oturum sayısı 41 görünüyor. Reklam harcaması duruyor, kampanya aktif, stok yerinde. Müşteri hizmetlerine sabah 08.40'tan beri gelen on dört mesajın on ikisinde aynı ekran görüntüsü var: "Bağlantınız gizli değil — NET::ERR_CERT_DATE_INVALID". Sertifika o gece 03.00'te süresi dolarak devre dışı kalmış. Otomatik yenileme altı ay önce, sunucu taşınırken cron görevi taşınmadığı için sessizce durmuş; kimse fark etmemiş çünkü sertifika o sırada hâlâ geçerliydi. Sorunun çözümü 45 dakika sürdü. Kayıp, o günkü ciro ortalaması 118.000 TL olan bir mağaza için yaklaşık 34.000 TL, artı Google Ads'te boşa giden 4.200 TL'lik tıklama, artı üç gün boyunca düşen dönüşüm oranı. Teknik iş yükü: bir komut. Maliyet: bir haftalık kâr.
Sorun sertifika değil. Sorun, sertifikanın görünmez bir altyapı parçası olarak kabul edilip hiçbir panele, hiçbir uyarı kanalına, hiçbir kontrol listesine bağlanmamış olması. E-ticarette çöken şeylerin çoğu gürültüyle çöker; SSL sessizce çöker ve sadece müşteri görür.
SSL, TLS ve HTTPS aslında ne yapıyor
Üç işi aynı anda yapan tek dosya
Sertifikanın üç ayrı görevi var ve çoğu işletme sahibi bunlardan sadece birini biliyor.
- Şifreleme: Müşterinin girdiği kart numarası, adres ve parola, araya giren kimse tarafından okunamaz hale gelir. Kafedeki ortak Wi-Fi'de oturan biri trafiği yakalasa bile anlamsız veri görür.
- Kimlik doğrulama: tecof.com adresine bağlandığınızda gerçekten tecof.com'un sunucusuna bağlandığınızı, araya giren sahte bir sunucuya değil, sertifika otoritesinin imzası garanti eder. Şifreleme olmadan kimlik doğrulama işe yaramaz, kimlik doğrulama olmadan şifreleme de yaramaz.
- Bütünlük: Gönderilen veri yolda değiştirilirse tarayıcı bunu anlar. Operatör seviyesinde sayfaya reklam enjekte edilmesi ya da ödeme formundaki hesap numarasının değiştirilmesi engellenir.
Handshake: 200 milisaniyede ne oluyor
Müşteri adres çubuğuna sitenizi yazdığında sıra şöyle işliyor. Tarayıcı sunucuya bağlanır ve desteklediği şifreleme yöntemlerini bildirir. Sunucu bir yöntem seçer ve sertifikasını gönderir. Tarayıcı sertifikayı üç açıdan kontrol eder: imzalayan otorite kendi güvenilir kök listesinde var mı, sertifikanın tarihi geçerli mi, sertifikadaki alan adı adres çubuğundaki adresle eşleşiyor mu. Üçü de tamamsa taraflar ortak bir oturum anahtarı üretir ve asıl veri alışverişi o anahtarla şifreli devam eder. TLS 1.3'te bu tur sayısı bire indiği için el sıkışma tipik olarak 100-200 milisaniye sürüyor; TLS 1.2'de iki tur gerektiğinden bu süre iki katına çıkabiliyor.
Zincir, ara sertifika ve en sık atlanan hata
Sertifikanız tek başına çalışmaz. Kök otorite, ara otoriteyi imzalar; ara otorite sizin sertifikanızı imzalar. Sunucunuzun tarayıcıya sadece kendi sertifikasını değil, ara sertifikayı da göndermesi gerekir. Masaüstü Chrome eksik ara sertifikayı çoğu zaman kendi başına bulup tamamlar, Android'deki uygulama içi tarayıcı bulamaz. Bunun pratik sonucu şu: siz masaüstünden bakıp "çalışıyor" dersiniz, trafiğinizin yüzde 70'ini oluşturan mobil kullanıcı hata ekranı görür. Kurulumdan sonra mutlaka bağımsız bir zincir testi çalıştırın ve mobil cihazdan mobil veriyle açıp doğrulayın.
Sertifika tipleri: hangisi size gerçekten lazım
DV, OV ve EV arasındaki gerçek fark
Üç doğrulama seviyesi var ve aralarındaki fark şifreleme gücü değil — şifreleme üçünde de aynı. Fark, otoritenin sizi ne kadar araştırdığı.
| Tip | Neyi doğrular | Süre | Yıllık maliyet | Kime uygun |
|---|---|---|---|---|
| DV (Domain Validation) | Sadece alan adının kontrolü sizde mi | 2-10 dakika | 0-400 TL | Blog, kurumsal site, küçük mağaza |
| OV (Organization Validation) | Alan adı + şirketin ticaret sicilde kayıtlı varlığı | 1-3 iş günü | 1.500-4.000 TL | Kurumsal müşteriye satan B2B mağaza |
| EV (Extended Validation) | Alan adı + şirket + fiziksel adres + imza yetkisi | 3-10 iş günü | 4.000-12.000 TL | Finans, sigorta, yüksek sepet tutarı |
| Wildcard | *.siteniz.com — tüm birinci seviye alt alan adları | DV'de dakikalar | 0-6.000 TL | blog, api, panel gibi çok alt alan adı |
| Multi-domain (SAN) | Tek sertifikada 3-100 farklı alan adı | Tipe göre | 1.000-15.000 TL | .com.tr + .com + kampanya alan adları |
EV sertifikanın eski satış argümanı adres çubuğunda görünen yeşil şirket adıydı. Chrome 2019'da, Firefox da aynı dönemde bu göstergeyi kaldırdı. Yani müşteriniz EV ile DV arasındaki farkı tarayıcıda artık göremiyor. EV'yi bugün almanın tek rasyonel gerekçesi, sizden bunu sözleşmeyle talep eden kurumsal bir alıcı ya da denetçi olması. Ortalama sepet tutarı 800 TL olan bir mağazada EV, dönüşüme ölçülebilir hiçbir katkı yapmaz.
Wildcard mı, SAN mı, ayrı ayrı mı
Alt alan adı sayınız üçü geçiyorsa wildcard yönetim yükünüzü ciddi biçimde azaltır: tek yenileme, tek dosya. Ama wildcard'ın bir riski var — özel anahtar sızarsa tüm alt alan adlarınız aynı anda etkilenir. Ödeme, panel ve API gibi kritik alt alan adlarını wildcard'ın dışında, kendi sertifikalarıyla tutmak yaygın ve sağlıklı bir yaklaşım. Farklı uzantılarda alan adınız varsa (siteniz.com ve siteniz.com.tr) multi-domain sertifika tek yenileme takvimi sağlar; ancak Let's Encrypt ile her birine ayrı ücretsiz sertifika almak da tamamen geçerli ve daha esnek bir yol.
Let's Encrypt ücretli sertifikaya karşı
| Kriter | Let's Encrypt (ücretsiz) | Ücretli DV | Ücretli OV/EV |
|---|---|---|---|
| Şifreleme gücü | Aynı | Aynı | Aynı |
| Tarayıcı güveni | Tam | Tam | Tam |
| Geçerlilik süresi | 90 gün (otomatik yenilemeli) | 398 güne kadar | 398 güne kadar |
| Destek | Topluluk forumu | Telefon/ticket, 24 saat | Öncelikli, 4 saat |
| Garanti / sigorta | Yok | 10.000-250.000 USD | 1-2 milyon USD |
| Sanal POS başvurusunda kabul | Evet | Evet | Evet |
Karar kuralı basit: kurumsal bir sözleşme, banka ya da denetçi sizden özellikle OV/EV istemiyorsa Let's Encrypt yeterlidir ve Türkiye'deki mağazaların büyük çoğunluğu için doğru seçimdir. Tek şartı, 90 günlük süreyi otomatik yenilemeye bağlamanız. Bunu elle yapmayı planlıyorsanız ücretli ve 398 günlük bir sertifika alın — çünkü elle yenileme, yılda dört kez unutma fırsatı demektir. Modern altyapılarda bu iş zaten platform tarafında hallediliyor; altyapı seçerken yapılan hatalar yazısında değindiğimiz gibi, sertifika yönetiminin kimin sorumluluğunda olduğunu sözleşme aşamasında netleştirmek gerekiyor.
E-ticarette SSL neden pazarlık konusu değil
Sanal POS: bankanın ilk baktığı şey
Türkiye'de sanal POS başvurusu yaptığınızda banka ya da ödeme kuruluşu sitenizi manuel olarak inceler. Kontrol listesinin ilk maddelerinden biri geçerli HTTPS'tir; ikincisi ödeme sayfasının da HTTPS olması, üçüncüsü mesafeli satış sözleşmesi, ön bilgilendirme formu, iade ve teslimat koşulları sayfalarının erişilebilir olmasıdır. Bu sayfaların HTTP üzerinden açılması ya da karışık içerik uyarısı vermesi başvuru reddine yol açabiliyor. ETBIS kaydınızın doğrulanması sırasında da site erişilebilirliği kontrol ediliyor. Sertifikası düşmüş bir sitede hem başvuru hem doğrulama takılır.
PCI DSS ve kart verisi
Kart bilgisi doğrudan sizin sunucunuzdan geçmiyor, ödeme kuruluşunun iframe'i ya da yönlendirmesi üzerinden ilerliyor olabilir — çoğu Türk mağazası böyle çalışıyor. Bu sizi PCI DSS kapsamından tamamen çıkarmaz. SAQ A formunda bile, ödeme sayfasını barındıran sitenin TLS ile korunması ve zayıf protokollerin (SSL 3.0, TLS 1.0, TLS 1.1) kapalı olması bekleniyor. Sunucunuzda hâlâ TLS 1.0 açıksa bu bir uyum bulgusudur ve yıllık taramada karşınıza çıkar.
Tarayıcı uyarısı, KVKK ve arama sıralaması
Chrome, HTTPS olmayan sayfalardaki parola ve kart alanlarına "Güvenli değil" etiketi koyuyor; sertifikası geçersizse tam sayfa bir uyarı ekranı gösteriyor ve devam etmek için iki tık gerekiyor. Bu ekranı gören ziyaretçilerin büyük bölümü geri dönüyor. KVKK tarafında ise Kişisel Verileri Koruma Kurumu'nun teknik tedbirler rehberinde veri aktarımının şifrelenmesi açıkça sayılıyor; ad, adres, telefon ve sipariş geçmişi kişisel veri olduğu için üye kaydı alan her mağaza bu kapsamda. Google'ın HTTPS'i sıralama sinyali olarak kullandığını 2014'ten beri açıkça söylediğini de ekleyin: tek başına belirleyici değil ama eşitlik bozan bir faktör. Hız, güven ve teknik sağlık birlikte çalışıyor; dönüşüm oranını artırma tarafında yaptığınız her iyileştirme, ziyaretçi ilk saniyede uyarı ekranı görüyorsa anlamını yitiriyor.
Kurulumdan sonra karşınıza çıkacak dört sorun
Mixed content: yeşil kilidi öldüren şey
Sayfanız HTTPS ile açılıyor ama içindeki bir görsel, bir font ya da bir script HTTP adresinden çağrılıyorsa tarayıcı kilidi kaldırır. Script ve stil dosyaları gibi aktif içerikler zaten baştan bloklanır; sonuç genelde bozuk görünen bir sayfa ya da çalışmayan bir sepet butonudur. En sık kaynaklar: veritabanındaki eski ürün açıklamalarına gömülü http:// görselleri, tema dosyalarındaki sabit adresler, eski reklam ve chat kodları. Çözüm sırası şu: veritabanında http://siteniz.com ifadesini https:// ile toplu değiştirin, tema ve widget kodlarını tarayın, sonra tarayıcı konsolunda kalan uyarıları tek tek kapatın. Üçüncü parti bir servis hâlâ sadece HTTP sunuyorsa o servisi değiştirmek gerekir.
HSTS: iki ucu keskin bıçak
HSTS, tarayıcıya "bu alan adını bundan sonra sadece HTTPS ile aç" talimatı veren bir başlıktır. SSL stripping saldırılarını engeller ve ilk yönlendirmeyi ortadan kaldırdığı için sayfayı bir miktar hızlandırır. Riski şu: max-age süresi boyunca tarayıcı sizi HTTP'den açmayı reddeder. Sertifikanız bozulursa "geçici olarak HTTP'ye düşelim" seçeneğiniz kalmaz. Bu yüzden kademeli gidin: önce 300 saniye, bir hafta sorunsuz çalışırsa 86400, bir ay sonra 31536000. includeSubDomains ve preload direktiflerini ise tüm alt alan adlarınızın HTTPS'te olduğundan emin olmadan eklemeyin; preload listesinden çıkmak aylar sürebiliyor.
Yenileme ve süre dolması
Sertifika ömürleri kısalıyor. 2015'te üç yıl olan üst sınır 2020'de 398 güne indi ve sektör 2029'a kadar kademeli olarak 47 güne inecek bir takvim üzerinde anlaştı. Bunun anlamı net: elle yenileme bir strateji olmaktan çıkıyor, otomasyon zorunlu hale geliyor. Otomatik yenilemeniz varsa bile şu üç şeyi doğrulayın — yenileme görevi sunucu taşımalarında da kopyalanıyor mu, yenileme sonrası web sunucusu gerçekten yeniden yükleniyor mu, ve yenileme başarısız olduğunda kime e-posta gidiyor. Üçüncüsü genelde eksiktir ve baştaki sahnedeki mağazanın başına gelen tam olarak budur.
Alan adı taşırken SSL
Alan adını başka bir sağlayıcıya ya da siteyi yeni bir sunucuya taşırken sertifika kendiliğinden gelmez. Sağlıklı sıra: yeni sunucuda siteyi ayağa kaldırın, DNS'i değiştirmeden önce sertifikayı orada oluşturun (Let's Encrypt'te DNS doğrulama yöntemi bunu mümkün kılar), sonra TTL değerini 300 saniyeye düşürüp DNS kaydını değiştirin. Ters sırada yaparsanız DNS yayılırken ziyaretçilerin bir kısmı sertifikasız sunucuya düşer. Taşımadan sonra eski sunucudaki yönlendirmeleri en az 30 gün açık tutun ve www ile www'suz sürümün ikisinin de sertifikada yer aldığını kontrol edin.
Hata kodlarını okumak ve izleme kurmak
NET::ERR_CERT_* ailesi
| Hata kodu | Gerçek anlamı | İlk yapılacak | Tipik süre |
|---|---|---|---|
| ERR_CERT_DATE_INVALID | Sertifika süresi doldu ya da sunucu saati yanlış | Yenilemeyi elle tetikle, sunucu saatini kontrol et | 5-45 dakika |
| ERR_CERT_COMMON_NAME_INVALID | Sertifikadaki alan adı adresle eşleşmiyor (genelde www eksik) | Sertifikayı her iki adı içerecek şekilde yeniden üret | 15-60 dakika |
| ERR_CERT_AUTHORITY_INVALID | Ara sertifika eksik ya da kendinden imzalı sertifika | Tam zinciri sunucuya yükle | 20-60 dakika |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Sunucu çok eski ya da çok kısıtlı protokol sunuyor | TLS 1.2 ve 1.3'ü aç, eski şifre setlerini kapat | 30-90 dakika |
| ERR_CERT_REVOKED | Sertifika otorite tarafından iptal edildi | Anahtar sızıntısını araştır, yeni anahtarla yeni sertifika al | 2-8 saat |
Üç katmanlı izleme
Bir sertifikanın sessizce ölmesini engellemenin yolu, aynı bilgiyi birbirinden bağımsız üç yerden almaktır.
| Katman | Ne izler | Sıklık | Uyarı eşiği | Kime gider |
|---|---|---|---|---|
| Harici kontrol | Sertifika bitiş tarihi ve zincir | Günde 1 | 30, 14, 7 ve 2 gün kala | E-posta + ekip kanalı |
| Erişilebilirlik | Ana sayfa, kategori, sepet, ödeme HTTP kodu | 5 dakikada 1 | Ardışık 2 başarısızlık | SMS + telefon |
| Sunucu içi | Yenileme görevi çalıştı mı | Her çalıştırmada | Hata çıktısı | Teknik sorumlu e-postası |
| Tarayıcı gerçek kullanıcı | Mobil cihazlarda zincir hatası | Haftada 1 manuel | Tek hata bile | Kontrol listesi |
Uyarı e-postasının gittiği adres, ayrılan bir çalışanın kurumsal hesabı olmasın. Bu, sahada gördüğümüz en sık kök sebeplerden biri. Uyarıları bir ekip kanalına ve en az iki kişiye yönlendirin. Otomatik kontrollerin sipariş, stok ve entegrasyon tarafındaki karşılığı için API ve entegrasyon yazımıza bakabilirsiniz; aynı mantık orada da geçerli: sessiz hata en pahalı hatadır.
Teşhis için elinizin altında olması gerekenler
- openssl s_client: Sunucunun gönderdiği tam zinciri ve bitiş tarihini komut satırından gösterir. Tarayıcının tamamladığı eksikleri gizlemez.
- Harici zincir testi: Bağımsız bir sunucudan bakar; sizin ağınızdaki önbellek yanılgılarını ortadan kaldırır.
- Mobil veriyle gerçek cihaz testi: Wi-Fi'siz, uygulama içi tarayıcıyla açın. Zincir eksikliği en net burada görünür.
- Certificate Transparency kaydı: Alan adınıza kimin sertifika ürettiğini herkese açık kayıtlardan izleyebilirsiniz. İzinsiz sertifika üretimini fark etmenin tek yolu budur.
30 Günde Sağlam Bir HTTPS Kurulumu
1-7. gün: envanter ve mevcut durum
Sahip olduğunuz tüm alan adlarını ve alt alan adlarını tek bir tabloya yazın: ana site, www, blog, panel, api, kampanya adresleri, eski kampanya adresleri. Her biri için mevcut sertifikanın bitiş tarihini, tipini ve kimin yönettiğini not edin. Ardından tüm siteyi tarayarak HTTP üzerinden çağrılan kaynakların listesini çıkarın. Bu hafta tek bir ayar değiştirmeyin; sadece ne olduğunu görün. Çoğu ekip bu adımda unuttuğu iki üç alt alan adı bulur.
8-14. gün: kurulum ve karışık içerik temizliği
Eksik olan yerlere sertifika kurun. Veritabanındaki http:// bağlantılarını toplu güncelleyin, tema ve üçüncü parti kodları düzeltin. HTTP'den HTTPS'e 301 yönlendirmesini tek adımda yapın — http://site, https://www.site'ye iki zıplamayla değil tek zıplamayla gitsin. Ardından ana sayfa, üç kategori, üç ürün, sepet, ödeme ve mesafeli satış sözleşmesi sayfalarını tarayıcı konsolu açık şekilde tek tek gezin. Konsolda tek bir karışık içerik uyarısı kalmayana kadar durmayın.
15-21. gün: otomasyon ve sertleştirme
Yenilemeyi otomatikleştirin ve bir kez zorla çalıştırıp gerçekten yenilendiğini doğrulayın. Yenileme sonrası web sunucusunun yeniden yüklendiğinden emin olun. TLS 1.0 ve 1.1'i kapatın, 1.2 ve 1.3'ü açık bırakın. HSTS'i 300 saniyelik max-age ile başlatın. Sunucu saatini NTP ile senkronize edin — ERR_CERT_DATE_INVALID hatalarının azımsanmayacak bölümü yanlış sunucu saatinden kaynaklanıyor.
22-30. gün: izleme, tatbikat ve dokümantasyon
Üç katmanlı izlemeyi kurun ve uyarıların gerçekten geldiğini test edin: bir test alan adında sertifikayı bilerek bozun, uyarının kaç dakikada geldiğini ölçün. HSTS max-age değerini bir yıla çıkarın. Son olarak tek sayfalık bir çalışma notu yazın: alan adları listesi, sertifika tipleri, yenileme yöntemi, uyarıların gittiği adresler, sorun anında aranacak kişi ve beş satırlık müdahale adımı. Bu notu ekipteki en az iki kişinin erişebileceği bir yerde tutun.
Yarın sabah yapabileceğiniz iş şu: tarayıcıda kendi sitenizi açıp adres çubuğundaki kilide tıklayın, sertifikanın bitiş tarihini not edin, sonra telefonunuzun mobil verisiyle aynı sayfayı bir kez daha açın. Bitiş tarihine 30 günden az kaldıysa ya da mobilde masaüstünde olmayan bir uyarı çıktıysa, bugün çözülecek bir işiniz var demektir. Sertifika yönetiminin platform tarafında otomatik olarak yürüdüğü bir yapıya geçmeyi düşünüyorsanız Tecof e-ticaret altyapısı sayfasında bu kısmın nasıl çalıştığını görebilirsiniz; ama hangi altyapıyı kullanırsanız kullanın, sabah yapılacak o iki dakikalık kontrol sizin sorumluluğunuzda kalıyor.
Sıkça Sorulan Sorular
Ücretsiz SSL sertifikası güvenli mi?
Evet. Let's Encrypt sertifikası ile 8.000 TL'lik bir sertifikanın sağladığı şifreleme birebir aynıdır; ikisi de aynı TLS protokolünü ve aynı anahtar uzunluklarını kullanır. Fark, sertifika otoritesinin sizi ne kadar araştırdığı, verdiği destek ve sigorta teminatıdır. Ödeme kuruluşları ve bankalar Let's Encrypt'i kabul ediyor. Tek gerçek farkı, 90 günlük geçerlilik süresinin otomatik yenilemeye bağlanmasını zorunlu kılmasıdır.
SSL sertifikası sitemi yavaşlatır mı?
Ölçülebilir şekilde hayır. TLS 1.3 ile el sıkışma tek turda tamamlanıyor ve modern işlemcilerde şifreleme maliyeti ihmal edilebilir düzeyde. Üstelik HTTP/2 ve HTTP/3 yalnızca HTTPS üzerinde çalıştığı için, HTTPS'e geçmek genellikle siteyi yavaşlatmak yerine hızlandırır. Yavaşlık yaşıyorsanız sebebi sertifika değil, muhtemelen yönlendirme zincirleri, optimize edilmemiş görseller veya sunucu yanıt süresidir.
Sertifikam bitti, kaç dakikada geri açarım?
Otomatik yenileme kuruluysa ve sadece görev takılmışsa yenilemeyi elle tetiklemek ve web sunucusunu yeniden yüklemek 5-15 dakika sürer. Sıfırdan yeni sertifika üretmeniz gerekiyorsa DV için 20-45 dakika hesaplayın. Bu sürede sitenizi kapatmayın; kapalı site en azından hata mesajı vermez ama arama motoru tarafında farklı bir sorun yaratır. En hızlı yol, sorunu doğrudan çözmektir.
Tüm sayfalarda HTTPS gerekli mi, yoksa sadece ödeme sayfasında mı yeter?
Tüm sayfalarda gerekli. Sadece ödeme sayfasını şifrelemek 2010'ların yaklaşımıydı ve artık işe yaramıyor: oturum çerezi HTTP sayfalarda açıkta gider, tarayıcı diğer sayfalarda "Güvenli değil" etiketi gösterir ve karışık içerik sorunları ortaya çıkar. Google da karma yapıları indekslerken sorun çıkarıyor. Site geneli HTTPS tek doğru kurulumdur.
Wildcard sertifika mı, her alt alan adına ayrı sertifika mı?
Üçten fazla alt alan adınız varsa wildcard yönetimi belirgin şekilde kolaylaştırır. Ancak ödeme, yönetim paneli ve API gibi kritik alt alan adlarını wildcard'ın dışında tutup kendi sertifikalarını vermek daha güvenli bir düzendir; çünkü wildcard'ın özel anahtarı sızarsa tüm alt alan adları aynı anda risk altına girer. Küçük yapılarda her alt alan adına ayrı ücretsiz sertifika vermek de tamamen makul.
HSTS'i hemen açmalı mıyım?
Hemen değil, kademeli olarak. Önce tüm site ve alt alan adlarınızın HTTPS üzerinden sorunsuz çalıştığından emin olun. Sonra max-age değerini 300 saniye ile başlatın, bir hafta sorun çıkmazsa bir güne, bir ay sonra bir yıla çıkarın. includeSubDomains ve preload direktiflerini en sona bırakın, çünkü preload listesine girdikten sonra çıkmak aylar sürebiliyor ve bu süre boyunca HTTP'ye düşme seçeneğiniz kalmıyor.
Alan adımı taşırsam sertifikam ne olur?
Sertifika alan adına bağlıdır, sunucuya değil; yani aynı alan adını taşıyorsanız sertifikayı yeni sunucuya kopyalayabilir ya da orada yenisini üretebilirsiniz. Doğru sıra, DNS'i değiştirmeden önce yeni sunucuda sertifikayı hazır etmektir. Aksi halde DNS yayılımı sırasında ziyaretçilerin bir kısmı sertifikası olmayan sunucuya düşer ve hata ekranı görür. TTL değerini taşımadan 24 saat önce 300 saniyeye düşürmek geçişi kısaltır.
Sanal POS başvurumda SSL dışında neye bakılıyor?
Bankalar ve ödeme kuruluşları geçerli HTTPS'in yanında mesafeli satış sözleşmesi, ön bilgilendirme formu, iade ve teslimat koşulları, gizlilik politikası ve iletişim bilgileri sayfalarının erişilebilir olmasını istiyor. Ürün fiyatlarının KDV dahil görünmesi, ETBIS kaydınızın tamam olması ve şirket unvanının sitede yer alması da kontrol ediliyor. Bu sayfaların HTTP üzerinden açılması ya da karışık içerik uyarısı vermesi başvuruyu geciktirebiliyor.
KVKK açısından SSL zorunlu mu?
KVKK metninde "SSL kurun" diyen bir madde yok; kanun veri sorumlusundan uygun teknik ve idari tedbirleri almasını istiyor. Kurumun yayımladığı teknik tedbirler rehberinde ise veri aktarımının şifrelenmesi açıkça yer alıyor. Ad, adres, telefon ve sipariş geçmişi kişisel veri olduğundan, üyelik ve sipariş alan her mağaza için HTTPS pratikte beklenen asgari tedbirdir. Şifresiz aktarım, bir veri ihlali durumunda aleyhinize yorumlanır.
Sertifikam geçerli ama tarayıcı yine de kilidi göstermiyor, neden?
Neredeyse her zaman karışık içerik sorunudur. Sayfanızdaki bir görsel, font, script ya da iframe HTTP adresinden yükleniyordur. Tarayıcı konsolunu açıp "mixed content" uyarılarına bakın; kaynağı genellikle veritabanına gömülü eski görsel adresleri, tema dosyasındaki sabit bağlantılar ya da eski bir chat veya reklam kodudur. Hepsini HTTPS'e çevirdiğinizde kilit geri gelir.