eMudhra/emSign Sertifika Skandalı: Sekiz Ara CA'nın Zayıf Anahtar Üretimi

 

Anahtar üretim törenindeki hata nedeniyle sekiz ara sertifika otoritesinin özel anahtarları hesaplanabilir seviyede zayıf üretildi; tarayıcılar güncellendi ama sunucular, CI/CD hatları ve IoT cihazları hâlâ risk altında

 

1. Olayın özü

17 Ekim 2026'da açıklanan olay, eMudhra'nın emSign altyapısı altındaki sekiz ara sertifika otoritesinin (ara CA) özel anahtarlarının, Nisan 2025'teki anahtar üretim sürecindeki bir hata nedeniyle gereken entropiye sahip olmadan üretilmesidir. Bu durum, anahtarları bilen herhangi birinin herhangi bir web sitesi veya servis için geçerli görünen sertifika üretebilmesine yol açabiliyor; olay açıklandıktan sonra etkilenen sertifikalar geçersiz kılındı.

2. Neden ciddi bir risk

Ara CA'nın özel anahtarı, güven zincirinin tamamını taşır: bu anahtar ele geçirilirse (veya burada olduğu gibi zayıf üretilirse) saldırgan, herhangi bir alan adı için tarayıcıların kabul edeceği sahte sertifikalar üretebilir. Orta adam saldırısının (MITM) teknik altyapısı eline geçmiş olur.

3. Tarayıcılar güncellendi — ama yeterli mi?

Hayır. Google, Mozilla, Apple ve Microsoft etkilenen sertifikaları platformlarından engelledi. Ancak tarayıcıların dışında kalan sunucular, API entegrasyonları, VPN'ler, CI/CD hatları, container imajları ve gömülü/IoT sistemleri kendi yerel güven deposunu kullanır ve sertifika iptal kontrolü yapmaz. Bu ortamlarda risk devam ediyor ve çoğu kurumun bunları envanterinde görünür tutmadığı bilinen bir zaaf.

4. TISAX Madde 5.1.1 bağlamı

Kriptografik envanter tutma yükümlülüğü tam da bu senaryo için yazılmış: bir güven zincirindeki halkanın bozulduğu durumda kurumun kullandığı sertifikaları ve güven depolarını biliyor olması gerekir. Envanteri olmayan kurum, etkilenip etkilenmediğini bile doğrulayamaz. İlgili referanslar: CVE-2026-111943 (Go tarafı), Red Hat advisory RHSA-2026:88560.

5. Yapılması gerekenler

  • Envanter taraması: Kullanımdaki TLS sertifikalarının ve güven zincirlerinin eMudhra/emSign ara CA'larına dayanıp dayanmadığını kontrol edin; etkilenen sertifikaları etkilenmeyen bir CA'dan yenileyin.
  • Güven depolarını güncelleyin: İşletim sistemi ca-certificates paketleri, Python certifi, Node.js, Go ve container temel imajlarını güncelleyin; güncellemelerin yeniden başlatma ve imaj yeniden derleme ile etkinleştiğinden emin olun.
  • Tarayıcı dışı bağlantıları test edin: Sunucudan sunucuya API çağrıları, VPN bağlantıları ve gömülü cihazlarda sertifika doğrulamanın hâlâ çalıştığını doğrulayın. Güncelleme mümkün değilse trafiği izlemek pratik bir telafi kontrolüdür.
  • Doğrulamayı kapatmayın: Güncelleme sonrası çıkan sertifika hatalarını çözmek için doğrulamayı devre dışı bırakmayın; bu, korumayı tamamen ortadan kaldırır.
  • Değişikliği kayda geçirin: Güncelleme ve yenileme işlemlerini değişlik yönetimi kayıtlarına işleyin — TISAX değerlendirmelerinde Madde 5.1.1 için doğrudan delil olarak kullanılabilir.

TLS Sertifika eMudhra emSign PKI TISAX Güvenlik Açığı