Self-Signed SSL ile prod’da çalışılır mı? Riskler ve doğru yaklaşım

Self-signed SSL (kendi imzaladığın sertifika) ile üretim (prod) ortamında çalışmak, teknik olarak mümkün olsa da çoğu senaryoda geri dönüş maliyeti yüksek bir risktir. Tarayıcıların güven vermeyen sertifikayı reddetmesi, kullanıcıların “güvenli değil” uyarılarıyla karşılaşması; ayrıca hata yönetimi, izleme ve yedekleme süreçlerini doğrudan etkiler. Bu yazıda prod için “ne zaman yapılır / ne zaman yapılmaz” kararını somut risklerle netleştiriyor; bunun yerine uygulanabilecek doğrulanabilir alternatifleri karşılaştırıyoruz.

Self-signed SSL prod’da neden sorun çıkarır?

Self-signed SSL, sertifikanın bir sertifika otoritesi (CA - Certificate Authority) tarafından doğrulanmaması demektir. Bu yüzden tarayıcılar ve işletim sistemleri sertifikayı varsayılan olarak güvenli kabul etmez.

Prod ortamında sorun genellikle üç kanalda görünür:

1) Tarayıcı ve kullanıcı güveni (en görünür risk)

Chrome/Firefox ve mobil tarayıcılar “Bağlantınız gizli değil”/“Güvenilmeyen sertifika” uyarıları gösterir.
Kullanıcıların bir kısmı devam etmez; bu doğrudan dönüşüm ve erişilebilirlik kaybıdır.
Çalışan ekiplerin testleri “tamam gidiyor” gibi görünse bile, gerçek kullanıcı akışında uyarılar satış, form doldurma ve kayıt oranını düşürür.

Prod’da kullanıcı kitlesi genişledikçe bu problem ölçülebilir kayba döner.

2) Doğrulama ve hata yönetimi karmaşası

Self-signed SSL, yanlış yapılandırma olduğunda “gerçek mi yoksa sertifika hatası mı?” ayrımını zorlaştırır. - Uptime monitörleri (HTTP/HTTPS kontrolü yapan sistemler) hata vermez ama uyarı/özel istisna yönetimi ister. - Loglarda TLS doğrulama hataları görünür; incident (olay) yönetiminde gereksiz gürültü artar. - Bazı proxy/CDN/ingress katmanları self-signed sertifikayı farklı şekillerde ele alır; “bazı bölgelerde çalışıyor gibi” yanılsaması oluşturabilir.

3) Güvenlik göstergelerinin etkisizleşmesi

Prod’ta amaç yalnızca şifreleme yapmak değil; aynı zamanda kimliğin doğrulanmasıdır. CA tarafından imzalanmamış sertifika, ortadaki kişinin sunucuya kendini “gibi” göstermesini engelleme gücünü azaltır. Bu durum çoğu organizasyon için kabul edilebilir değildir.

Self-signed SSL ile prod’da çalışmanın risk haritası

Aşağıdaki tablo, prod ortamında karşılaşacağınız etkileri ve genellikle nasıl telafi edildiğini özetler.

Risk	Etki	Tipik Belirti	Prod’da Sonuç	Yaygın Telafi
Tarayıcı uyarıları	Erişim kaybı	“Güvenilmeyen sertifika”	Dönüşüm düşer	CA sertifikası ya da özel trust
Uptime/monitor alarm yorgunluğu	Operasyonel yük	Sürekli “TLS” hatası	Gerçek arızayı kaçırma	Monitörü doğru CA’ya göre ayarlama
Load balancer / reverse proxy uyumsuzluğu	Kesintiler	Bazı istekler çalışır	Bölgesel kesinti	Proxy trust store güncellemesi
Mobil uygulama / API istemcisi reddi	Entegrasyon arızası	TLS handshake failure	Kritik iş akışı bozulur	CA veya pinning stratejisi
İç ekiplerde “o an çalıştı” yanılsaması	Yanlış karar	İşyeri ağı içinde sessiz çalışır	Prod’a geçişte patlar	Staging’i gerçek kullanıcı gibi doğrulama
Sertifika yenileme yönetimi zorluğu	Güvenlik açıkları	Süresi dolmuş sertifika	TLS kesintisi	Otomasyon (renew) + CA

Ne tür prod senaryolarda kabul edilebilir? (Net karar kriterleri)

Self-signed SSL ile prod’a geçmek, genellikle şu koşullarda “teknik olarak yapılır” ama istisnai sayılır:

Tamamen kapalı erişim: Sadece kurumsal ağ içinden, VPN arkasından veya IP allowlist ile erişilen bir servis.
Kullanıcı kitlesi yok: Yalnızca server-to-server çağrıları; yani tarayıcı trafiği yok.
Kontrol sizde: İstemci tarafında (ör. dahili uygulama) sertifikayı trust etmek mümkün ve yönetiliyor.
Hata izleme katmanı hazır: Uptime ve loglar self-signed’u “normal” saymayacak şekilde ayarlanmış.

Bunların hepsi sağlanmıyorsa prod ortamında self-signed sertifika kullanımı, riskleri “operasyonel maliyete” dönüştürür.

Self-signed SSL yerine prod için doğru alternatifler

Aşağıda, prod’da daha sürdürülebilir seçenekleri “risk seviyesi” ve uygulama karmaşıklığı açısından değerlendiriyoruz.

Seçenek 1: CA imzalı ücretsiz sertifika (Let’s Encrypt)

Üretim için en yaygın çözümdür.
Otomatik yenileme (renew) mekanizmaları mevcuttur.
Tarayıcılar tarafından güvenilir kabul edilir.

Not: DNS erişimi ve/veya HTTP-01/ALPN-01 gibi doğrulama yöntemleri gerekir. Reverse proxy veya CDN kullanıyorsanız, doğrulama yolunu doğru kurgulamak önemlidir.

Seçenek 2: Kurumsal CA / Internal CA (organizasyon içi)

Kurum içinde cihazlar ve istemciler üzerinde trust zinciri yönetilebilir.
Kullanıcı tarayıcıları uyarı vermeden çalışır.
Dış kullanıcıya açık servislerde yine CA zincirinin kapsamı belirleyicidir.

Seçenek 3: Ticari CA sertifikası

Güven ve uyumluluk hedeflenir.
Bazı compliance (uyum) ihtiyaçlarında tercih edilir.
Operasyonel maliyet vardır (yenileme ücreti).

Seçenek 4: İleri seviye istemci güven modeli (pinning)

Self-signed yerine CA zinciri doğru ayarlanmadığında, uygulama tarafında “sertifika pinning” gibi yöntemler gündeme gelebilir. Ancak bu yöntem, sertifika yenileme sürecini zorlaştırır. Prod’da operasyonel risk artırdığı için genellikle “özel” senaryolarda kullanılır.

Riskleri azaltmak için pratik kontrol listesi

Prod’a geçmeden önce şu kontrolleri tamamlayın. Bu listeyi “self-signed için de uygulanır” diye düşünmeyin; daha çok yanlış karar riskini ve son dakika sürprizlerini azaltır.

### 1) Erişim kanallarını netleştirin

Servis yalnızca API mi, yoksa web tarayıcısı da kullanıyor mu?
Trafik VPN/kurumsal ağ ile mi sınırlı?
Mobil uygulama veya üçüncü taraf entegrasyon var mı?

Bu soruların cevabı “tarayıcı + genel internet” ise self-signed SSL prod için kabul edilmez seviyede riskli olur.

### 2) Monitoring’i doğrulayın

Uptime kontrolü sadece “200 OK” değil; sertifika doğrulama durumunu da izleyin.
False positive oluşmaması için test ortamı ile prod ortamındaki TLS davranışını aynılaştırın.

### 3) Yenileme (renew) ve kesinti planını yazın

CA imzalı sertifikalarda yenileme otomasyonu kritik olduğu için bir “renew başarısız olursa ne olur?” senaryosu belirleyin. - Yenileme hangi pipeline’da çalışıyor? - Yenileme başarısız olursa hangi alarm tetikleniyor? - Expired sertifika olursa hizmeti kim hangi adımlarla kurtarır?

### 4) Reverse proxy / load balancer güvenini kontrol edin

Nginx/Apache önünde başka katman (CDN, WAF, ingress) varsa sertifika zinciri uçtan uca uyumlu olmalı.
İstemci tarafındaki güven ile proxy içindeki trust store güncellemeleri birbirini etkilemez; bu nedenle test, “gerçek rota” üzerinden yapılmalıdır.

### 5) Staging’i sadece “URL açılıyor” seviyesinde bırakmayın

Staging testlerinde tarayıcı uyarısı göz ardı edilebiliyor. Prod testi şu şekilde olmalı: - Gerçek kullanıcı tarayıcısı (varsayılan güven ayarları ile) - Gerçek kullanıcı yolu (redirect’ler, auth akışları, API çağrıları) - Farklı ağlar (kurumsal Wi-Fi yerine mobil internet gibi)

Sonuç: Prod’da kararınızı tek şeye indirgemek için kural

Self-signed SSL ile prod’da çalışmak; tarayıcı uyarılarını yönetebileceğiniz kapalı bir servis kurmadıysanız, erişim ve operasyonel riskleri büyütür. Bu yüzden prod için temel kural şudur:

Kullanıcı (tarayıcı) trafiği varsa: CA imzalı sertifika kullanın.
Tamamen kapalı (VPN/IP allowlist), tarayıcı yoksa ve istemci tarafında trust yönetimi varsa: self-signed “kısa süreli ve kontrollü” bir geçiş seçeneği olabilir.

Aksiyon önerisi: Prod’a geçmeden önce sertifika modelinizi (self-signed mı CA mı) erişim kanallarına göre sınıflandırın; ardından monitoring ve yenileme planını netleştirin. Eğer web kullanıcıları veya genel internet trafiği varsa, self-signed yerine Let’s Encrypt ya da kurumsal CA’ya geçiş planını bir sonraki deploy döngüsüne alın.