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

Self-signed SSL (kendi imzaladığınız sertifika), geliştirme (dev) ortamında hızlı deneme için işe yarar. Ancak prod ortamına taşındığında güvenlik ve operasyon tarafında görünmeyen maliyetler ortaya çıkar. Bu rehberde; self-signed SSL’in prod’da neden riskli olduğunu, hangi senaryolarda hiç kullanılmaması gerektiğini ve hangi alternatifin hangi koşulda en doğru seçim olduğunu net biçimde göreceksiniz.

Self-signed SSL nedir ve prod’da neden farklı davranır?

Self-signed SSL, sertifikanın CA (Certificate Authority) tarafından imzalanmadığı, dolayısıyla tarayıcıların onu doğrudan “güvenilir” listesinde görmediği durumdur.

Prod’da fark yaratan şey, tarayıcının veya client uygulamanın “kullanıcı etkileşimi + güven doğrulaması” sürecini nasıl ele aldığıdır: - Tarayıcılar çoğu durumda “Güvenli değil” uyarısı üretir. - Mobil uygulamalar veya API client’lar sertifikayı doğrularken hata verebilir. - Bazı güvenlik politikaları (TLS/HTTPS allow-list, pinning, kurumsal sertifika store) self-signed sertifikayı reddeder.

Sonuç: Self-signed SSL prod’da “çalışıyor” olsa bile, kullanım deneyimi ve operasyonel kararlılık bozulabilir.

Self-signed SSL’in prod’da tipik tetiklediği sorunlar

Aşağıdaki sorunlar, self-signed SSL ile prod’a çıkıldığında en sık rapor edilenlerdir: - Tarayıcı uyarısı: Kullanıcı sayfayı açsa bile güven problemi oluşur. - OAuth / SSO / webhook entegrasyon sorunları: Bazı servisler “sertifika zinciri” beklentisiyle çalışır. - SEO ve tarayıcı davranışı: Uyarı sayfaları tıklamayı düşürür; arama sonuçlarında doğrudan teknik ceza her zaman görünmese de kullanıcı sinyali zarar görür. - Hata yönetimi maliyeti: Client bazlı “farklı davranış” üretir (tarayıcı farkı, işletim sistemi farkı, sertifika store farkı). - Sertifika yenileme/dağıtma: Sertifika süresi bitince tüm client’lar tekrar güncelleme ister.

Risk analizi: Prod’da self-signed SSL kullanmanın somut maliyetleri

“Pros’da çalışır mı?” sorusunun doğru cevabı: Teknik olarak HTTPS kurulur, ama gerçek prod gereksinimlerine göre kalite maliyeti yükselir.

Aşağıdaki kontrol matrisi, prod uygunluğunu hızlı değerlendirmenizi sağlar.

1) Kullanıcı erişimi (B2C) için risk seviyesi

B2C (kullanıcıların web sitenize tarayıcıdan girdiği) senaryosunda self-signed SSL, prod için fiilen uyumsuzdur.

• Tarayıcı uyarısı tüketici güvenini kırar.
• Kullanıcı “Güvenli değil” ekranından geçmeyi seçse bile dönüş oranı düşer.
• “Tek seferlik sorun” gibi görünse de dönemsel sertifika yenileme dönemlerinde tekrar tekrar aynı problem yaşanır.

2) API entegrasyonları (B2B) için risk seviyesi

API client’ları (uygulama sunucuları, job scheduler’lar, third-party entegrasyonlar) sertifika doğrulaması yapar. Self-signed sertifika: - Sertifika zinciri bekleyenlerde hataya yol açar. - “Sertifikayı güvene alma” manuel işlemi gerektirebilir. - Client başına farklı çözüm (trust store’a ekleme) doğurur.

Bu, bakım maliyetini büyütür.

3) Operasyon ve bakım riski

Prod’da sertifika yönetimi “otomatik ve izlenebilir” olmalıdır. Self-signed sertifikada ise genellikle: - Otomatik CA tabanlı yenileme akışı yoktur. - Dağıtım (client trust store) manuel ilerler. - Sertifika süresi dolunca kesinti riski artar.

4) Kurumsal güvenlik politikaları ile uyumsuzluk

Bazı kurumlar: - Sadece belirli CA’ların sertifikalarını kabul eder. - TLS fingerprint/pinning uygulayabilir. - Kurumsal proxy/SSL inspection kullanır.

Self-signed SSL bu politikaların çoğunda doğrudan uyuşmazlık üretir.

Ne zaman “kullanılabilir”? (Sınırları net senaryolar)

Self-signed SSL prod’da tek bir şekilde “yapılır” ve geri dönüşü yoktur. Bunun yerine şu sınırlar önemlidir: prod dediğiniz şey, kimlerin eriştiği ve sertifika doğrulamasının nasıl yönetildiğidir.

Aşağıdaki durumda self-signed SSL kabul edilebilir olsa bile riskleri göze alıyor olursunuz: - Erişim sadece sizin kontrolünüzdeki iç sistemler arasında (ör. lab değil, tamamen izole ağ) ve tüm client’lar self-signed sertifikayı güvene alacak şekilde yönetiliyorsa. - Sertifika dağıtımı merkezi şekilde otomatik yapılıyorsa (ör. config yönetimi ile trust store güncelleniyorsa). - Sertifika yenileme/rollback akışı test edilmişse.

Buna karşılık aşağıdaki senaryolarda self-signed SSL prod kullanımına uygun değildir: - Kamuya açık web sitesi (kullanıcıların tarayıcıdan girdiği). - Üçüncü taraf servislerle entegrasyon (webhook, ödeme sağlayıcı, e-posta API, SSO, live callback). - Kurumsal müşterilerden gelen istemciler (heterojen client ortamları). - Dışarıdan erişen otomasyon sistemleri (CI/CD, monitoring, log pipeline) sertifika hatasıyla duruyorsa.

Alternatifler: Self-signed yerine prod’da doğru SSL seçimi

Prod’da amaç “HTTPS kurmak”tan çok; güven doğrulamasını sorunsuz ve otomatik yürütmektir.

Aşağıda alternatifleri kullanım amacına göre netleştiriyoruz.

Alternatif karşılaştırma tablosu

Let’s Encrypt ile prod kararını netleştirin

Let’s Encrypt prod için fiilen standart yaklaşımlardan biridir. Ancak “yeterli mi?” sorusu domain erişilebilirliğine ve doğrulama yöntemine bağlıdır.

Kontrol listesi: - Domain’in doğrulanabilir olması: A kaydı/erişim doğrulaması sorunsuz olmalı. - TLS kesintisi olmaması için renew süreci ve kontrol (validasyon) izlenmeli. - Gerekirse staging/test akışı: Yanlış ayarların gerçek trafiği etkilememesi gerekir.

Cloud/flare veya proxy kullanıyorsanız dikkat

CDN veya reverse proxy (ör. edge) kullanıyorsanız iki katman düşünün: - Edge tarafında sertifika “CA imzalı” olabilir. - Origin (sizin VDS/VPS sunucunuz) tarafında self-signed kalır.

Bu durumda kullanıcı uyarısı edge üzerinde ortadan kalkabilir; fakat origin ile konuşan sistemler (health check, botlar, bazı entegrasyonlar) self-signed nedeniyle hata üretebilir. Yani “kullanıcı görmüyor” her zaman “risk yok” anlamına gelmez.

Prod’da self-signed SSL kullanmayı bırakmak için net geçiş planı

Self-signed SSL’i prod’da kullanıyorsanız hedef; minimum kesintiyle CA imzalı sertifikaya geçmektir. Geçiş planını aşağıdaki adımlarla netleştirin.

1) Mevcut kullanımı envanterleyin

Önce şu soruların cevabını çıkarın: - HTTPS’e kimler bağlanıyor? (tarayıcı kullanıcıları, mobil uygulama, server-to-server) - Hangi endpoint’ler var? (web, API, webhook callback) - Hangi client’lar self-signed sertifikayı şu an nasıl kabul ediyor? (trust store ekli mi?)

2) Hedef sertifika türünü seçin

Genel web trafiği için CA imzalı (çoğunlukla Let’s Encrypt) seçin. İç ağ özel kullanımda private CA düşünülebilir. Self-signed’i “kalıcı” bir prod çözümü olarak planlamayın.

3) Kademeli geçiş (dual stack) uygulayın

Kesintiyi azaltan yaklaşım: - Yeni CA imzalı sertifikayı sunucuya kurun. - Reverse proxy varsa origin/edge konfigürasyonunu ayrı ayrı doğrulayın. - Test ortamında gerçek client akışlarını çalıştırın: login, ödeme akışı, webhook gönderimi, görsel/JS çağrıları.

4) Yenileme ve izlemeyi kurun

SSL sadece kurulum değildir. Prod için izleme gerekir: - Sertifika bitiş tarihini düzenli kontrol edin. - Renew/renewal hata durumlarını loglayın. - Otomasyon hatasında fallback planınız olsun (ör. geçici valid CA paketi).

Uygulamalı kontrol listesi: “Self-signed ile prod çalışır mı?”

Aşağıdaki soruları “evet” ya da “hayır” diye yanıtlayın.

• Kamuya açık kullanıcılar tarayıcıdan siteye giriyor mu? Evetse hayır.
• Üçüncü taraf entegrasyonlar sertifika hatasıyla başarısız oluyor mu? Evetse hayır.
• Entegrasyonlar dışında kalan tüm client’larınızın trust store güncellemesini merkezi yönetebiliyor musunuz? Hayırsa hayır.
• Sertifika yenileme ve dağıtım otomasyonunuz test edilmiş durumda mı? Hayırsa hayır.
• Kurumsal güvenlik/pinning/policy uygulayan müşteriniz var mı? Evetse hayır.

Bu maddelerin birden fazlası “hayır” çıkarsa self-signed prod kullanımının riski kabul edilemez seviyededir.

Sonuç: Prod’da self-signed SSL yerine CA imzalı sertifika standardını uygulayın

Self-signed SSL teknik olarak HTTPS sağlar ama prod ortamında güven uyarıları, entegrasyon uyumsuzluğu ve sertifika yenileme/dağıtım kaynaklı kesinti risklerini büyütür. En doğru aksiyon, prod domain’lerinde CA imzalı sertifikaya geçmek (öncelik Let’s Encrypt veya gereksinime göre private CA/kurumsal CA) ve yenileme-izleme süreçlerini yapılandırmaktır. Eğer şu an self-signed ile çalışıyorsanız, önce endpoint envanteri çıkarın, ardından kademeli geçiş planıyla sertifikayı CA imzalı hale getirin ve yenileme takibini otomasyona bağlayın.