Epin Satış Panelinde SSL Sertifikası Kurulumunu Yarım Bıraktığın İçin Ödemelerin Sessizce Düşüyor: Kimsenin Anlatmadığı Kurulum Zinciri

Çoğu kişi SSL'i tek satırlık bir iş sanır: hosting panelinden ücretsiz sertifikayı tıkla, adres çubuğunda kilit çıksın, konu kapansın. E-pin satan bir işletme sahibiyseniz bu inancın size kaç para kaybettirdiğini muhtemelen hiç ölçmediniz. Çünkü SSL'in yarım kurulumu hata mesajı vermez; sadece bazı ödemeler tamamlanmaz, bazı webhook'lar düşer, bazı müşteriler mobil tarayıcıda uyarı görüp geri döner. Sistem çalışıyor gibi görünür, ciro ise sebepsizce dalgalanır.

Gerçek şu: bir e-pin satış scripti kurulduğu anda üç ayrı yerde şifreli bağlantıya bağımlı hale gelir; müşteri tarayıcısı, ödeme sağlayıcısının sunucudan sunucuya çağrısı ve bayi/tedarikçi API'sinin senin panele bıraktığı yanıt. Bunlardan sadece birincisi adres çubuğunda görünür. Diğer ikisi görünmez ve tam da bu yüzden aylarca fark edilmeden bozuk kalır. Bu yazıda kilit ikonunun arkasındaki kurulum zincirini, sırasıyla ve neden o sırada olduğunu anlatarak açıyoruz.

Kilit ikonu çıktı diye kurulum bitmiş mi sayılır?

Hayır, ve bu yanılgı en pahalı olanıdır. Adres çubuğundaki kilit yalnızca şunu söyler: senin tarayıcın ile sunucu arasındaki bu tek istek şifrelendi. Sertifika zincirinin eksik olması, ara sertifikanın (intermediate) sunucuya yüklenmemiş olması, masaüstü Chrome'da hiçbir şey göstermez; çünkü masaüstü tarayıcılar eksik ara sertifikayı kendi önbelleğinden tamamlar. Ama ödeme sağlayıcısının sunucusu, tedarikçi API'sinin cURL istemcisi ve bazı Android WebView'ları bunu tamamlamaz. Sonuç: müşteri sitede kilidi görür, ama sağlayıcının panele gönderdiği ödeme bildirimi sessizce reddedilir ve sipariş "beklemede" kalır.

Kurulumu bitmiş saymanın tek ölçüsü şudur: sunucunun sunduğu sertifika zinciri, üçüncü taraf bir istemci tarafından doğrulanabiliyor mu? Bunu tarayıcıyla değil, sunucudan sunucuya test ederek anlarsın. Kurulumdan sonra kendi sunucunda basit bir istek çalıştırıp sertifika doğrulama hatası alıp almadığını görmek, kilit ikonuna bakmaktan yüz kat daha bilgilendiricidir. Bir dijital ürün satış yazılımı kurarken bu tek adımı atlamak, ilk hafta içinde "ödeme aldım ama kod gitmedi" tikelerinin ana kaynağı olur.

Sertifika seçerken neye göre karar vermelisin?

E-pin işinde sertifika seçimi teknik bir tercih değil, ticari bir tercihtir. Ücretsiz kısa ömürlü sertifikalar teknik olarak tamamen yeterlidir; şifreleme gücü ticari olanla aynıdır. Fark, yenileme otomasyonunun ne kadar sağlam kurulduğu ve panelin kaç alt alan adına yayıldığıdır. Panel, ana site, API uç noktası ve statik dosya alanını ayrı alt alan adlarında tutuyorsan tek tek sertifika yönetmek yerine joker (wildcard) bir sertifika almak, unutma riskini tek kaleme indirir.

Yenileme otomasyonu neden kurulumun en kritik parçası?

Doksan günlük sertifikanın anlamı şudur: yılda dört kez kapanma riski. Elle yenileme yapmayı planlıyorsan, o günün tam olarak kampanya gününe, bayram yoğunluğuna veya tatilde olduğun haftaya denk gelmesini bekle. Yenileme görevini zamanlanmış bir işe (cron) bağlarken iki ayrı şeyi kurmak gerekir: sertifikayı alan komut ve web sunucusunu yeniden yükleyen komut. İkincisini atlayanlar en sinsi hatayı yaşar; dosyada yeni sertifika durur, sunucu belleğinde eski süresi geçmiş olan servis edilmeye devam eder.

Yenilemeyi kurduktan sonra onu izlemeyi de kurmalısın. Sertifika bitiş tarihini haftada bir kontrol edip kalan gün sayısı yirminin altına düştüğünde sana e-posta veya Telegram mesajı atan on satırlık bir kontrol, panelin en değerli sigortasıdır. Pinova gibi bir e-pin yazılımı kullanıyorsan bu tür altyapı kontrollerini panelin sistem sağlığı ekranında toplamak, üç ayrı yerde tutmaktan çok daha sürdürülebilir.

Mixed content hatası ödemeyi nasıl sessizce düşürür?

Panelin HTTPS üzerinden açılıyor ama içindeki bir görsel, bir yazı tipi ya da bir JavaScript dosyası hâlâ http:// ile çağrılıyorsa tarayıcı o kaynağı engeller. Engellenen kaynak bir dekoratif görselse kimse fark etmez. Engellenen kaynak ödeme formunu çizen betikse müşteri boş bir alan görür, butona basar, hiçbir şey olmaz ve siteden çıkar. Bu olay sunucu loguna hata olarak düşmez, çünkü sunucu tarafında bir hata yoktur; karar tarayıcıda verilmiştir.

Çözüm iki katmanlıdır. Birincisi, veritabanında ve tema dosyalarında kalan http:// referanslarını tek seferde temizlemek. İkincisi, şablonlarda mutlak adres yerine protokolü devralan göreli yollar kullanmak. Bir e-pin scripti kurarken kurulum sihirbazına yazdığın site adresinin baştan https:// olarak girilmesi, sonradan yüzlerce kaydı düzeltmekten çok daha kolaydır. Kurulumu http üzerinden yapıp sonra SSL eklemek, bu işin en yaygın sıralama hatasıdır.

HSTS ve yönlendirme kurgusunu hangi sırayla açmalısın?

HSTS, tarayıcıya "bu alan adına bir daha asla şifresiz bağlanma" diyen bir başlıktır ve tarayıcıda önbelleğe alınır. Gücü de tehlikesi de buradan gelir. Sertifikan düzgün çalışmadan HSTS'i uzun süreli açarsan ve sonra bir aksilik olursa, müşterinin tarayıcısı siteye şifresiz bile bağlanmayı reddeder; sen sorunu çözene kadar o kullanıcı için site yok sayılır. Doğru sıra nettir: önce sertifikayı kur, sonra tüm trafiği tek yönlü 301 ile HTTPS'e çek, birkaç gün gerçek trafikle izle, ardından HSTS süresini kısa başlatıp kademeli uzat.

Yönlendirme tarafında ikinci klasik hata www ve www'suz sürümü aynı anda birbirine yönlendirmek, yani döngü yaratmaktır. Tek bir kanonik adres seç, diğerini ona yönlendir, ödeme sağlayıcısının panelindeki dönüş adreslerini de o kanonik adrese göre güncelle. Sağlayıcı panelinde http yazan tek bir dönüş adresi, tüm başarılı ödemeleri yanlış kapıya götürmek için yeterlidir.

Kurulumu bitirdiğini nasıl kanıtlarsın?

Bir kurulumun bittiğine, hissederek değil kontrol listesi kapatarak karar verilir. Aşağıdaki tabloyu panel devreye alma günü açıp tek tek işaretle; her satır, gerçek bir işletmede en az bir kez ciro kaybına yol açmış bir maddeyi temsil ediyor. Özellikle son iki satır, panel aylardır sorunsuz çalışıyor gibi görünürken sessizce bozulan kısımlardır.

Bu işi tek tek mi kurmalı, hazır bir sistemle mi ilerlemeli?

Teknik olarak her maddeyi elle kurabilirsin. Sorun, bu maddelerin işletme büyüdükçe çoğalmasıdır: ikinci alan adı, mobil uygulama uç noktası, bayi paneli, fatura servisi. Her yeni parça, aynı zinciri yeniden doğru kurmayı gerektirir. İyi tasarlanmış bir dijital ürün satış scripti bu tekrarı azaltır; site adresini tek merkezde tutar, şablonlarda protokol karıştırmaz, sağlayıcı dönüş adreslerini kendi ayar ekranından üretir ve sistem sağlığı ekranında sertifika süresini gösterir. Özellikler tarafında aradığın şey parlak arayüz değil, tam olarak bu tür sessiz arızaları imkânsız kılan varsayılanlar olmalı.

Maliyet tarafında da hesap basittir. Tek bir bozuk webhook günü, çoğu zaman yıllık yazılım bedelinden daha pahalıya gelir; çünkü kaybedilen sadece o günün cirosu değil, kod gelmediği için bir daha alışveriş yapmayan müşteridir. Fiyatlandırmayı değerlendirirken sorman gereken soru "ne kadar tutuyor" değil, "hangi arıza sınıflarını benim hayatımdan tamamen çıkarıyor" olmalı.

SSL kurulumunu bir kez doğru kurgulayan işletmeler, sonraki yıllarda bu konuyu bir daha gündem yapmaz; yanlış kurgulayanlar ise her çeyrekte aynı arızayı farklı bir kılıkta yaşar. Panelinin bu zinciri nasıl tek ekrandan yönettiğini kendi gözünle görmek istersen canlı demo üzerinden ayar ekranlarını gez, sonra kendi kurulum listenle karşılaştır; farkı ilk beş dakikada göreceksin.