eMudhra’nın küresel TLS sertifika altyapısında kullanılan sekiz ara sertifikayla ilişkili özel anahtarların zayıf üretildiği ortaya çıktı. anahtarları elde edebilecek saldırgan, teorik olarak güvenilir görünen sahte web sitesi sertifikaları düzenleyebilir veya etkilenen kod imzalama sertifikalarını kötüye kullanabilirdi. Google, Mozilla kök sertifika programları ilgili sertifikaları engellemek için önlemler. Broadcom bazı güvenlik cihazlarında Trust Package’in elle güncellenmesini istiyor.
Olay nasıl ortaya çıktı?Sorun, eMudhra’nın 30 Nisan 2025’te gerçekleştirdiği anahtar üretim süreciyle bağlantılı. Şirketin açıklamasına göre süreçteki wrap/unwrap adımı, güçlü anahtarların yanında ikinci zayıf anahtar seti oluşturdu. Kök sertifika depolarında yayımlanan anahtarlar zayıf setten geldi. eMudhra, anahtarların FIPS 140-2 Level 3 sertifikalı HSM’lerde üretildiğini sorunun HSM kullanılmamasından değil, anahtar üretim sürecindeki hatadan kaynaklandığını belirtiyor. Nihai kök neden incelemesi ise şirketin açıklamasına göre sürüyor.
CERT-In’in aktardığı teknik değerlendirmeye göre, etkilenen P-384 eliptik eğri anahtarlarının özel değerleri olması gerekenden çok daha küçüktü açık anahtar bilgilerinden elde edilebiliyordu. P-384 şifreleme algoritmasının kırıldığı anlamına gelmiyor; zafiyet, sertifikalar için anahtarların hatalı üretilmiş olmasından kaynaklanıyor.
Etkilenen sekiz ara sertifikanın altısı TLS, ikisi kod imzalama amacı taşıyordu. eMudhra, ara sertifikaların iptal edildiğini bunların son kullanıcı sertifikası düzenlemediğini bildiriyor. Google altı TLS ara sertifikasına zincirlenen sertifikaların, engelleme öncesinde Certificate Transparency kayıtlarında görünmediğini açıkladı. 22 Ekim itibarıyla kamuya açık kaynaklarda, anahtarların saldırganlar tarafından kötüye kullanıldığı doğrulanmış değil.
saldırgan zayıflıktan nasıl yararlanabilir?ara sertifika yetkilisinin (Intermediate CA) özel anahtarı, yetkilinin altındaki sertifikaları imzalamak için kullanılır. Anahtara sahip olan saldırgan, teorik olarak hedeflediği alan adı için sahte TLS sertifikası düzenleyebilirdi. İstemci sertifika zincirine hala güveniyorsa, bağlantı kurduğu sunucunun gerçek olduğuna inanabilirdi.
Böyle saldırının başarıya ulaşması için yalnızca sahte sertifika oluşturmak yeterli olmazdı. Saldırganın kurbanın bağlantısını kendi kontrolündeki sunucuya yönlendirebilmesi veya trafiğin arasına girebilmesi gerekirdi. örneğin DNS ya yönlendirme altyapısının ele geçirilmesi, güvensiz ağda trafiğin yönlendirilmesi veya başka araya girme imkanı üzerinden gerçekleşebilirdi. Sahte sertifika kabul edilirse saldırgan bağlantıdaki verileri görmeye veya değiştirmeye çalışabilirdi.
nedenle olay, her eMudhra sertifikası kullanan web sitesinin ele geçirildiği anlamına gelmiyor. etkilenen sertifika zincirine güvenmeye devam eden istemci saldırganın bağlantı trafiğine müdahale edebilme imkanının araya gelmesiyle oluşuyordu. Tarayıcıların sertifika engellemesi zincire güvenilmesini önlemek için devreye girdi. Google, Chrome’daki müdahalenin ara sertifika anahtarlarını temel alarak yapıldığını TLS ara sertifikalarına bağlı, engelleme öncesinde CT kayıtlarına girmiş sertifikalar görmediğini bildirdi.
İki kod imzalama anahtarının kötüye kullanılması ayrı risk oluşturuyordu: Saldırgan, imzalı görünen zararlı yazılımlarla güven algısı yaratmaya çalışabilirdi. yüzden kurumların yalnızca web tarayıcılarını değil, kod imzalama zincirlerini uygulama çalıştırma politikalarını gözden geçirmesi gerekiyor.
Hangi sistemler hizmetler etkilenebilir?Olay, eMudhra’nın küresel TLS güven zincirindeki belirli ara sertifikalarla sınırlı. CERT-In’e göre eMudhra’nın Hindistan’daki düzenlemeye tabi dijital imza sertifikası (DSC) eSign altyapısı olaydan etkilenmedi. eMudhra emSigner, CertiNext, emCA, PrivaTrust SecurePass hizmetlerinin ayrı altyapıda çalıştığını etkilenmediğini belirtiyor.
Doğrudan etkilenen güven zincirlerine ek olarak, tarayıcıların ilgili kök sertifikayı güven depolarından çıkarması meşru TLS sertifikalarında kesintiye yol açabilir. Google, emSign ECC Root CA – G3 kök sertifikasının Chrome Root Store’dan kaldırılmasının Chrome’un depoyu kullanan cihazlarına 27 Ekim 2026’ ulaşmasının beklendiğini duyurdu. eMudhra ise köke bağlı sertifikalar kullanan müşteri ekosistemi için geçiş yenileme çalışması yürüttüğünü söylüyor. Dolayısıyla kurumlar yalnızca “sertifikamız doğrudan etkilenen ara CA’dan ?” sorusunu değil, zincirin ilgili köke kadar uzanıp uzanmadığını kontrol etmeli.
Kurumlar hangi önlemleri almalı? 1. Tarayıcı işletim sistemi güncellemelerini uygulayınChrome, Firefox, Android istemciler için üreticilerin yayımladığı güvenlik güven deposu güncellemelerini yükleyin. Tarayıcıların güncel olması, uygulamaların veya sunucu işletim sistemlerinin aynı güven iptal bilgilerini aldığı anlamına gelmeyebilir. Özel CA deposu kullanan uygulamaları ayrıca değerlendirin.
2. Sertifika zincirlerini envanterleyinİnternete açık web siteleri, API uç noktaları, proxy bağlantıları kritik iç servislerde kullanılan TLS sertifikalarının issuer, ara CA kök CA bilgilerini kontrol. Sertifika zincirinde ilgili eMudhra ara sertifikaları veya emSign ECC Root CA – G3 bulunuyorsa, sertifikayı sağlayan tarafla görüşerek güvenilir başka PKI hiyerarşisinden yenileme planlayın.
Yenileme sonrasında yalnızca sertifikanın tarihine bakmayın; yeni sertifikanın gerçekten farklı güvenilen zincire bağlandığını doğrulayın.
3. Özel CA paketlerini ayrıca güncelleyinProxy’ler, ağ güvenlik cihazları, TLS kütüphaneleri, uygulama çalışma ortamları, container imajları gömülü cihazlar kendi CA paketlerini kullanabilir. sistemler tarayıcıların iptal listelerini otomatik olarak almayabilir. Üreticinin güven paketi güncellemesini uygulayın cihazın ilgili sertifika zincirini artık kabul etmediğini doğrulayın. CERT-In bağımsız CA depoları kullanan uygulama cihazların ayrıca incelenmesini öneriyor.
4. Kod imzalı dosyaları uygulama politikalarını gözden geçirinKritik uygulamaları çalıştırmadan önce imza durumunu, yayıncı bilgisini sertifika zincirini doğrulayın. İmzalı olması dosyanın tek başına güvenli olduğu anlamına gelmez. Kurumlar WDAC veya AppLocker gibi uygulama denetimlerini, yazılım dağıtım kaynaklarını dosya bütünlüğü kontrollerini gözden geçirebilir. Sertifika zincirinin iptal durumunu kontrol edin; doğrulama hatalarını geçici olarak yok sayan istisnalar tanımlamayın. CERT-In, kod imzalama güveninin kontrol edilmesini öneriyor.
5. CT kayıtlarını beklenmeyen sertifika değişikliklerini izleyinKurumun alan adları için Certificate Transparency (CT) kayıtlarını izlemek, beklenmeyen sertifika düzenlemelerini fark etmeye yardımcı. Ayrıca web sunucularındaki sertifika değişiklikleri, DNS kayıtları olağan dışı TLS doğrulama hataları takip edilmelidir. CT izleme ek tespit katmanıdır; CA iptalini veya güven deposu güncellemesini uygulamanın yerine geçmez.
6. TLS doğrulama kontrollerini kapatmayınSertifika hatası veren uygulamada doğrulamayı devre dışı bırakmak, saldırgan araya girdiğinde bağlantının uyarısız kurulmasına yol açabilir. Sorun varsa önce sertifika zincirini, cihazın saatini, DNS/proxy yapılandırmasını güven paketinin durumunu inceleyin; güvenlik denetimini kapatarak çalışmayı sürdürmeyin.
eMudhra olayı, anahtar üretimindeki zayıflığın sertifika otoritesinin güven zincirini nasıl etkileyebileceğini gösteriyor. Tarayıcı üreticileri etkilenen TLS ara sertifikalarını engelledi ilgili kök sertifikayı güven depolarından çıkarma sürecine başladı. Buna rağmen kurumsal uygulamalar, proxy cihazları özel CA paketleri güncel olmayabilir. Kurumlar güven depolarını yenilemeli, sertifika zincirlerini envanterlemeli, köke bağlı geçerli sertifikalar için geçiş planı yapmalı kod imzalama doğrulamasını kontrol etmelidir. Kamuya açık kaynaklarda an için doğrulanmış kötüye kullanım bulunmaması, kontrollerin ertelenmesi gerektiği anlamına gelmiyor.
Kaynaklar- CERT-In: Compromise of eMudhra Intermediate CA Certificates
- Google: Protecting Chrome and Android Users
- eMudhra: Security Incident Statement
- Mozilla Bugzilla: eMudhra Intermediate Certificate Key Compromise
