Bir Windows uygulaması, Microsoft imzalı dosyayı Windows güvenilir bulduğu hâlde reddedebilir mi? Evet; doğrulama kodu belirli bir sertifika adına, parmak izine veya algoritmaya sabitlenmişse bu mümkün. Microsoft’un 20 Ağustos 2026 tarihli KB5125813 belgesi, Windows kod imzalama altyapısında 2026 sonu ve 2027 boyunca yapılacak değişikliklere karşı geliştiricileri ve BT yöneticilerini uyarıyor. Amaç paniğe kapılmak değil; kırılgan doğrulama mantığını ekim ayından önce bulmak.

Kod imzası neden değişiyor?

Kod imzası, bir çalıştırılabilir dosyanın kim tarafından yayımlandığını ve imzalandıktan sonra değiştirilip değiştirilmediğini doğrulamaya yardım eder. Buradaki değişiklik, Windows’un imza güven zincirini güncel tutma ve daha güçlü kriptografiye geçme planının parçası. Microsoft Windows Production PCA 2011 sertifika yetkilisinin 19 Ekim 2026’da süresi doluyor ve yerine yeni bir üretim CA’sı geliyor.

Microsoft ayrıca 2026’nın sonuna kadar RSA-3072 ve SHA-384 gibi daha güçlü yapılandırmalara yönelmeyi, 2027’de ise kuantum sonrası imzalamaya geçişi planladığını belirtiyor. Bu takvim, bugün kullanılan her algoritmanın aniden güvensiz olduğu anlamına gelmiyor. Asıl mesaj, yazılımın tek bir sertifika veya algoritma kombinasyonunu sonsuza kadar değişmez kabul etmemesi.

Hangi uygulamalar kırılabilir?

  • Microsoft sertifikasının konusu, vereni, seri numarası veya parmak izi kod içinde sabitlenmişse;
  • Yalnız RSA-2048 ve SHA-256 gibi tek bir algoritma eşleşmesi kabul ediliyorsa;
  • Windows’un güven API’leri yerine Authenticode veya sertifika zinciri özel kodla ayrıştırılıyorsa;
  • Uygulama, sertifika rotasyonlarını düzenli almayan özel bir güven deposu kullanıyorsa;
  • EDR, uygulama izin listesi veya kurumsal dağıtım aracı eski CA’ya göre kural yazdıysa risk yükselir.

Bu sorun çoğunlukla sıradan kullanıcının elle sertifika değiştirmesi gereken bir durum değil. Risk, kurum içi yazılım, eski ajan, özel güncelleyici veya güvenlik ürünü gibi imzayı kendi mantığıyla değerlendiren bileşenlerde. Ev kullanıcısı için doğru hareket Windows ve uygulama güncellemelerini yüklemek; rastgele kök sertifika indirip kurmak değil.

Geliştirici doğrulamayı nasıl düzeltmeli?

Microsoft’un önerisi “sertifikanın kimliğini” değil Windows’un verdiği güven kararını doğrulamak. Bunun için WinVerifyTrust veya uygun CryptoAPI/Crypt32 zincir ve ilke arabirimleri kullanılmalı. Desteklenen bir sözleşme açıkça belgelenmedikçe belirli CA adı, parmak izi, anahtar boyutu ya da özet algoritması şart koşulmamalı.

Burada sertifika sabitlemenin her türünün yanlış olduğu sonucu çıkarılmamalı. Web servislerinde kontrollü pinning veya kurum içi kök güven politikası farklı tehdit modellerine dayanabilir. Uyarı, Windows sistem dosyalarının meşru sertifika rotasyonunu kıracak biçimde Microsoft üretim kimliğine sabitlenmiş doğrulamalarla ilgili. SSL sertifikasının temel güven mantığı ile kod imzalama aynı aileden kavramlar taşısa da kullanım bağlamları farklıdır.

BT yöneticisi için risksiz kontrol planı

  • Kritik Windows ajanlarını, güvenlik yazılımlarını ve eski kurumsal uygulamaları envanterleyin.
  • Üreticiye yeni Microsoft CA’sı ve SHA-384 imzalarıyla test yapılıp yapılmadığını sorun.
  • Özel uygulama izin listelerinde sertifika parmak izi veya veren adına bağlı kuralları bulun.
  • Değişikliği önce temsilî bir test cihazında deneyin; olay günlüklerini ve uygulama başlatma hatalarını karşılaştırın.
  • Özel güven deposu kullanan ürünlerin sertifika güncelleme mekanizmasını doğrulayın.
  • Geri dönüş planını uygulama sürümü, ilke yedeği ve sorumlu kişiyle birlikte yazılı hâle getirin.

Test sırasında güvenlik denetimini tamamen kapatmak doğru bir çözüm değildir. Bir ürün yeni imzayı reddediyorsa geçici “her şeye izin ver” kuralı açmak yerine satıcı güncellemesi, dar kapsamlı test politikası ve kayıtlı istisna kullanılmalı. Aksi hâlde uyumluluk sorunu çözülürken daha büyük bir çalıştırma riski oluşturulur.

Sonuç: güveni doğrulayın, sertifikayı ezberlemeyin

Sorun çıktığında hangi kanıtları toplayın?

Geçiş döneminde bir uygulama açılmazsa “sertifika değişti” varsayımıyla doğrudan politika gevşetmeyin. Hatanın oluştuğu Windows sürümünü, uygulama sürümünü, dosyanın dijital imza durumunu, olay günlüğündeki zaman damgasını ve aynı dosyanın test cihazındaki sonucunu kaydedin. Sorunun yalnız eski sürümde görülmesi, üretici güncellemesini güçlü aday yapar; bütün sürümlerde görülmesi ise daha geniş bir dağıtım veya güven deposu problemini gösterebilir.

Satıcıya “uygulama çalışmıyor” demek yerine yeni Microsoft üretim CA’sıyla test sonucu, kullanılan doğrulama API’si ve özel güven deposu olup olmadığını sorun. Bu üç bilgi destek süresini kısaltır. Kurum içi yazılımınız varsa kaynak kodda parmak izi, sertifika konusu, RSA-2048 ve SHA-256 gibi sabit varsayımları aramak iyi bir başlangıçtır; bulunan her eşleşme otomatik hata değildir, kullanım bağlamı incelenmelidir.

Envantere yalnız masaüstü uygulamalarını yazmayın. Güncelleme servisleri, sürücü yükleyicileri, PowerShell betikleri, uygulama kontrol ürünleri ve çevrimdışı kurulum paketleri de imza doğrulayabilir. Uzun süredir değişmeyen ama kritik çalışan eski bir yardımcı araç, görünür ana uygulamadan daha kırılgan olabilir. Test kapsamı bu arka plan bileşenlerini içermelidir.

19 Ekim 2026 tarihi, özellikle eski doğrulama kodlarını gözden geçirmek için somut bir son tarih sunuyor. Sağlam uygulama, güvenilir imzanın yıllarca aynı parmak izi ve algoritmayla geleceğini varsaymaz. Windows’un desteklenen güven kararını kullanır, sertifika rotasyonunu test eder ve kriptografik değişime hazırlıklı kalır.

Kaynak