eMudhra CA Anahtarlarının Ele Geçirilmesi: Şirketlerin Şimdi Kontrol Etmesi ve Düzeltmesi Gerekenler

17 Ekim 2026 Cumartesi günü bir güvenlik araştırmacısı, Hindistanlı sertifika otoritesi eMudhra'nın işlettiği sekiz ara sertifika otoritesinin (intermediate CA) özel anahtarlarının, herkese açık sertifikalardan herkes tarafından hesaplanabildiğini bildirdi. Anahtarların her biri 256'dan küçük bir sayıydı. Biri 4 sayısıydı. Sekizden altısı Apple, Google, Microsoft ve Mozilla'nın güvendiği TLS sertifikaları verebiliyordu; diğer ikisi Windows yazılımı imzalayabiliyordu.

Chrome altı TLS anahtarını bildirimden bir saat kırk dakika sonra engelledi, Firefox da aynı akşam. Web'de gezinen kullanıcılar için tehlike cumartesi gecesine kadar geçmişti.

Geri kalan her şey için ise geçmemişti. Sunucular, container'lar, Java uygulamaları, Python betikleri, ödeme entegrasyonları ve bağlantılı cihazlar sertifikaları, güvenilen otoriteler listesinin kendi kopyalarına göre kontrol eder ve bu kopyaların çoğu ancak biri bir güncelleme kurduğunda değişir. O zamana kadar bu anahtarlardan biriyle imzalanmış, herhangi bir alan adına ait bir sertifika gerçek kabul edilir; anahtarlar ise 20 Ekim'den beri herkese açık.

Aynı hafta GoDaddy, içerdikleri politika bilgileri kendi yayımladığı belgelerle uyuşmadığı için 404.607 sertifikayı iptal etmeye başladı. Müşterilerinin yeni sertifikaları kendileri indirip kurması gerekti.

Bu rehber, “etkileniyor muyuz?” sorusunu yanıtlamak zorunda olanlar için: BT ve operasyon sorumluları, CTO'lar ve işi bir web sitesine, bir API'ye ya da bağlantılı bir ürüne dayanan kurucular. Rehber şunları ele alıyor: Mozilla, Google, eMudhra, GoDaddy ve yazılım üreticilerinin yayımladığı olay kayıtlarına dayanarak ne olduğu; bugün neyin kontrol edilmesi gerektiği; bu hafta neyin güncellenmesi gerektiği; ve bu türden bir sonraki olayın rutin bir iş olması için neyin hazırlanması gerektiği. Buradaki her bilgi 22 Ekim 2026 itibarıyladır ve olay hâlâ kapanmadı.

Ne Oldu?

eMudhra sekiz ara sertifikayı 30 Nisan 2025'teki bir anahtar töreninde (key ceremony) oluşturdu. Şirketin 19 Ekim'de Mozilla'nın olay kaydına yazdığı açıklamaya göre, olağan prosedürden sapma olarak onaylanan bir anahtar sarmalama ve açma (key wrap/unwrap) adımının testindeki bir hata, donanım güvenlik modülünde (HSM) amaçlanan anahtarların yanında ikinci, zayıf bir anahtar seti oluşturdu. Etiketler birbirine benziyordu, sertifika talepleri yanlışlıkla zayıf anahtarlarla oluşturuldu ve eMudhra'nın kök sertifikası bunları imzaladı. Aynı talepler Sectigo'ya da gitti; Sectigo 14 Mayıs 2025'te sekizini de AAA Certificate Services kök sertifikasından çapraz imzaladı. eMudhra, “kesin kök nedeni henüz doğrulamadığını” söylüyor.

Mozilla sonucu şöyle anlattı: “P384 özel anahtarları, 1 ile grup mertebesi arasında rastgele seçilen tam sayılardır. Etkilenen 8 anahtarın tamamı 256'dan küçük tam sayılar kullanıyordu.” Mozilla bildirimi 20:06 UTC'de aldı ve anahtarları 21:48'de “ilk bildiren kişinin kullandığı yöntem hakkında hiçbir bilgi olmadan” kendisi ortaya çıkardı. Araştırmacı, anahtarları Google'ın açık kaynak paranoid_crypto kütüphanesiyle “kutudan çıktığı haliyle” bulduğunu söylüyor. Zayıf anahtarlar neredeyse 18 aydır herkesçe güvenilen sertifika zincirlerinin parçasıydı.

Sekiz sertifika:

Her anahtar iki sertifikada yer alıyor. Birini eMudhra'nın, emSign ECC Root CA - G3 kök sertifikasına zincirlenen emSign Root TLS CA - G3 ya da emSign Root CS CA - G3 sertifikası verdi; diğeri Sectigo'nun AAA Certificate Services kök sertifikasından verdiği çapraz sertifika. İkinci yol önemli, çünkü hiçbir zaman eMudhra kök sertifikası içermemiş bazı güven depoları (trust store) bu eski Sectigo kök sertifikasına hâlâ güveniyor.

Saldırıya Uğrayan Oldu mu?

Kötüye kullanım bildiren olmadı ve tarayıcılar söz konusu olduğunda hiç olmadığını düşünmek için iyi bir neden var. Chrome, Certificate Transparency (CT, sertifika şeffaflığı) zorunluluğu uygulayan diğer istemciler gibi, bir sertifikayı yalnızca herkese açık CT loglarına kaydedilmişse kabul ediyor. Google'a göre engellemeden önce bu altı ara sertifikaya zincirlenen hiçbir TLS sertifikası loglanmamıştı; dolayısıyla “bu CA'ların verdiği hiçbir sahte sertifika, CT zorunluluğu uygulayan istemcilere karşı kullanılamazdı”.

Tarayıcının dışında tablo farklı. Mozilla'nın olay sayfasında şöyle deniyor: “tarayıcı ekosisteminin dışındaki birçok istemci Certificate Transparency zorunluluğu uygulamıyor. Saldırganların hatalı anahtar üretimini bu istemcileri hedef almak için istismar edip etmediğini bilmiyoruz.” Bu pencere 2025 baharında açıldı ve her istemci için ancak o istemci güncellendiğinde kapanıyor. eMudhra, anahtarların açıklamadan önce elde edildiğine dair herhangi bir kanıttan haberdar olmadığını söylüyor; Cloudflare da yaptığı incelemede kendi hizmetlerinde aktif bir istismar bulmadığını söylüyor.

Anahtarlar artık herkese açık olduğundan sahte sertifika üretmek hiçbir uzmanlık gerektirmiyor. Mozilla'nın olay sayfası, ele geçirilmiş anahtarlarla verilmiş sertifikalar sunan test sunucularını listeliyor; böylece herkes kendi istemcilerini bunlara karşı deneyebilir (komutlar aşağıda).

Sahte bir sertifikanın neye olanak tanıdığı şu: yazılımınız ile çağırdığı bir hizmet arasındaki trafiğin arasına girebilen biri (paylaşılan bir ağda, ele geçirilmiş bir yönlendirici ya da zehirlenmiş bir DNS yanıtı aracılığıyla) o hizmetin kimliğine bürünebilir, yazılımınızın gönderdiklerini (API anahtarları ve kişisel veriler dahil) okuyabilir ve aldıklarını değiştirebilir. İki kod imzalama anahtarından biriyle imzalanmış bir yazılım, Microsoft'un engellemesi makineye ulaşana kadar Windows imza denetiminden geçerdi.

Kimler Etkileniyor?

Birbirinden ayrı üç sorun var ve bir şirket üçünü birden yaşayabilir.

1. Ele geçirilmiş anahtarlara hâlâ güvenen yazılımlar

Bu sorun neredeyse her şirkette var: güven deposu hâlâ emSign ECC Root CA - G3 ya da AAA Certificate Services içeren ve sekiz anahtar için bir engelleme almamış, HTTPS çağrısı yapan her program. Tipik yerler:

• 20 ya da 21 Ekim'den önce kurulmuş Linux sunucuları ve oluşturulmuş container imajları. Örneğin yamasız bir Debian 12 her iki zincire de güveniyor.
• Kendi listesiyle gelen dil çalışma ortamları (runtime): Node.js, Python'da certifi, Java'da cacerts, PHP'de Composer'ın CA paketi, Rust'ta webpki-roots.
• macOS komut satırı araçları. Mozilla'nın olay sayfasına göre yerleşik curl, git, python3, perl, ruby ve openssl, sertifikaları iptal durumunu denetlemeden /etc/ssl/cert.pem dosyasına göre doğruluyor ve Apple bu dosyayı güncellemedi.
• Microsoft'un izin verilmeyen sertifikalar listesine yönelik otomatik güncellemelerini almayan Windows makineleri; bunun nedeni genellikle Grup İlkesi'nin bu güncellemeleri kapatması ya da ağın çevrimdışı olmasıdır.
• Kendi CA dosyasını içinde taşıyan hazır cihazlar (appliance), diğer cihazlar ve üçüncü taraf yazılımlar; örneğin yük dengeleyiciler, VPN ağ geçitleri, SDK'lar ve gömülü denetleyiciler.

Her çalışma ortamının ayrı ayrı kontrol edilmesi gerekiyor. 22 Ekim'de yaptığımız bir testte, Node.js 24.18 çalıştıran yamasız bir Debian 12 makinesi eMudhra'nın kök sertifikasında biten zinciri kabul etti, Sectigo'nunkinde biteni reddetti; aynı makinedeki Python ise ikisini de kabul etti.

2. Kendi sertifikaları kaldırılan kök sertifikaya zincirlenen şirketler

Mozilla ve Linux dağıtımları emSign ECC Root CA - G3 kök sertifikasını kaldırdı; Chrome da 27 Ekim'de onları izliyor. Bu kökün altındaki geçerli sertifikalar, her istemcide o istemci güncellendikçe çalışmaz hale geliyor. Google'ın talimatı: böyle sertifikaları olan web sitesi işletmecileri “Chrome Root Store'a dahil olan başka bir PKI hiyerarşisinden derhal yeni bir TLS sertifikası edinip kurmalıdır”.

Chrome, 21 Ekim'de CT'de bu kökün altında süresi dolmamış yaklaşık 30.800 sertifika saydı. Bunların 30.791'i, Internet2'nin ABD'deki üniversiteler ve araştırma kurumları için işlettiği sertifika hizmeti InCommon'ın iki ara sertifikasından geliyordu; InCommon ECC sertifikalarını eMudhra'nın platformu CERTInext üzerinden veriyor. 18'i eMudhra'nın kendi ara sertifikalarından geliyordu. eMudhra, yaklaşık 30.000 sertifikanın taşınması gerektiğini, bunların yaklaşık %97'sinin ACME ile verildiğini ve başka bir hiyerarşiden yenilerini verdiğini söylüyor.

Siteniz Full (strict) modunda Cloudflare'in arkasındaysa ve origin sunucunuz bu kökün altında bir sertifika sunuyorsa, Cloudflare güvenin kaldırılmasının “kesintilere yol açacağını” söylüyor ve müşterilerine “Özel origin sertifikalarınızı ve sunucu yapılandırmalarınızı gözden geçirin” çağrısında bulunuyor.

eMudhra'nın diğer kök sertifikası emSign Root CA - G1 altındaki RSA sertifikaları şu ana kadar etkilenmiş değil. Mozilla bu kökü “şu an için” kaldırmadığını söylüyor; Chrome ise “eMudhra'nın kalan CA sertifikalarının dahil edilmeye devam edilmesini yakından inceliyor”. Herhangi bir türde eMudhra ya da CERTInext sertifikasına bağımlıysanız, ikinci bir sertifika otoritesini şimdiden hazırlayın.

3. GoDaddy müşterileri

GoDaddy'nin durumunun eMudhra ile hiçbir ilgisi yok, ancak aynı hafta ve çok daha fazla siteyi vurdu. GoDaddy 15 Ekim'de, GoDaddy ve Starfield hiyerarşilerinden verilen sertifikaların, kendi CP/CPS belgesindeki (bir sertifika otoritesinin hangi sertifikaları verdiğini beyan ettiği belge) profillerle uyuşmayan sertifika politikası bilgileri (politika OID'leri ve CPS bağlantıları) taşıdığını Mozilla'ya bildirdi. Bu, sertifikalarda bir güvenlik açığı değil. Ancak herkese açık her sertifika otoritesinin uyduğu kurallar olan Baseline Requirements kapsamında yine de beş gün içinde iptal edilmeleri için bir neden.

Etkilenen sertifika sayısı 404.607 ve bunların 396.055'i alan adı doğrulamalı (DV). GoDaddy 18 Ekim 23:45 UTC olan son tarihe kadar 170.566'sını iptal etti, ertesi sabaha kadar da 227.422'sini; müşteri duyurusuna göre kalanlar 21 Ekim'de iptal edildi. GoDaddy sertifikaları yeniden veriyor, ancak bunları kurmak müşteriye kalıyor: “yeni bir sertifika kurulana kadar web sitenizin ziyaretçileri güvenlik uyarıları görebilir ve siteniz erişilemez hale gelebilir.”

Bugün Kontrol Edilecekler

1. Kendi sunucularınız ne gönderiyor? Herkese açık her ana bilgisayar adı (hostname) için, sunduğu zincirdeki sertifikaları verenleri (issuer) listeleyin:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Çıktıda eMudhra, emSign, EM ... G3B ya da G3C otoritelerinden biri veya InCommon Intermediate CA - DVG3C, OVG3C ya da EVG3C geçen bir satır varsa, sertifikanın 27 Ekim'den önce değiştirilmesi gerekir. Tek başına AAA Certificate Services normaldir, çünkü pek çok sıradan Sectigo zinciri onu hâlâ içerir. E-posta ve dizin hizmetleri için -starttls smtp (ya da imap, ldap) ve doğru portu ekleyin. İç ağdaki sunucuları, yük dengeleyicileri ve bir CDN'in arkasındaki origin sunucularını da dahil edin.

2. Alan adlarınız için neler verilmiş? CT, herkese açık sertifika otoritelerinin alan adlarınız için verdiği her sertifikayı listeler; şirkette kimsenin sipariş ettiğini hatırlamadıkları da dahil:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

Çıktı, şirketinizin gerçekte hangi sertifika otoritelerini kullandığını da gösterir; bu da aşağıda anlatılan envanterin başlangıcıdır.

3. İstemcileriniz ele geçirilmiş anahtarlara güveniyor mu? Mozilla'nın test sunucuları ele geçirilmiş anahtarlarla verilmiş sertifikalar sunar; dolayısıyla sertifika hatası almak iyi sonuçtur. İki aileyi de test edin: ilk sunucu eMudhra'nın kök sertifikasına, ikincisi Sectigo'nunkine zincirlenir ve bir güven deposu birini reddedip diğerini kabul edebilir.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl yalnızca curl adına cevap verir. Aynı isteği her uygulamanın kendi TLS yığını üzerinden, uygulamanın çalıştığı ortamda çalıştırın:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

İki Python satırı gereksiz tekrar değil: urllib işletim sisteminin deposunu, requests ise certifi paketini kullanır. Her satırı dv-g3b-aaa-emudhra sunucusuyla tekrarlayın. Java için söz konusu JVM'den test sunucularına herhangi bir HTTPS çağrısı yapın ve deposunun iki kökten birini içerip içermediğini listeleyin (Java 9 ve sonrası; Java 8'de -keystore $JAVA_HOME/jre/lib/security/cacerts kullanın):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Bir depoda kök sertifikanın bulunması tek başına maruziyeti kanıtlamaz, çünkü Go, Node.js, Deno ve Rust tarafında rustls-webpki artık depo ne derse desin sekiz anahtarı engelliyor. Kesin cevabı test sunucuları verir.

4. Windows bilgisayar filoları. Microsoft olay hakkında hiçbir şey yayımlamadı, ancak Windows'un otomatik olarak indirdiği izin verilmeyen sertifikalar listesi 20 Ekim'den beri sekiz anahtarın tamamını engelliyor. İstisnalar, Grup İlkesi'nin otomatik kök sertifika güncellemelerini kapattığı makineler ve Windows Update'e erişimi olmayan ağlar; bunlarda listenin başka bir yolla dağıtılması gerekir. certutil -verifyCTL Disallowed, bir makinenin önbelleğe aldığı kopyayı gösterir. Mozilla'nın olay sayfası tekil makineler için bir betik sunuyor ve bunun “kurumsal olarak yönetilen cihazlar için önerilmediğini” belirtiyor.

5. GoDaddy sertifikaları. Her sunucunun gerçekte hangi sertifikayı sunduğunu kontrol edin:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Sertifikayı veren GoDaddy ya da Starfield ise seri numarasını GoDaddy hesabınızdaki sertifikalarla karşılaştırın. GoDaddy'nin “Install your new certificate” (yeni sertifikanızı kurun) gösterdiği yerde sunucuda hâlâ iptal edilmiş sertifika vardır.

Her adımda geçerli tek kural: bir hatayı sertifika doğrulamasını kapatarak ortadan kaldırmayın. Cloudflare'in ifadesiyle: “Bu hataları doğrulamayı devre dışı bırakarak çözmemek önemlidir.” Doğrulama yapmayan bir istemci yalnızca bunlara değil, her sahte sertifikaya güvenir.

Bu Hafta Güncellenecekler

İki tür düzeltme var. İki kök sertifikayı kaldırmak, o depoyu kullanan bir istemci için tüm yolları kapatır, ancak bu köklerin altındaki geçerli sertifikaları da bozar. Sekiz anahtarı açık anahtar hash'leriyle engellemek ise (Go, Node.js, Deno, Electron, rustls-webpki, Composer ve Windows'un yaptığı gibi) açığı kapatır ve başka hiçbir şeyi bozmaz. Platformunuz ikincisini sunuyorsa onu tercih edin.

“Henüz” ifadesi, 22 Ekim itibarıyla hiçbir şey yayımlanmadığı anlamına gelir. Planınızı buna göre yapmadan önce yeniden kontrol edin.

Ekiplerin en sık yakalandığı dört nokta:

• Container imajları eski listeyi korur. 20 ya da 21 Ekim'den önce oluşturulmuş bir imaj, güncellenmiş bir temel imaj üzerinde yeniden oluşturulana kadar anahtarlara güvenir; aynı etiketi (tag) yeniden çekmek de ancak temel imaj yeniden oluşturulduktan sonra işe yarar. Yeniden oluşturun, yeniden devreye alın ve imajlarını çalıştırdığınız üreticilere sorun.
• Süreçler yükledikleri şeyi tutar. Bir program güven deposunu başlarken okur; bu yüzden güncellemeden sonra uzun süre çalışan hizmetleri yeniden başlatın. Node.js ayrıca yükseltmeden önce kurulup sonradan devam ettirilen (resume) TLS oturumlarının yeniden kontrol edilmediğini belirtiyor.
• Uygulamalar kendi CA dosyalarını taşır. SDK'lar ve uygulamalar çoğu zaman kendi cacert.pem ya da ca-bundle.crt dosyalarıyla gelir. Bunları kod depolarında ve imajlarda arayın (örneğin find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null ile) ve birden fazla çıkmasını bekleyin: sözgelimi pip, certifi paketinin kendine ait bir kopyasını taşır.
• Cihazlar üreticilerini bekler. Her üreticiye ürünün hangi güven deposunu kullandığını ve güncellemenin ne zaman çıkacağını yazılı olarak sorun. Güncelleme gelene kadar cihaz, çağırdığı her hizmet için sahte sertifikalara güvenir; bu yüzden erişebildiği yerleri sınırlayın.

AAA Certificate Services kök sertifikasını Debian, Ubuntu ESM, Fedora ve Red Hat'in geçici çözümünün yaptığı gibi elle kaldırırsanız, ardından Sectigo sertifikalı hizmetlere yapılan bağlantıları test edin: bazı eski sunucular hâlâ bu kökte biten bir zincir gönderiyor.

Bir Sonraki Olaydan Önce Hazırlanacaklar

Bir sertifika otoritesinin bu kadar zayıf anahtarlar bırakması nadirdir. Toplu iptaller ise nadir değil. Mozilla'nın hata takip sisteminde kayıtlı, 2026'nın büyük toplu iptalleri şunlar:

Bu beş olayın hiçbiri bir güvenlik sorunu değildi. Her birinde bir sertifika, otoritenin kendi belgesiyle çelişiyordu ve Baseline Requirements (bölüm 4.9.1.1) yine de beş gün içinde iptali zorunlu kılıyor. Bir anahtar ele geçirildiğinde ya da alan adı doğrulamasına güvenilemediğinde süre 24 saattir. Bu süreyi kimse sizin için uzatamaz. DigiCert'in 2024'te 83.267 sertifikayı iptal ettiği olayda Chrome Root Program, “istisna tanıma yetkisinin bulunmadığını” yazdı; bir müşteri kendi sertifikalarının iptalini durdurmak için mahkeme kararı aldı ve karar dört gün sonra kaldırıldı.

Yeni sertifikaların nasıl devreye alındığı çok şey anlatıyor. HARICA Temmuz'da, müşterilerinin ACME istemcilerine erken yenileme yapmalarını söylemek için ACME Renewal Information (ARI) kullandı ve diğer sertifikaları kendisi yeniden verdi; iki iptalinden büyük olanında, son tarih geldiğinde etkilenen adların %87'si değiştirilmişti. Müşterileri her yeni sertifikayı kendileri indirip kuran GoDaddy ise son tarihine kadar etkilenen sertifikalarının %42'sini iptal etmişti.

Yenileme döngüsü zaten kısalıyor:

• CA/Browser Forum'un SC-081 numaralı oylamasına (ballot) göre herkese açık TLS sertifikalarının geçerlilik süresi 15 Mart 2026'dan beri 200 günle sınırlı. Sınır 15 Mart 2027'de 100 güne, 15 Mart 2029'da ise 47 güne iniyor; o tarihten itibaren alan adı doğrulaması yalnızca 10 gün boyunca yeniden kullanılabilecek.
• Let's Encrypt varsayılan sertifika süresini 10 Şubat 2027'de 64 güne, bir yıl sonra da 45 güne indiriyor.
• Herkese açık TLS sertifikaları istemci kimlik doğrulamasını kaybediyor. Let's Encrypt bunu 8 Temmuz 2026'da vermeyi bıraktı; Chrome Root Program da 15 Mart 2027'den itibaren verilen sertifikaların yalnızca sunucu kimlik doğrulaması için olmasını şart koşuyor. B2B API entegrasyonlarında yaygın olduğu gibi herkese açık sertifikaları mutual TLS (karşılıklı TLS) için istemci sertifikası olarak kullanıyorsanız, bu bağlantılar için özel bir sertifika otoritesi gerekecek.

100 günde, ardından 47 günde, sertifikaları elle kurmak gerçekçi bir seçenek olmaktan çıkıyor. Bu takvime göre otomasyon kuran bir şirket, bir sonraki toplu iptale de hazır olur. Bunun için gerekenler:

1. Elinizde ne olduğunu iki yönden de bilin. Sunduğunuz her sertifikanın ana bilgisayar adı, veren, bitiş tarihi, yenileme yöntemi ve sorumlusuyla birlikte yer aldığı bir liste. Yazılımınızın dayandığı her güven deposunun yer aldığı ikinci bir liste: işletim sistemi paketi, her dilin kendi CA paketi, bir uygulamanın ya da cihazın içindeki her CA dosyası. Yukarıdaki CT araması ilk listenin başlangıcıdır; yazılım malzeme listesi (SBOM) ya da bağımlılık envanteri ise ikincisinin.
2. Sertifika verilmesini ve kurulumunu otomatikleştirin. Çalışabildiği her yerde ACME; bir sertifika otoritesinin istemcilerinize erken yenileme yapmalarını söyleyebilmesi için de ARI (RFC 9773) ile birlikte. Bir cihaz ACME çalıştıramıyorsa üreticinin otomasyonunu kullanın ya da TLS bağlantısını cihazın önünde, ACME çalıştırabilen bir sistemde sonlandırın.
3. İkinci bir sertifika otoritesini hazır tutun. İkinci bir otoritede çalışan ve test edilmiş bir ACME hesabı ve DNS'te ikisine de izin veren CAA kayıtları. Bir otoriteye duyulan güven kaldırıldığında ya da otorite toplu iptal yaptığında geçiş bir yapılandırma değişikliğine dönüşür.
4. Alan adlarınız için CT'yi izleyin. Alan adlarınız için verilen her yeni sertifikada uyarı alın. Beklenmedik bir sertifika verildiğinde bunu aynı gün öğrenirsiniz.
5. Güven depolarını bağımlılık olarak ele alın. Onları olağan yama sürecinizle güncelleyin ve imajları yalnızca kod değiştiğinde değil, bir takvime göre yeniden oluşturun.
6. Uygulama kılavuzunu (runbook) iki süreye göre yazın. 24 saat ve beş gün: kim karar veriyor, her sisteme kimin erişimi var, hangi sistemler elle adım gerektiriyor, her üreticiye nasıl ulaşılıyor. Kılavuzu yılda bir kez, bir hatayı kaldırabilecek bir hizmette sertifikayı değiştirerek prova edin. Herkese açık sertifika otoritelerinin 2025'ten beri kendi toplu iptal planlarını tutması ve test etmesi zorunlu; diğer yarısı müşterilerine düşüyor.

Başkalarının Çalıştırdığı Ürünler Üretiyorsanız

Ürününüz bir güven deposu içeriyorsa (bir cihaz, kurulu bir uygulama, bir SDK), müşterileriniz ancak güncellemeniz onlara ulaştığında korunur. Güncellemeyi yayımlayın ve müşterilerinize hangi sürümlerin düzeltildiğini söyleyin. Mozilla'nın güven deposu işletenlere tavsiyesi: yazılımınız bunu yapabiliyorsa sekiz ara sertifikayı engelleyin, aksi halde “bu ara sertifikaları imzalayan köklere duyulan güveni kaldırmanın uygun olup olmadığını değerlendirin”.

Cyber Resilience Act burada iki şekilde devreye giriyor. 11 Eylül 2026'dan beri yürürlükte olan bildirim yükümlülüğü aktif olarak istismar edilen güvenlik açıklarını kapsıyor ve bu olayda herhangi bir istismar bildirilmedi. 11 Aralık 2027'den itibaren uygulanacak temel gereksinimleri ise güvenlik açıklarının güvenlik güncellemeleriyle giderilebilmesini içeriyor; güven listesi güncellenemeyen bir ürün bu gereksinimleri karşılamaz. NIS2 kapsamındaki müşteriler, tedarikçilerine bu durumu ne kadar hızlı ele aldıklarını soracak; cevabın yazılı olarak hazır olması işinizi kolaylaştırır.

Hâlâ Açık Olanlar

• eMudhra'nın kalan kök sertifikası. Chrome 21 Ekim'de eMudhra'ya on iki soru yöneltti ve emSign Root CA - G1 hakkında hiçbir karar açıklamadı. Mozilla onu “şu an için” kaldırmıyor.
• eMudhra'nın geçiş yolu. Şirket Mozilla'ya müşterilerini G1 (RSA) hiyerarşisine taşıyacağını söyledi; durum sayfası ise “alternatif, bağımsız olarak işletilen, herkesçe güvenilen bir CA hiyerarşisinden” söz ediyor. Chrome bunun hangisi olduğunu sordu.
• Microsoft ve Apple. İkisi de bir açıklama yayımlamadı ve iki kökten hiçbirini kendi deposundan kaldırmadı.
• Bekleyen düzeltmeler. Red Hat, Amazon Linux, Temurin ve Corretto 22 Ekim itibarıyla hiçbir şey yayımlamamıştı; Bun için düzeltme birleştirildi ancak yayımlanmadı.
• Kök neden. eMudhra bunu doğrulamadı ve gerçekleştirdiği her anahtar törenini yeniden doğrulayacağını söyledi.
• Sectigo. 5 Eylül'den beri açık olan ayrı bir vakada Sectigo, genişletilmiş anahtar kullanımı (extended key usage) CPS belgesindeki bir cümleyle uyuşmayan sertifikaları, cümlenin belirsiz olduğunu savunarak iptal etmeyi reddetti. 18 Ekim'de bunlardan yaklaşık 72 milyonunun hâlâ etkin olduğunu saydı. Kamuya açık tartışmaya katılanların bir kısmı güvenin kaldırılması çağrısında bulundu; hiçbir kök programı bir karar açıklamadı. Sectigo sertifikası kullanan şirketler bu vakayı takip etmeli.

Nereden Yardım Alabilirsiniz?

Bir sertifika sorunu kendini nadiren sertifika sorunu olarak gösterir. Yüklenmeyi bırakan bir ödeme sayfası, senkronizasyonu duran bir entegrasyon ya da veri göndermeyi bırakan bir cihaz olarak ortaya çıkar, çoğu zaman da bir hafta sonu. Şirketlerin bu haftaki gibi haftaları kesintisiz atlatmasına yardımcı oluyor ve bir sonrakinin rutin bir iş olması için gereken düzeni kuruyoruz:

• Maruziyet kontrolü. Container'lar, Java hizmetleri, bankalar, ödeme ve lojistik sağlayıcılarıyla entegrasyonlar ve cihazlar dahil olmak üzere sistemlerinizin nerede TLS bağlantısı kurduğunu ya da kabul ettiğini, her birinin hangi güven deposunu kullandığını ve hangi sertifikaları sunduğunuzu buluyoruz.
• Düzeltmeler. Güncellemeler, yeniden oluşturulmuş imajlar, engellenmiş anahtarlar ya da değiştirilmiş sertifikalar; hepsi sizin değişiklik süreciniz üzerinden yapılır ve Mozilla'nın test sunucularına karşı doğrulanır.
• 2027 için otomasyon. Sunucularda, yük dengeleyicilerde ve hazır cihazlarda ARI destekli ACME, ikinci bir sertifika otoritesi, CAA kayıtları, CT izleme ve bir uygulama kılavuzu; hepsi 15 Mart 2027'den itibaren geçerli 100 günlük sertifikalara hazır.
• Kimsenin dokunmak istemediği sistemler. Kendi güven depoları olan eski Java uygulamaları, hazır cihazlar ve gömülü istemciler tam olarak eski sistem ve kod bakım hizmetimizin konusu.

Etkilenip etkilenmediğinizden emin değilseniz, kullandığınız alan adları ve platformlarla birlikte office@c9group.dev adresine yazın ya da bir görüşme planlayın. Önce neyi kontrol etmeniz gerektiğini size söyleyeceğiz.