Self-signed SSL prod’da çalışır mı? Riskler ve net karar

Self-signed SSL (kendi imzanla sertifika) teknik olarak HTTPS açar; ancak prod ortamda “kapatılacak bir uyarı” gibi düşünülmemesi gerekir. Çünkü tarayıcı güven modeli, sertifikanın doğrulanmasını sertifika otoritesi zinciriyle (CA chain) eşleştirir. Bu yazıda self-signed SSL’in prod’da çalışmasının ne zaman mümkün, ne zaman risk olduğunu net biçimde ayıracağız; ayrıca karar vermeyi kolaylaştıran kontrol listesi ve alternatifleri sunacağız.

Self-signed SSL prod’da ne sağlar, ne sağlayamaz?

Self-signed SSL’in temel etkisi, istemci ile sunucu arasında trafik şifrelemesi başlatmaktır. Yani kullanıcı ile sunucu arasındaki veri hattı şifrelenir (TLS kurulur). Bu, “gizlilik” katmanını kısmen yerine getirir.

Fakat tarayıcıların ve birçok istemcinin asıl kontrol ettiği şey şifrenin varlığı değil, sertifikanın kim tarafından doğrulandığıdır.

Prod’da asıl sorun: güven zinciri doğrulaması

Self-signed sertifika, çoğu tarayıcı tarafından varsayılan güven deposunda (trusted root store) bulunmadığı için doğrulama başarısız olur. Sonuçlar: - Tarayıcıda ziyaretçiyi karşılayan güven uyarısı ("This connection is not private" benzeri). - Bazı istemcilerde otomatik reddetme (özellikle otomasyon botları ve sıkı kurumsal politikalar). - Müşteri tarafında sertifikayı elle içe aktarma ihtiyacı.

Riskler: prod’da self-signed SSL kullanmanın somut etkileri

Aşağıdaki riskleri “etki türü” olarak ele alırsak karar netleşir:

1) Kullanıcı deneyimi ve dönüşüm kaybı

Tarayıcı uyarısı, prod’da ziyaretçinin siteyi terk etmesine yol açan en pratik etkiyi doğurur. Bu sadece “güven problemi algısı” değil; aynı zamanda ziyaretçinin uyarı ekranından devam etme sürecinde karar kalitesini düşürür.

2) Otomasyon bozulması (API çağrıları, botlar, entegrasyonlar)

Self-signed sertifikada istemci doğrulaması başarısız olduğu için: - CI/CD pipeline’ları, test script’leri veya webhook alan sistemleri hataya düşer. - Bazı HTTP istemcileri (özellikle sertifika doğrulamasını zorunlu yapan kurumsal SDK/agent’lar) bağlantıyı reddeder.

3) Operasyonel yük: sertifika yönetimi ve güncelleme

Self-signed sertifikayı prod’da kullanmak, pratikte “her istemcide kabul ettirme” işine döner: - Sertifikayı tarayıcıya/OS’a eklemek gerekir. - Mobil cihazlar, farklı tarayıcılar ve farklı ağlar için ayrı doğrulamalar gerekebilir.

4) Güvenlik algısı ve denetim (compliance) riski

Prod, güvenlik kontrollerinin denetlendiği ortamdır. Self-signed SSL: - “Şifreli trafik var ama kimlik doğrulaması yok” gibi okunabilir. - Güven denetimlerinde (audit) açıklama ihtiyacı doğurur. - Bazı organizasyonlarda kurumsal güvenlik politikaları self-signed’i doğrudan yasaklar.

5) Orta adam saldırısı (MITM) ihtimali algısı

Teknik olarak TLS, şifrelemeyle birlikte MITM’i zorlaştırır; ancak sertifika doğrulaması başarısız olduğunda kullanıcı/istemci güven modeli zayıflar. Self-signed’le “nasıl doğrulayacağınız” sorusu ortaya çıkar.

Net sonuç: Trafik şifrelenir ama “site kimliği” doğrulanmadığı için güven modeli tam kurulmaz.

Self-signed SSL prod’da hangi senaryolarda “kabul edilebilir”?

Self-signed SSL prod’da her durumda “yanlış” değildir. Aşağıdaki senaryolarda risk kontrollüdür: - Kapsamı sınırlı bir iç ağ kullanımı: Yalnızca yönetilen istemciler ve kontrollü erişim. - İstemci tarafında sertifika kabulü zaten planlıysa: Örn. kurumsal cihazlara sertifikayı ekleyebiliyorsanız. - Üretim değil, “production benzeri” test: Gerçek kullanıcı trafiği yoksa. - Yetkili teknik kullanıcıların eriştiği admin panel gibi, tarayıcı uyarılarını yönetmenin bir prosedürü varsa.

Buna karşılık, gerçek kullanıcıların göreceği web sitelerinde self-signed SSL prod için uygun değildir. Çünkü tarayıcı uyarısı otomatik olarak “kalıcı sürtünme” üretir.

Karşılaştırma: Self-signed vs CA imzalı SSL (prod için)

Aşağıdaki tablo, prod kararı verirken kritik farkları özetler.

Alternatifler: prod’da HTTPS’i doğru kurmanın net yolları

Self-signed yerine genellikle şu seçenekler kullanılır:

1) Ücretsiz CA tabanlı SSL (Let’s Encrypt)

Birçok ortamda en pratik çözüm Let’s Encrypt’tir. Sertifika, güven deposunda tanınan bir CA üzerinden gelir; kullanıcı uyarısı oluşmaz.

NetKıyas yaklaşımıyla hedef: Ziyaretçinin “sertifika hatası” görmeden HTTPS kullanabilmesi.

2) Yönetimli sertifika (WAF/CDN veya cloud sağlayıcı)

Bazı bulut/CDN sağlayıcıları sertifikayı sizin adınıza yönetir. Özellikle multi-domain (SAN) veya sık yenileme gerektiren durumlarda operasyonu azaltır.

3) İç CA (Internal CA) ile kurumsal doğrulama

Tam iç ağ projelerinde, kurumun kendi CA’sını istemcilerin güven deposuna ekleyerek güven modelini tamamlayabilirsiniz.

Bu yaklaşım, “self-signed” mantığının daha kontrollü versiyonudur: Sertifika tek kullanıcıya değil, yönetilen güven deposuna dayanır.

Karar verme kontrol listesi (prod’da net cevap)

Kendinize aşağıdaki soruları “evet/hayır” şeklinde sorun. Toplam evet sayısı arttıkça self-signed SSL riskli hale gelir.

Kullanıcı trafiği var mı?

• Evet: Self-signed prod için uygun değildir.
• Hayır: İç sistem olabilir.

İstemcilerinizin sertifikayı elle kabul etme süreci var mı?

• Yok: Self-signed prod risklidir.
• Var: Yönetilen istemci senaryosu olabilir.

API’ler ve entegrasyonlar sertifika doğrulaması yapıyor mu?

• Evet: Self-signed, bağlantı hatası ve prod kesintisi riski oluşturur.

Uyarı ekranı yönetilebilir mi (prosedür var mı)?

• Hayır: Ziyaretçi kaybı ve destek yükü artar.

Denetim/uygunluk beklentisi var mı?

• Evet: CA imzalı SSL standart beklentidir.

Eğer mecburen self-signed kullanıyorsanız: en az riskli uygulama

Self-signed’i “mecburen” kullandığınız durumlar nadirdir; yine de riski azaltan teknik önlemler vardır.

1) Sadece erişim kısıtlı uç noktalar kullanın

Admin panel veya dahili API gibi, erişimi IP allowlist veya VPN ile sınırlandırın.

2) Sertifika pinning/özel istemci ayarları yerine planlı güven deposu kullanın

Tek tek tarayıcı ayarı yerine kurum ölçeğinde yönetilen güven deposu yaklaşımı daha sürdürülebilirdir.

3) Sertifika yenileme planı kurun

Self-signed sertifikaların yenilenmesi genelde otomasyonsuz kalır. Prod’da kesinti yaşamamak için: - Sertifikanın bitiş tarihini (expiration) düzenli takip edin. - Yenileme ve dağıtım adımlarını dokümante edin.

4) Operasyon izleme: TLS hataları ve bağlantı reddi

Web sunucusu ve uygulama loglarında TLS handshake hatalarını izleyin. - Başarısız doğrulamalar artıyorsa müşteri/istemci tarafı problemine dönüşmeden aksiyon alın.

Net tavsiye: prod için güvenilir yol

Kullanıcı trafiği olan gerçek bir web/prod ortamında self-signed SSL ile karar vermeyin: Tarayıcı uyarısı, otomasyon bozulması ve denetim riski doğurur. En doğru yaklaşım CA imzalı SSL kullanmaktır; çoğu senaryoda Let’s Encrypt veya yönetimli sertifika hizmetleri hem maliyeti düşürür hem de prod stabilitesini artırır.

Aksiyon olarak şu adımı uygulayın: İnternet üzerinden erişilen tüm domain’ler için CA imzalı SSL hedefleyin; yalnızca iç ağ/erişimi kısıtlı sistemlerde self-signed düşünün ve mutlaka sertifika dağıtım + yenileme + izleme planını dokümante edin. Bu şekilde prod’da güven, operasyon ve kullanıcı deneyimi aynı anda korunur.