Prod ortamda self-signed SSL kullanılır mı? Riskler ve net karar

Prod ortamda self-signed SSL (kendi imzanızla oluşturulmuş sertifika) kullanmak teknik olarak mümkündür; ancak “çalışır mı?” sorusunun cevabı tek başına yeterli değildir. Asıl mesele; güven zincirinin kırılması, tarayıcı ve istemci tarafında sürekli uyarı üretmesi, bazı otomasyonların hata vermesi ve doğrulama/izleme süreçlerinin zayıflamasıdır. Bu rehberde prod’da self-signed SSL’in hangi riskleri doğurduğunu, hangi koşullarda kesinlikle kullanılmaması gerektiğini ve güvenli alternatiflere geçiş için net adımları okuyacaksınız.

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

Self-signed SSL’de sertifikanın doğrulaması, genellikle “güvenilir sertifika otoriteleri (CA)” zinciri üzerinden yapılmaz. Tarayıcılar ve çoğu istemci yazılım, sertifikanın bir CA tarafından imzalanmasını bekler. Bu nedenle self-signed sertifikada standart davranış; istemci tarafında “sertifika güvenilmiyor” uyarısıdır.

Bu uyarılar sadece kullanıcıyı rahatsız etmekle kalmaz; aynı zamanda iş akışlarını doğrudan etkiler:

• İnsan trafiği düşer: Üst üste gelen uyarılar satış/başvuru akışını bozar.
• API istemcileri kırılır: Bazı istemciler “SSL doğrulaması kapatılsın” seçeneğini ya yok sayar ya da güvenlik politikası nedeniyle izin vermez.
• Tarayıcı otomasyonları başarısız olur: Headless tarayıcılar (ör. Playwright/Selenium) hata vererek akışı kesebilir.
• İzleme ve sağlık kontrolleri (health check) alarm üretir: Basit TLS kontrolü yapan sistemler hatalı durum döndürür.
• Kimlik doğrulama zayıflar: Self-signed sertifikada “bu sunucu gerçekten bu domain mi?” sorusu CA doğrulaması olmadan daha kırılgan hale gelir.

Tarayıcı uyarıları: Sadece görsel değil, operasyonel etkidir

Uyarı sayfası kullanıcıda “güvensiz site” hissi yaratır. Bunun prod’daki etkisi; örneğin aynı kullanıcı tekrar denemeden vazgeçebilir ya da ödeme/oturum açma adımlarına gelmeden akışı terk edebilir.

Öte yandan, prod’da kullanılan bazı servisler (ör. backend’in kendi içindeki servisler arası çağrılar) “sertifika doğrulamasını kapat” yaklaşımıyla yönetilirse bu kez güvenlik seviyesi görünürde düşer.

Sertifika doğrulama zafiyeti: CA zinciri yok

Self-signed SSL’de sertifika, sizin kontrol ettiğiniz bir anahtar ile imzalanır. Ancak çoğu istemci için “güvenilir” demek, sertifikanın tanınan bir CA tarafından imzalandığı anlamına gelir. CA doğrulaması olmadığında:

• İstemci “sertifika doğru mu, değil mi?” kararını otomatik veremez.
• Güven ayarlarını istemciye özel yapmak gerekir.
• Organizasyon içinde farklı istemciler farklı davranır; bu da tutarsız hata üretir.

Prod’da self-signed SSL ne zaman “kabul edilebilir”? (Net sınırlar)

Self-signed SSL’in bazı dar kullanım alanları vardır. Ancak “prod” kelimesi geniş bir kapsam ifade ettiğinden, kriterleri net koymak gerekir.

Aşağıdaki durumlarda self-signed SSL kabul edilebilir değildir:

• Müşterilerin tarayıcıyla eriştiği public web sitesi
• Ödeme, kimlik doğrulama, kullanıcı hesabı gibi güvenin kritik olduğu akışlar
• Tarayıcı/istemci uyarısını azaltmak için “manuel exception” beklenen senaryolar
• Üçüncü taraf entegrasyonların (ERP/CRM/otomasyon botları) TLS doğrulaması yapabildiği sistemler

Aşağıdaki durumlarda ise “kullanımın etkisi sınırlıdır”, ama yine de planlı olmak şartıyla mümkündür:

• İntranet veya kapalı ağda, erişim yalnızca belirli bileşenlere yönelik tam kontrollü ortamlar
• Sertifikayı istemcilerin tamamında doğru şekilde trust store’a ekleyebildiğiniz kurumsal senaryolar
• Harici kullanıcıya/SEO’ya açık olmayan, geçici test veya kısa süreli migration dönemi

Önemli: “Kabul edilebilir” dediğimiz senaryolarda bile üretimde self-signed SSL ile risk, tamamen sıfırlanmaz; sadece etkisi kontrollü olur.

En yaygın riskler: Ne bozulur, hangi hatayı görürsünüz?

Aşağıdaki riskler prod’da daha sık görünür çünkü altyapı bileşenleri (CDN, WAF, load balancer, uygulama istemcileri, log/monitoring) TLS doğrulamasını farklı şekillerde uygular.

1) Tarayıcı kaynaklı güven uyarısı ve terk oranı

• Chrome/Firefox gibi tarayıcılar self-signed sertifikayı “güvenilmiyor” olarak işaretler.
• Kullanıcı “devam et” yapsa bile bu akış izlenmesi zorlaşır (A/B test, funnel metrikleri bozulur).

2) API istemcilerinde certificate verify failed

Bazı istemciler TLS doğrulamasını zorunlu tutar. Bu durumda şu tür hatalar oluşur:

• certificate verify failed
• self signed certificate
• x509: certificate signed by unknown authority

Bu hatalar; uygulama hatası değil, TLS katmanı reddi olduğu için loglarda kök neden zor bulunabilir.

3) Otomasyon ve cron tabanlı kontrollerin alarm üretmesi

Prod’da otomatik sağlık kontrolleri sık kullanılır. Self-signed SSL varsa:

• Monitor sistemleri TLS check başarısız sayabilir.
• Otomasyon, yeniden deneme (retry) döngüsüne girip servisleri gereksiz yükleyebilir.

Not: Benzer şekilde “cron çalışmıyor” gibi görünen sorunlar bazen aslında TLS doğrulama kaynaklı çağrı başarısızlığı olabilir.

4) Load balancer/CDN/WAF katmanında uyumsuzluk

CDN veya reverse proxy kullanan sistemlerde TLS sonlandırma (termination) nerede yapıldığı kritik olur:

• CDN ile origin arasında self-signed kullanırsanız, CDN tarafı sertifikayı kabul etmeyebilir.
• WAF/edge güvenlik kuralları “unknown CA” ile alarm üretebilir.

5) Sertifika yenileme ve etkisiz kalma riski

Self-signed sertifikada yenileme planı olmazsa:

• Sertifika tarihi dolduğunda tüm istemciler anında etkilenir.
• Bazı sistemlerde geçiş süreci “manuel müdahale”ye döner.

Prod’da sertifika yaşam döngüsü (validity, renewal, rollout) otomasyona bağlanmalıdır.

Riskleri sayısallaştırmak: Hangi metrikleri izlemeniz gerekir?

Self-signed SSL’in prod’daki etkisini yönetmek için “teknik mi kullanıcı mı” ayrımını yapın. En pratik metrik seti:

• İstek başarımı: 2xx/3xx oranı (TLS handshake reddi varsa 4xx/5xx artar)
• Tarayıcı hataları: Uyarı tetiklenen kullanıcı sayısı (RUM/analytics)
• API hata oranı: TLS doğrulama hataları (özellikle x509 kök neden)
• Health check durumu: Monitor ekranında “TLS failing”
• Ortalama yeniden deneme sayısı: Retry yapan joblar servisleri yormaya başlayabilir

Güvenli alternatifler: Prod için net öneri

Prod’da self-signed SSL yerine aşağıdaki alternatifler doğru seçimdir.

1) CA tarafından imzalanmış sertifika (zorunlu seçenek)

En standart yaklaşım, tarayıcıların otomatik güvendiği bir CA’dan sertifika kullanmaktır.

• Domain doğrulaması (DV) genellikle yeterlidir.
• Sertifika otomatik yenilenebilir olmalıdır.

2) İç servisler için özel trust (mümkünse)

Eğer mesele “sadece servisler arası şifreli iletişim” ise:

• İç CA ile imzalı sertifika (internal CA) kullanın.
• Uygulama istemcilerinde trust store doğru yapılandırılsın.

Bu yaklaşım, public tarayıcı uyarısını üretmez; ama yine de internal CA’nın yaşam döngüsü yönetilmelidir.

3) Hızlı geçiş için pratik yöntem

Prod’da dönüşümün “kesintisiz” olmasını hedefleyin:

• Mevcut endpoint’i aynı anda iki sertifikayla ele almak (mümkün olan senaryolarda)
• Reverse proxy/load balancer katmanında CA sertifikaya geçmek
• “Rollout planı” hazırlamak: önce staging, sonra kademeli prod

Self-signed SSL’den çıkış planı (uygulanabilir kontrol listesi)

Aşağıdaki adımlar; prod’da riski azaltacak şekilde sırayla ilerler.

1) TLS sonlandırmanın nerede olduğunu netleştirin

Şunları çıkarın:

• HTTPS trafiği hangi katmanda sonlanıyor? (origin server, reverse proxy, load balancer)
• CDN kullanıyorsanız “edge ile origin” arasında TLS var mı?

Bu bilgi olmadan sertifika değişimi bazen beklenmedik hatalara yol açar.

2) Staging’de aynı istemci tipleriyle doğrulayın

Sadece curl ile değil, prod’u temsil eden istemcilerle test yapın:

• Tarayıcı (Chrome/Firefox)
• Uygulama içi istemci (backend’in backend’e çağrıları)
• Health check aracı
• Otomasyon jobları

3) Sertifika yenilemesini otomatikleştirin

Prod’da self-signed SSL’in en büyük riski, yenilemenin unutulmasıdır. Yeni sertifikada:

• Otomatik renewal mekanizması kurun.
• Yenileme loglarını izleyin.

4) Kademeli geçiş ve geri dönüş planı oluşturun

• Gün içinde düşük trafikli saat belirleyin.
• Geri dönüş için mevcut sertifikanın yedek kopyası ve konfigürasyon dosyaları hazır olsun.

Karar çerçevesi: “Self-signed SSL prod’da kullanayım mı?”

Aşağıdaki tablo, hızlı karar vermenizi sağlar.

Sonuç: Prod’da self-signed SSL’i “planlı değilse” kullanmayın

Self-signed SSL prod’da çalışabilir; ancak prod’un hedefi sadece “şifreleme” değil, istemci güveni, otomasyon uyumu ve operasyonel sorunsuzluktur. Kullanıcıların tarayıcıyla eriştiği her senaryoda self-signed SSL kullanmayın; bunun yerine CA imzalı sertifikaya geçin. Eğer konu dahili servisler arası iletişimse, self-signed yerine internal CA + doğru trust store yapılandırmasıyla ilerleyin. Bugün mevcut sisteminizde TLS sonlandırmanın nerede yapıldığını netleştirip, staging’de aynı istemci setiyle test ederek sertifika geçiş planını başlatın.