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

Self-signed SSL (kendinden imzalı sertifika), test ortamında hızlı ilerlemek için pratik görünür. Ancak prod (üretim) ortamında “güven” ve “kimlik doğrulama” beklentisini doğrudan etkiler. Bu yazıda self-signed SSL’in prod’da neden riskli olduğunu; hangi senaryolarda kesinlikle kaçınılması gerektiğini, hangi sınırlı durumlarda kontrollü şekilde kullanılabileceğini ve doğru alternatifleri net bir karar çerçevesiyle anlatıyoruz.

Self-signed SSL prod’da neyi “bozuyor”?

Self-signed SSL, sertifikanın imzacısının (CA) tarayıcılar tarafından güvenilir listelerde olmaması demektir. Sonuç olarak tarayıcılar çoğu durumda şu uyarıları üretir: - Sertifika güvenilmiyor (untrusted) - Sertifikanın alan adı ile uyuşması sorunlu görünebilir (CN/SAN yanlışsa) - Bağlantı güvenli olsa bile tarayıcı kullanıcıyı uyarır

Prod’da bu durum yalnızca “göz yorucu bir uyarı” değildir. Güvenin kullanıcıya yansımasını, SEO/UX etkisini ve bazı otomasyon akışlarının (API istemcileri, servis-to-servis çağrılar) davranışını doğrudan değiştirir.

En kritik fark: TLS var, ama “kimlik” doğrulanmıyor

TLS şifreleme (encryption) yapılır; trafiğiniz gizlenir. Fakat self-signed sertifikayla doğrulanan kimlik, tarayıcının gözünde güvenilir bir otorite üzerinden gelmediği için doğrulama zinciri kırılır. Bu, MITM (man-in-the-middle) senaryolarında kullanıcı/istemci tarafında “ben bunun gerçek sunucu olduğuna güveniyorum” kararını ortadan kaldırır.

Prod’da karşılaşacağınız riskler

Aşağıdaki riskler, self-signed SSL’i prod’a taşırken “en sık ve en maliyetli” olanlar.

1) Tarayıcı uyarıları: dönüşüm kaybı ve destek maliyeti

Üretim ortamında ziyaretçilerinize sertifika uyarısı göstermek iki kanalı etkiler: - Dönüşüm: Kullanıcı uyarıyı görüp işlemi iptal eder. - Operasyon: “Site açılmıyor / güvenli değil” bildirimleri artar.

Kurumsal müşteri tarafında ise tarayıcı uyarıları politika ihlali gibi algılanabilir.

2) Hatalı entegrasyonlar: API istemcilerinin reddetmesi

Prod’da sadece tarayıcılar yoktur. Uygulamalarınız backend’te birbirini çağırır: - Ödeme sağlayıcıları - Özel servisler - Job/scheduler sistemleri - Monitoring/collector araçları

Birçok istemci kitaplığı doğrulama (certificate validation) açıkken untrusted sertifikayı reddeder. Bu durumda sorun “SSL çalışmıyor” gibi görünür ama kök neden doğrulama zinciridir.

3) Sertifika yönetimi: döngüsel hata riski

Self-signed sertifikalar genelde daha “elle yönetilir”: - Sertifika yenileme (renew) takvimi unutulursa kesinti olur. - Yeni sertifika yayımlanınca istemcilerin trust listeleri güncellenmelidir. - Sunucu IP’si/alan adı değişirse CN/SAN uyumsuzluğu ortaya çıkabilir.

Prod’da bu süreç, küçük bir eksiklikle bile “kısmi kesinti” yaratabilir.

4) Güven varsayımı: yanlış ekibin yanlış kararı almasına yol açar

Self-signed sertifika kullanan ekipler, “HTTPS var” diye güvenlik kontrolünü tamamlandığını varsayabilir. Oysa güvenlik kontrolü iki parçadır: - Şifreleme yapıyor mu? - Kimlik doğrulanıyor mu?

Self-signed SSL ikinci parçayı zayıflatır.

5) Failover ve yük dengeleme (LB) ile ölçeklenirken sorun çıkması

Yük dengeleyici arkasında birden fazla instance varsa her instance’ın aynı sertifikayı doğru konfigürasyonla kullandığından emin olmanız gerekir. Aksi halde bazı istekler valide edilebilir, bazıları edilmeyebilir.

Ne zaman (istisna olarak) kullanılabilir?

Self-signed SSL’i prod’da “tamamen yasak” gibi düşünmek doğru değil; ama kriterleri çok net olmalı. Aşağıdaki şartlar sağlanmadan prod’da self-signed SSL kullanmak, kontrollü risk almak değildir; çoğunlukla hataya davetiye çıkarmaktır.

Kontrollü ve kapalı sistem senaryosu

Self-signed SSL yalnızca şu koşullarda makul bir istisna olabilir: - İnternet üzerinden kullanıcı trafiği yoktur (tamamen iç ağ / VPN / kapalı erişim) - İstemcilerinizin hepsi aynı kontrol altında (ör. kurumsal iç servisler) - İstemcilerde doğrulama için sertifikayı “trust” edecek mekanizma vardır - Uyarıların gösterilmesi mümkün değildir (ör. tarayıcı erişimi yok)

“HTTPS zorunlu ama müşteri görmüyor” gibi bir durum

Bazı organizasyonlar prod’da yalnızca altyapı seviyesinde HTTPS ister. Örneğin: - Reverse proxy arası servisler - Kubernetes ingress arkasında dahili çağrılar - Sadece API istemcileri ve bunların hepsi sizin kontrolünüzde

Bu durumda sorun “kullanıcı görür mü?” değil “istemci doğrular mı ve kesintiye nasıl düşer?” olur.

Prod için net karar: Ne yapmalısınız?

Aşağıdaki tablo, self-signed SSL ile prod arasında hızlı karar vermenizi sağlar.

Self-signed yerine prod’da “doğru” alternatifler

1) Let’s Encrypt (güvenilir CA) ile kamu sertifikası

Kurumsal ve teknik açıdan en yaygın çözüm, tarayıcılar tarafından güvenilen bir CA kullanmaktır. Let’s Encrypt, özellikle otomasyonla yönetildiğinde operasyon maliyetini düşürür.

Ne zaman uygundur? - Alan adınız (domain) halka açık erişimde doğrulanabiliyorsa - Otomatik yenileme yapabiliyorsanız - Ekipte sertifika yönetimi standardı varsa

2) İç CA (internal CA) — kapalı ağ için en doğru “prod benzeri” yaklaşım

Eğer internet trafiği yoksa ve kurumsal bir iç ağ kullanıyorsanız, self-signed yerine internal CA yaklaşımı daha kontrollüdür. - Sertifika güven zinciri yönetilebilir - İstemcilere “CA’yı trust etme” yapısal olarak çözülür - Yenileme ve revocation yönetimi daha planlı yürür

Bu yaklaşım, self-signed’in “her şeyi tek sertifikaya indirgeme” riskini azaltır.

3) Ticari (commercial) SSL sertifikası

Bazı kurumlar için gerekçeler şunlar olabilir: - SLA/ek garanti ihtiyacı - Daha güçlü doğrulama süreçleri - Operasyonel süreçlerin yönetim kolaylığı

Bu seçenek, özellikle büyük ölçekli ve denetim gerektiren kurulumlarda tercih edilir.

Prod SSL yönetim kontrol listesi (self-signed olmasa da şart)

Self-signed SSL kullanmaktan bağımsız olarak, prod’da SSL/TLS güvenliğini sağlamanın pratik kontrol noktaları: - Alan adı uyumu: Sertifikada SAN (Subject Alternative Name) veya doğru CN bulunuyor mu? - Zincir doğruluğu: Ara sertifikeler doğru sunuluyor mu? Eksik chain çoğu zaman “arada sırada güven hatası” üretir. - TLS sürümleri: Gereksiz eski protokoller kapalı mı? (örn. TLS 1.0/1.1) - Otomatik yenileme: Sertifika bitişinden bağımsız olarak otomasyon çalışıyor mu? - Kesişen servisler: Reverse proxy (Nginx/Apache) ile uygulama katmanında sertifika/konfigürasyon çakışması var mı? - Yedek planı: Sertifika yenileme başarısız olursa trafik nasıl etkilenir?

Uygulama örnekleri: Hangi noktada sorun çıkar?

Self-signed SSL kullandığınızda sorun genelde şu katmanlarda patlar.

Reverse proxy arkasında doğrulama

Örnek: Nginx/HAProxy terminasyon yapıyor ama upstream (uygulama) tarafı ayrıca TLS doğruluyor olabilir. - Reverse proxy “client” tarafını doğrulamaz, kullanıcı uyarı görür. - Proxy “server” tarafında upstream’i doğrular ve upstream untrusted kalır.

Servis-to-servis çağrılarda certificate validation

Uygulama kodunuzda doğrulama kapalıysa (ör. “verify=false” türü ayar) prod güvenliği fiilen düşer. Doğrulama açıkken untrusted sertifika kullanıyorsanız ise çalışmaz.

Bu yüzden “çalışıyor” ile “güvenli/istikrarlı” aynı şey değildir.

Sonuç: Prod için net aksiyon önerisi

Self-signed SSL, prod’da yalnızca kapalı ve tam kontrollü servis senaryolarında “kısa vadeli, kontrollü risk” olarak düşünülebilir. Kullanıcıların tarayıcıdan eriştiği veya dış istemcilerin dahil olduğu her durumda risk seviyesi yüksektir: tarayıcı uyarıları, istemci reddi ve operasyonel sertifika yönetimi kesinti doğurur.

Aksiyon planı: 1) Web/API herkese açık ise self-signed SSL’i prod’dan kaldırın. 2) Açık erişim doğrulanabiliyorsa Let’s Encrypt gibi güvenilir CA ile sertifikayı otomatik yenileyecek düzene geçin. 3) İnternet yoksa iç CA (internal CA) kurarak tüm istemcileri CA’yı trust edecek şekilde standartlaştırın. 4) Sertifika zinciri, SAN doğruluğu ve otomatik yenileme için kontrol listesini yürütün.

Bu adımlarla “HTTPS var” görünümünü değil, prod’da gerçekten beklenen güven ve istikrarı sağlarsınız.