Prod ortamda Self-signed SSL kullanılır mı? Risk haritası

Self-signed SSL (kendi imzanla oluşturulan sertifika) bazı test senaryolarında hızlı bir çözüm sağlar. Ancak “prod’da çalışır mı?” sorusunun cevabı, sadece teknik olarak HTTPS açmak değildir; tarayıcı güven modeli, istemci doğrulaması, otomasyonlar ve hata maliyetleri belirleyicidir. Bu yazıda prod ortamda self-signed SSL kullanmanın risklerini somut başlıklar halinde ayırıp, ne zaman kullanılabileceğini ve güvenli alternatifi netleştireceksiniz.

Aşağıdaki kontrol listesiyle kendi sisteminizin durumunu hızlıca ölçün: - Sertifika doğrulaması kullanıcı tarafında nasıl çalışıyor? - Tarayıcı uyarıları (warning interstitial) oluşuyor mu? - Uygulama içi çağrılar ve servisler sertifika doğrulamasını nasıl ele alıyor? - SEO, log analizi, WAF/CDN ve izleme sistemleri bu durumu nasıl etkiliyor?

Self-signed SSL tam olarak neyi “garanti eder”?

Self-signed sertifika, sertifikanın doğrulama zincirinde (trust chain) genellikle tanınan bir CA (Certificate Authority) bulunmadığı için tarayıcılar ve çoğu istemci tarafından güvenilmez kabul edilir.

Prod’da “HTTPS var” denmesi yeterli değildir. Asıl garanti şudur: istemci, sertifikanın doğru sunucuya ait olduğunu güvenilir bir köke (root CA) dayanarak doğrulayabilir. Self-signed’de bu doğrulama ya başarısız olur ya da kullanıcı/istemci özel ayar gerektirir.

Prod için kritik fark: istemci uyarısı ve güven modeli

Self-signed sertifika ile HTTPS açtığınızda şu iki durumdan biri yaşanır: 1. Tarayıcı uyarısı çıkar: Kullanıcı “Güvenmiyor” / “Bağlantı güvenli değil” sayfası görür. 2. İstemci sertifikayı kabul edecek şekilde özel ayarlanır: Örneğin kurumsal cihazlarda sertifika kökü manuel eklenir veya uygulamada doğrulama devre dışı bırakılır.

Prod’da bu iki yaklaşım da farklı riskler üretir.

Prod’da self-signed SSL kullanmanın ana riskleri

Aşağıdaki risklerin her biri, “çalışıyor” görünse bile kullanıcı ve operasyon tarafında maliyet doğurur.

1) Tarayıcı “uyarı ekranı” ile kullanıcı kaybı

Kitleye açık bir prod web sitesinde self-signed SSL kullanmak, tarayıcıların güven uyarısını göstermesi nedeniyle pratik olarak kullanıcı trafiğini düşürür. Ayrıca bazı kullanıcılar güvenli olmayan uyarıdan çıkıp formu tamamlamadan vazgeçer.

Somut sonuçlar: - Checkout / login ekranlarında kullanıcı terk oranı artar. - Mobil tarayıcılarda uyarı davranışı değişken olabilir (bazı akışlar daha katı görünür).

Tarayıcı tarafında “sertifikaya güvenmiyorum” yaklaşımı, özellikle e-ticaret, ödeme ve müşteri hesapları gibi akışlarda kabul edilemez bir hata biçimidir.

2) Sertifika doğrulama devre dışı bırakılırsa güven tamamen kırılır

Self-signed ile çalışmak için bazı ekipler uygulamalarda TLS doğrulamasını gevşetir. Örneğin Node.js tarafında rejectUnauthorized gibi seçenekler devre dışı bırakılırsa, sistem “HTTPS görünümlü” olsa bile MITM (man-in-the-middle) saldırılarına karşı savunmasız hale gelir.

Bu riskin prod maliyeti yüksektir çünkü saldırgan sadece trafiği dinlemekle kalmaz, sahte içerik de sunabilir.

3) Otomasyon ve entegrasyon kırılmaları

Prod sistemleri sadece tarayıcıdan ibaret değildir. Aşağıdaki bileşenlerin çoğu sertifika doğrulaması yapar: - Uygulama servisleri arası çağrılar (server-to-server) - RPA / ETL job’ları - Monitoring/health check araçları - E-posta bağlantıları ve webhook’lar (bazı sistemler URL doğrulaması yapar)

Self-signed sertifika varsa bu entegrasyonlarda şu tip hatalar görülür: - x509: certificate signed by unknown authority - certificate verify failed - Otomatik yenileme veya container rollout sırasında beklenmedik TLS hataları

4) CDN/WAF/Reverse proxy zincirinde doğrulama karmaşası

Prod’ta tipik mimari şöyledir: CDN/WAF → Reverse proxy (Nginx/HAProxy) → Uygulama.

Self-signed SSL kullanınca zincirin hangi halkasının neyi doğruladığı netleşmez. Örneğin: - CDN, origin sertifikasını doğrulamak zorunda kalır. - Reverse proxy, upstream’e bağlanırken TLS doğrulama yapabilir. - Bazı sistemlerde “custom CA” tanımlaması gerekir.

Bu karmaşa, bakım sırasında “bir şeyler çalışırken başka bir şey bozuldu” durumlarını üretir.

5) Sertifika parmak izi (pinning) ve istemci güncellemeleri

Bazı kurum içi istemciler veya uygulamalar sertifika pinning yapar. Self-signed sertifikayı yenilediğinizde (ör. süre dolunca) pin kırılır, otomasyonlar devre dışı kalır.

Prod’da self-signed ile iki sorun ortaya çıkar: - Sertifikayı ne zaman yenileyeceğiniz net değildir. - Yenileme planı yoksa “beklenmedik kesinti” olur.

6) SEO ve analitik etkisi (dolaylı)

Self-signed sertifika, tarayıcı uyarısı nedeniyle kullanıcı etkileşimini bozar. Bu da dönüşüm ve davranış metriklerini dolaylı şekilde etkileyebilir.

Önemli nokta: Google gibi tarayıcılar içeriği indeksleyebilir; fakat kullanıcıların uyarı nedeniyle siteyi terk etmesi, özellikle sayfa altı akışlarda performansı düşürür. NetKıyas okuyucusu açısından mesele “SEO bozulur mu?”dan ziyade “kullanıcı güveni bozulur mu?” sorusudur.

Self-signed SSL ne zaman kabul edilebilir? (Prod dışı değil, prod ile sınır)

Self-signed SSL prod’a yakın ama kontrollü bir ortamda “kabul edilebilir” olabilir. Buradaki koşul: erişim tekil ve yönetilebilir olmalı.

Uygun senaryolar

Aşağıdaki şartlar sağlanıyorsa self-signed ile sınırlı bir prod kullanım modeli düşünülebilir: - Uygulama yalnızca kurum içi ağdan erişiliyor (IP allowlist / VPN) - İstemci cihazları kurumsal olarak yönetiliyor (sertifika dağıtımı yapılabiliyor) - Risk kabul edildi: Kullanıcı arayüzünde uyarı çıkmayacak şekilde kontrol var

Bu durumda “prod” aslında halka açık prod değil, yönetilen bir erişim prod’udur.

Kabul edilmez senaryolar

• Halka açık e-ticaret sitesi, topluluk sitesi, SaaS login sayfası
• Ödeme akışları, kimlik doğrulama (SSO) ve webhook kullanan entegrasyonlar
• CDN/WAF üzerinden herkesin eriştiği origin servisleri

Bu senaryolarda doğru yaklaşım: güvenilir bir CA’dan sertifika almak veya yönetilen bir SSL çözümü kullanmaktır.

Güvenli alternatif: CA tabanlı SSL ile prod’da aynı mimariyi koruyun

Self-signed yerine pratikte iki yol öne çıkar: 1. Güvenilir CA sertifikası (ör. Let’s Encrypt gibi otomatik yenilemeli seçenekler) 2. Yönetilen sertifika altyapısı (CDN üzerinden edge TLS)

Let’s Encrypt / otomatik yenileme neden prod’a daha uygundur?

• Tarayıcıların güvendiği kökler üzerinden doğrulama yapılır.
• Otomatik yenileme (renewal) planlanabilir.
• Reverse proxy ve CDN zincirinde origin doğrulama sorunları azalır.

CDN edge TLS kullanımı

CDN/WAF kullanıyorsanız genellikle “kullanıcı tarafı” ile “origin tarafı” TLS konuları ayrı ele alınır. Bazı kurulumlarda CDN ile kullanıcı arasında güvenilir sertifika; origin ile CDN arasında farklı bir sertifika modeli uygulanabilir.

Burada net kural: - Kullanıcıya sunulan uçta (client-facing) self-signed kullanmayın. - Origin tarafında self-signed’i bile sadece yönetilebilir bir ağ ve doğru CA tanımıyla sınırlayın.

Riskleri hızlı test etme: prod’a taşımadan önce yapılacak kontrol listesi

Aşağıdaki testler, self-signed SSL’in “görünürde çalışması”nın ötesinde gerçek etkisini gösterir.

1) Tarayıcı testi

• Gizli sekmede siteyi açın
• Uyarı ekranı çıkıp çıkmadığını gözleyin
• Farklı cihaz/OS (Windows + Android en azından) kontrol edin

Uyarı varsa bu prod için doğrudan kırmızı bayraktır.

2) Entegrasyon testi

• Uygulamanızın kendi sunucular arası çağrılarını test edin
• Health check (monitoring) endpoint’lerinin hata verip vermediğini inceleyin
• Webhook tüketicilerinin TLS doğrulama hatası loglayıp loglamadığını kontrol edin

3) Sertifika yenileme testi (operasyon güvenliği)

Self-signed kullanımında sertifika yenilemesi genellikle elle veya düzensiz planla yürütülür. - Yenileme tarih planınız var mı? - Sertifika pinning varsa güncelleme otomasyonu var mı?

4) Reverse proxy / load balancer zinciri testi

• Nginx/Ingress tarafında upstream TLS doğrulamasını nasıl ayarladığınızı kontrol edin
• Hangi katmanda hangi sertifikayı kullandığınızı dokümante edin

Aşağıdaki karşılaştırma, prod’da ne beklemeniz gerektiğini netleştirir.

Uygulama düzeyinde “nasıl yapılır” kısmı: kendinizi doğru yöne kilitleyin

Self-signed SSL’i prod benzeri kontrollü bir ortamda kullanmayı düşünüyorsanız bile, hedefiniz doğrulama sistemini mümkün olduğunca kapatmak değil, doğru doğrulama yöntemine geçmek olmalıdır.

Doğru yaklaşım (önerilen)

• Sertifikayı kullanan istemcilerin güven deposuna (trust store) doğru CA/sertifika kökünü ekleyin.
• Uygulamada doğrulamayı devre dışı bırakmayın.

Hatalı yaklaşım (riskli)

• Uygulama kodunda TLS doğrulamasını kaldırmak.
• “Her sertifikayı kabul et” yaklaşımı.

Bu yaklaşım kısa vadede sorunu örter, uzun vadede güvenlik açıklarını büyütür.

Sonuç: Prod’da self-signed SSL yerine doğrulanabilir sertifikayı hedefleyin

Self-signed SSL prod’da “teknik olarak HTTPS çalıştırır” görünse bile, tarayıcı uyarısı, entegrasyon kırılması ve güven zincirinin zayıflaması gibi riskler nedeniyle halka açık prod senaryolarında doğru seçim değildir. Kontrollü erişimli (VPN/iç ağ) ve istemci doğrulaması yönetilebilen durumlarda sınırlı kullanım mümkündür; ancak bu bile operasyonel yenileme riskleri taşır.

Aksiyon önerisi: Eğer siteniz kullanıcıların tarayıcı üzerinden eriştiği gerçek prod ise güvenilir bir CA’dan sertifikaya geçin ve sertifika yenileme sürecini (automation) sistemin rutin bakımına dahil edin. Bu adım, hem güvenlik hem de arıza maliyetini net biçimde düşürür.