← Blog

BİR GÜNCELLEME SİZİ NASIL SESSİZCE SSL'SİZ BIRAKABİLİR

Bir platform güncellemesi, web sunucusu yapılandırmasını sıfırlarken geçerli SSL sertifikasını da eski/süresi dolmuş haline döndürdü. Container içindeki config'i bulup düzeltmemiz, müşteri fark etmeden dakikalar sürdü.

Bir kurumsal müşteride rutin bir platform güncellemesi (kategorizasyon motoru güncellemesi) sorunsuz tamamlandı — servisler yeniden başladı, veri akışında görünür bir kesinti yoktu. Ama güncelleme sessiz bir yan etki bırakmıştı: web sunucusunun (nginx) yapılandırma dosyalarını yeniden oluştururken, güncel SSL sertifikasını da varsayılan/eski haline döndürmüştü.

Belirti: tarayıcıda "sertifika geçersiz"

Güncellemeden kısa süre sonra platforma tarayıcıdan erişilmeye çalışıldığında "bağlantınız güvenli değil" uyarısı çıktı. Sertifika süresi haftalar önce dolmuştu — güncel, geçerli bir sertifika zaten yüklüydü ama güncelleme işlemi onu görmezden gelip kendi varsayılanına dönmüştü.

Kök neden: config drift, container içinde

Platform, web servisini bir Docker container'ı içinde çalıştırıyordu; SSL yapılandırması host makinedeki bir dizine mount edilmişti. Güncelleme betiği, nginx config'ini yeniden üretirken bu mount noktasındaki sertifika referansını da üzerine yazmış, sonuç olarak eski/süresi dolmuş sertifika dosyası devreye girmişti.

Bu, otomatik güncellemelerin klasik bir yan etkisi: güncelleme kendi değiştirdiği dosyaları doğru varsayıyor, ama config'in bir kısmı elle/harici olarak yönetiliyorsa güncelleme onu "eski hâline" sıfırlayabilir.

Düzeltme

  • Container'ın SSL config yolu tespit edildi.
  • Yedeklenmiş güncel sertifika dosyaları (asıl geçerlilik süresi aylarca yeterliydi) tekrar yüklendi.
  • Web servisi reload edildi, bağlantı test edildi.
  • Ertesi gün müşteri tarafında da tekrar doğrulandı — sorun yoktu.

Tüm müdahale, müşteri fark etmeden, dakikalar içinde tamamlandı.

Çıkarımlar

  • "Güncelleme sorunsuz tamamlandı" mesajı, yan etkisiz demek değildir. Her güncelleme sonrası kritik config'lerin (SSL, DNS, firewall kuralları) hâlâ beklendiği gibi olduğunu doğrulamak ayrı bir adım olmalı.
  • Container tabanlı servislerde config drift daha sinsi ilerler. Host'taki bir dosya, container içindeki bir process tarafından beklenmedik şekilde yeniden yazılabilir — mount noktalarını ve kimin neyi yönettiğini net tutmak gerekir.
  • Yedekleme disiplini, "sessiz" arızaların hızlı çözümünün anahtarıdır. Güncel sertifikanın bir yedeği hazır olduğu için düzeltme dakikalar sürdü, saatler değil.
  • Otomatik güncellemelere temkinli yaklaşın. Özellikle prod ortamında, güncelleme sonrası hızlı bir "kritik yüzeyler" kontrol listesi (SSL, erişim, temel işlevsellik) çalıştırmak, müşteriden önce sorunu yakalamanın en ucuz yolu.

Bu konuda daha fazla bilgi almak ister misiniz?

Yazıda anlatılan çözümü kendi altyapınızda da hayata geçirmek ya da benzer bir ihtiyacı konuşmak isterseniz, ekibimizle iletişime geçin.

Bize ulaşın →