eMudhra Sertifika Otoritesinde Anahtar Sızıntısı: 8 Ara Sertifika Engellendi, Sunucularda ca-certificates Güncellemesi Şart

Ne oldu? (What happened)

Cisco Talos'un 21 Ekim tarihli açıklamasına göre sorun 30 Nisan 2025'te, eMudhra'nın emSign G3 kökleri altında 24 alt sertifika otoritesi için yaptığı anahtar üretim töreninde başladı. Anahtarların sarılıp açıldığı (wrap/unwrap) adımdaki bir hata, ikinci ve çok zayıf bir P-384 anahtar seti oluşturdu. Bu zayıf anahtarlar yanlışlıkla sekiz ara sertifikada kullanıldı. Talos'a göre anahtarların rastgeleliği olması gereken 384 bitten yaklaşık 3–8 bite düştü; bazı özel anahtarların tek ya da iki basamaklı sayılar olduğu bildirildi. Yani anahtar, herkese açık sertifikadan bir saniyeden kısa sürede hesaplanabiliyor.

Etkilenen sekiz ara sertifikanın altısı TLS, ikisi kod imzalama sertifikası:

• EM EV / OV / DV TLS CA - G3B (eMudhra BV)
• EM EV / OV / DV TLS CA - G3C (eMudhra Inc)
• EM OV CS CA - G3B ve EM OV CS CA - G3C (kod imzalama)

Sorunu bir araştırmacı 17 Ekim'de kök sertifika programlarına bildirdi. Chrome aynı akşam CRLSet ile, Mozilla birkaç saat sonra OneCRL ile engeli devreye aldı. Apple ve Android 19 Ekim'de, Microsoft 20 Ekim'de engelledi. eMudhra sekiz sertifikayı 19 Ekim'de iptal etti. Mozilla 20 Ekim'de emSign ECC Root CA - G3 kökünü NSS'ten çıkardı. eMudhra, sekiz ara sertifikadan yalnız birinin üretimde kullanıldığını ve hiçbirinin son kullanıcı sertifikası vermediğini söylüyor. Kötüye kullanım görüldüğüne dair bir kayıt şu an yok, ama anahtar herkesin hesaplayabileceği durumda olduğu için bu güvence yetmiyor.

Risk kimde? (Who is exposed)

Güncel tarayıcı kullanan bir ziyaretçi için risk büyük ölçüde kapandı. Açıkta kalanlar, sertifika iptal listelerini okumayan ve kendi sertifika deposunu taşıyan yazılımlar:

• Sunucudan dışarı istek atan uygulamalar: PHP'nin cURL ile ödeme kuruluşuna, kargo firmasına ya da e-fatura servisine bağlanması, Node.js ve Go servislerinin API çağrıları. Ağ yolunu ele geçiren bir saldırgan bu bağlantılara sahte sertifikayla araya girebilir.
• Kendi CA paketini taşıyan kütüphaneler: Python certifi, Rust webpki-roots, Composer ca-bundle, Java'nın cacerts deposu.
• VPN istemcileri, proxy ve yük dengeleyiciler, gömülü cihazlar ve IoT donanımı.
• Electron tabanlı masaüstü uygulamaları ve paket yöneticileri.

Talos'un uyarısı açık: kilit dosyası (lockfile) özetleri, imza ve kaynak doğrulaması kullanan derleme hatları ek bir koruma sağlıyor, ama yalnız TLS'ye güvenen indirme adımları risk altında.

Hangi güncellemeler çıktı? (Vendor fixes)

Red Hat bülteninin durumu "devam ediyor" olarak görünüyor; Java ve Perl Mozilla::CA gibi bileşenler için güncellemeler peyderpey geliyor. Kendi kullandığınız dağıtımın ve çalışma ortamının bültenini ayrıca kontrol edin.

Sunucuda ne yapmalı? (What to do on servers)

Linux sunucularda ilk adım sistem sertifika deposunu güncellemek:

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

# RHEL / AlmaLinux / Rocky
sudo dnf update ca-certificates
rpm -q ca-certificates

Ardından uygulama katmanına geçin:

• Node.js: node -v ile sürümü kontrol edin, 26.12.1 / 24.22.1 / 22.23.4 ya da üstüne geçin. Node kendi CA listesini taşıdığı için yalnız sistem paketi yetmez. Ayrıntılar için Node.js 26 LTS geçiş rehberi.
• Go ile derlenmiş araçlar: Go 1.27.3 / 1.26.10 ile yeniden derlenmesi gerekiyor; ikili dosya olarak indirdiğiniz araçların yeni sürümlerini bekleyin.
• PHP: projede composer/ca-bundle kullanılıyorsa composer update composer/ca-bundle ile 1.6.0'a çıkın. cURL sistem deposunu kullanıyorsa yukarıdaki paket güncellemesi yeterli.
• Python: pip install -U certifi ile 2026.10.19 ya da üstüne geçin.
• Java: JDK'nın güncel güvenlik sürümüne geçin; kendi cacerts dosyanızı yönetiyorsanız emSign G3 zincirini oradan çıkarın.

Güncellemeden sonra uzun süre çalışan süreçleri yeniden başlatmayı unutmayın; sertifika deposu çoğu çalışma ortamında açılışta okunur. Alesta WEB olarak önerdiğimiz sıra şu: önce sistem paketi, sonra Node ve uygulama paketleri, en sonda servislerin yeniden başlatılması ve dışarıya bağlanan işlerin (ödeme, kargo, e-fatura) birer kez denenmesi.

Konteyner ve CI ortamları (Containers and CI)

Docker imajları ana makinedeki sertifika deposunu değil, imajın içindekini kullanır. Temel imajlar güncellendikten sonra imajlarınızı yeniden derleyin; FROM satırında sabit bir eski etiket kullanıyorsanız güncel etikete geçin. Docker Desktop 22 Ekim'de çıkan 4.96.3 sürümünde ele geçirilen ara sertifikalara güveni kaldırdı. CI çalıştırıcılarında (runner) da aynı paket güncellemesi ve imaj yenilemesi gerekiyor.

Kendi sitenizin sertifikası eMudhra'dan değilse ziyaretçi tarafında yapmanız gereken bir şey yok. Sertifikanızın kimden alındığını ve ne zaman yenileneceğini SSL kontrol aracı ile görebilirsiniz. Önümüzdeki dönemde sertifika ömürlerinin kısalmasıyla ilgili değişiklik için Let's Encrypt 64 günlük sertifika yazısına bakabilirsiniz.

Sık sorulan sorular

Sitemin sertifikası eMudhra'dan değil, etkilenir miyim?

Sitenizin sertifikası etkilenmez. Risk, sizin sunucunuzun dışarıya yaptığı bağlantılarda: güncellenmemiş bir sertifika deposu, saldırganın ürettiği sahte sertifikayı geçerli sayabilir.

Bu bir yazılım açığı mı?

Hayır. Red Hat'in de belirttiği gibi bu bir sertifika otoritesinin anahtar sızıntısı. Açılan CVE kayıtları, sertifika depolarına yapılan güvensizlik güncellemelerini izlemek için kullanılıyor.

Tarayıcım güncel, başka bir şey yapmam gerekiyor mu?

Tarayıcı için hayır. Ama aynı bilgisayarda VPN istemcisi, Electron tabanlı uygulamalar ya da geliştirme araçları varsa onların güncellemelerini de yükleyin.

İlgili yazılar: OpenSSH 10.6 · PHP 8.6 · Web hosting · İletişim

Kapak fotoğrafı: Lacz02 / Wikimedia Commons (CC BY-SA 4.0)