EMudhra CA olayı sonrası TeamCity’de Java trust store kontrolü

JetBrains, özel anahtarları zayıf çıkan sekiz eMudhra CA nedeniyle TeamCity server ve build agent’larının Java trust store’larını kontrol etmenizi istiyor. Altısı TLS, ikisi code signing için kullanılan bu intermediate CA’lerin anahtarlarının kamuya açık veriden kurtarılabildiği 17 Ekim 2026’da bildirildi. TeamCity 2026.2.2 ve 2026.1.6, kurulum etkilenen sertifikalara hâlâ güveniyorsa bir health report gösteriyor.

TeamCity nedir, ne için kullanılır?

TeamCity, JetBrains’in geliştirdiği bir CI/CD sunucusudur. Kod değişikliklerini build agent’larında derleyip test etmek ve release süreçlerini otomatikleştirmek için kullanılır. Hem kendi sunucunuza kurulan On-Premises sürümü hem de JetBrains’in işlettiği Cloud sürümü vardır. Yazılım ekipleri ve kurumsal geliştirme birimleri tercih eder. Bilinen alternatifleri arasında Jenkins, GitLab CI ve GitHub Actions bulunur.

eMudhra CA anahtarları ve Java trust store

Tarayıcınız ve işletim sisteminiz güncelse bu olay sizi büyük ihtimalle etkilemiyor. TeamCity server ve build agent’ları işletim sisteminin trust store’unu kullanmıyor, kendi Java runtime’larının trust store’una bakıyor. O dosya güncellenene kadar sekiz eMudhra CA sertifikası güvenilir sayılmaya devam ediyor.

JetBrains’e göre bu anahtarlarla üretilen bir sertifika, onlara hâlâ güvenen her yazılımda geçerli görünüyor. Bir CI ortamında Java süreçleri TeamCity server’a, VCS host’una ve package registry’ye bağlanıyor. EMudhra, anahtarların duyurudan önce kullanıldığına dair kanıt bilmediğini söylüyor; anahtarlar artık kamuya açık veriden çıkarılabildiği için bu güvence ileriye dönük değil.

İki CA code signing için. İmza doğrulamasını Java ile yapan bir pipeline adımınız varsa onu da kontrol listesine ekleyin.

Önce JRE envanteri

İş, her server node ve agent’ın hangi JRE ile çalıştığını bulmakla başlıyor. Agent makinelerinde çoğu zaman birden fazla JDK kurulu olur ve agent’ın kendi JRE’si build’lerin kullandığından farklı olabilir. Javax.net.ssl.trustStore ile özel bir trust store tanımladıysanız onu ayrıca tarayın.

find / -name cacerts -type f 2>/dev/null
keytool -list -v -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit | grep -E 'CN=EM (DV|OV|EV) (TLS|CS) CA - G3'

JDK 8’de yol jre/lib/security/cacerts şeklinde. Bu hızlı kontrol yalnızca CN alanına bakıyor; JetBrains’in yazısındaki script parmak izi önekleriyle de eşleşme arıyor, karar vermeden önce onu çalıştırın. Script blocked.certs dosyasını incelemiyor ve sonucu yalnızca seçtiğiniz trust store için geçerli.

Sonra Java sağlayıcınızın release note’larında CVE-2026-91403 ve CVE-2026-114820’yi arayın. Amazon Corretto 21 kullanıyorsanız 21.0.13.0.11 veya sonraki bir build’e çıkın. Güncellemeden sonra her node ve agent’ı yeniden başlatın.

Yükseltme mümkün değilse JetBrains’in elle müdahale adımlarını uygulayabilirsiniz. Burada dikkat: AAA Certificate Services kökünü silmek etkilenmeyen servisleri de kesebilir, bu kökü kaldırmadan önce ona bağlı bağlantıları test edin.

Agent’lar health report’un dışında kalıyor

TeamCity 2026.2.2 ve 2026.1.6’daki health report yalnızca server’ı tarıyor, agent’ları kontrol etmiyor. TeamCity Cloud kullanıyorsanız JetBrains server’ı güncelledi, fakat self-hosted agent’larınızın JRE’si yine sizin işiniz.

Java güncellemesi elle yüklenmiş sertifikaları silmiyor. İki dizine bakın:

• Server: <TeamCity Data Directory>/config/projects/_Root/pluginData/trustedCertificates
• Agent: <agent home>/conf/trustedCertificates

Server’daki etkilenen sertifikaları Root project altındaki SSL / HTTPS Certificates sayfasından kaldırın, agent’takileri doğrudan silin. Dizin yoksa henüz sertifika yüklenmemiş demektir; TeamCity onu ilk yüklemede oluşturuyor.

Docker image’ları ve ayrı trust store tutan araçlar

Container içinde Java’yı elle güncellemek kalıcı olmuyor, container yeniden oluşturulunca eski image geri geliyor. Yamalı 2026.2.2 veya 2026.1.6 agent image’ını Docker Hub’dan çekin veya kendi image’ınızı yeniden build edin, ardından container’ları yeniden oluşturun. JetBrains server image’ı için “once published” ifadesini kullanıyor; image hazır değilse rebuild yolunu izleyin.

Özel agent image’larınızda Java tek sorun değil. Git ve MinGit, Python’un certifi paketi ve Node.js kendi CA listelerini taşıyor. Build adımlarınız pip veya npm ile registry’ye bağlanıyorsa Java güncellemesi bu araçları düzeltmez; her image’da OS ve araçları güncelleyip rebuild edin.

VCS host’unuz veya registry’niz eMudhra sertifikası kullanıyorsa sertifikayı eMudhra’nın geçiş süreciyle değiştirin.

Neyi erteleyebilirsiniz

TeamCity yükseltmesi Java güncellemesinin yerini tutmuyor; JetBrains yükseltmeden sonra da her node’da Java’yı güncellemenizi istiyor. Sırayla: JRE’ler, yüklenen sertifikalar, agent image’ları, en son TeamCity sürümü.

Yeni sürümler başka güvenlik açıklarını da kapattığı için yükseltmeyi uzun süre bekletmeyin. TeamCity indirmeleri bir eMudhra CA ile imzalanmadığından kurulum paketlerini yeniden doğrulamanız gerekmiyor.

CVE kayıtları: CVE-2026-91403, CVE-2026-114820