Sertifika otoritesi ele geçirildi: sunucularımın sertifikalarında neyi kontrol ediyorum

eMudhra sertifika otoritesinin sekiz ara sertifikasının özel anahtarları sızdı. Bu sertifikalara tarayıcılar, işletim sistemleri ve HTTPS üzerinden çalışan hemen her şey güveniyordu. Anahtarlar kimdeyse, o kişi herhangi bir alan adı için sahte sertifika üretip kendi sunucusunu başkasının sunucusu gibi gösterebilir: bir banka ya da ödeme servisinizin API'si gibi. Tarayıcılar bu açığı bir günde kapattı. Sunucular ve çalışanların dizüstü bilgisayarları kendi kendine kapatmaz. Bununla sunuculardan sorumlu olan kişinin ilgilenmesi gerekir.

Kim ne yazdı

Cloudflare 20 Ekim'de olayı blogunda anlattı: sızıntıyı 19 Ekim'de saat 17:00 UTC civarında öğrenmişler, yaklaşık bir gün içinde WARP ve cloudflared istemcilerini güncelleyip CDN ve Zero Trust tarafını kapatmışlar. Kendilerinde istismar izine rastlamamışlar. Oradan iki tavsiye akılda tutmaya değer. Birincisi: SDK'nın altına bakmak. Bir API istemcisi sertifikayı HTTP kütüphanesi, dilin çalışma zamanı, işletim sistemi ya da kendi güven listesi üzerinden doğrulayabilir. Tek bir SDK'yı güncellemek bunların hiçbirini değiştirmez. İkincisi: güncellemeden sonra loglarda sertifika hataları belirirse bunları doğrulamayı kapatarak çözmemek.

Ubuntu 20 Ekim'de 14.04'ten 26.10'a kadar bütün sürümler için ca-certificates paketine ve libnss3 kütüphanesine güncelleme yayınladı. eMudhra'nın kendisi onların kök deposunda yoktu, ama onu iki başka kök imzalamıştı: emSign Root TLS CA G3 ve Comodo AAA Certificate Services. İkisini de kaldırdılar. Otomatik güncellemeler açıksa, ki 16.04'ten beri varsayılan olarak açık, yama bir gün içinde gelir. Java ayrı bir hikâye: Java'nın deposu sistem deposuyla, çözülmemiş bir hatası olan bir paket üzerinden eşitleniyor ve orada elle müdahale gerekiyor. 21 Ekim'de Oracle kendi Java'sı için CVE-2026-91403'ü yayınladı.

Simon Willison 20 Ekim'de kısa bir özet derledi: sertifikalar Mozilla, Microsoft, Apple ve Chrome'un güvendiği köklere çıkıyor, bu yüzden kendi güven listesi olan her yazılımın güncellenmesi gerekiyor. Python tarafında uv 0.13.4, pip 26.2.2 ve certifi 2026.10.19 çoktan çıktı.

Weaviate 22 Ekim'de kendi güncelleme sürecini anlattı: bütün istemci parkını ve platformu 17 saatten kısa sürede Go 1.27.3'e taşımışlar, kurumsal müşterileri altı saatte. Metinden anladığım kadarıyla güncelleme dilin sürümüydü: Cloudflare'in yazdığı “SDK'nın altı” durumu tam da bu.

Bu neden araç kiralama şirketini de ilgilendiriyor

Bir araç kiralama şirketini ele alalım. Rezervasyon sitesi bir sunucuda duruyor, yöneticiler dizüstü bilgisayarlardan çalışıyor, ödeme bir ödeme servisi üzerinden onaylanıyor, sözleşmeler e-postayla gidiyor. Sitenin kendi sertifikasının bu hikâyeyle ilgisi yok. Tehlike şurada: kiralama sunucusu ödeme servisinin ve CRM'in API'sine kendisi gidiyor, yönetici ise kafede başkasının Wi-Fi'ından dizüstüyle bankaya giriyor. Yolun üstünde sızan anahtarlara sahip biri varsa, sunucuya ya da dizüstüne sahte bir “ödeme servisi” gösterir ve güven listesi güncellenene kadar sertifika kontrolü bunu geçirir.

Sonuç: kontrol edilmesi gereken şey, makinelerinizin bir yere kendileri bağlanırken güvendiği listeler. Tek bir sunucuda bu listelerden birkaç tane var.

Kendimde neyi kontrol ediyorum

Birkaç şirketin sunucusu benim üzerimde: ABD'deki PDR şirketinin 2022'den beri Google Cloud'da Debian üzerinde çalışan sunucusu, aynı yerdeki hidroponik çiftliğin sunucusu ve stüdyonun 2 GB bellekli ortak sunucusu. Sonuncusunda Nginx arkasında Docker içinde sitem ve Let's Encrypt sertifikalı “Birlikte Kahve” iç servisi çalışıyor. PDR şirketinde güvenlik soruları bana geliyor ve dünyada büyük bir sızıntı olduğunda bizi ilgilendirip ilgilendirmediğine bakıyorum. Bu hikâye tam da onlardan.

Birincisi: her sunucuda sistem paketi ca-certificates. Debian'da adı Ubuntu'dakiyle aynı.

İkincisi: konteynerlerin içi. Docker imajının kendi güven listesi var, host güncellemesi ona dokunmaz, imajların yeniden derlenmesi gerekir. Stüdyo sunucusunda derlemeye bazen bellek yetmiyor, bu yüzden imaj sunucu dışında derlenip hazır olarak yükleniyor.

Üçüncüsü: çalışma zamanları. Node.js kendi kök sertifika listesini taşıyor, Python'un kendi certifi'si var. Bu haftaki güncellemelerini Node.js, Python ve Next.js yamaları yazısında ayrıca anlatıyorum.

Dördüncüsü: kim nereye gidiyor. “Birlikte Kahve”de sunucu Tasty Coffee'nin toptan API'sine ve Google E-Tablolar'a iç proxy'ler üzerinden kendisi gidiyor. PDR şirketinde Python parser'ları Anthropic, OpenAI ve Gemini servislerine, telefon sistemi Twilio'ya gidiyor, PDF'leri ise kendi Chrome'uyla Puppeteer üretiyor. Bu yolların her birinin kendi sertifika kontrolü var ve tarayıcıda başarılı bir test onlar hakkında hiçbir şey söylemez.

Beşincisi: stüdyo sunucusundaki Let's Encrypt sertifikasına dokunmuyorum. Onu başka bir otorite verdi ve anladığım kadarıyla bu hikâye onu ilgilendirmiyor.

Küçük bir şirkette ne yapardım

Sunuculardaki ve çalışma dizüstülerindeki işletim sistemlerini, sertifika paketi dahil, güncellerdim. Ubuntu'da bu sıradan bir apt upgrade.

HTTPS üzerinden dışarıya kendisi giden programların listesini çıkarırdım: ödeme servisine giden site, CRM entegrasyonları, parser'lar, mesajlaşma botu. Her biri için sertifikayı neyle doğruladığını öğrenirdim: sistem, çalışma zamanı ya da kütüphane.

Docker imajlarını güncellenmiş temel imajlarla yeniden derleyip konteynerleri yeniden başlatırdım. Tek başına host'u güncellemek yetmez.

Güncellemeden sonra loglara bakardım. Bir şey bağlanamaz olduysa kime ve neden bağlanamadığını çözerdim. Doğrulamayı “geçici olarak” kapatmak olmaz.

Çalışanlara bu hafta dizüstü ve telefon güncellemelerini ertelememelerini söylerdim.

Sistemin neden kendi sunucusuna ihtiyaç duyduğu ve erişimden kimin sorumlu olduğu üzerine: Sunucu: veri, erişim ve sürecin yürütülmesi. Yayınlanabilen ve geri getirilebilen bir altyapının nasıl tutulduğu DevOps ve altyapı sayfasında anlatılıyor. Bu yazıdaki sunucular “Birlikte Kahve” ve PDR şirketiyle teknik ortaklık vakalarında var. Yakın yazılardan: PHP2Shell ve kendi sunucularını kontrol etmek, Node.js, Python ve Next.js yama haftası ve kalıcı anahtar yerine tek seferlik token; daha önce API anahtarları ve bir sızıntıyı atlatmak üzerine yazmıştım. Sunucularınızın kime güvendiğinden emin değilseniz, nerede ne kurulu olduğunu anlatın, nereden başlayacağınızı söyleyeyim. Görevi konuşalım.