Microsoft’un en yeni işletim sistemi sürümleri olan Windows 11 24H2 ve Windows Server 2025 güvenlik standartlarını ileri taşımak amacıyla TLS 1.3 protokolünü varsayılan hale getirdi.
TLS 1.3 hız ve güvenlik açısından ciddi avantajlar sunsa da eskiye dönük bazı özelliklerin artık desteklenmemesi sebebiyle belirli senaryolarda uyumluluk problemleri yaşanıyor.
Özellikle IIS Express üzerinde ASP.NET projelerinde istemci sertifikası doğrulama (client certificate authentication) testleri yapılırken birçok geliştirici şu hatalarla karşılaşıyor:
- HTTP Error 500 – Internal Server Error
- 0x80070032 (ERROR_NOT_SUPPORTED)
Bu hatalar uygulamanın koduyla ilgili değil doğrudan TLS protokol davranışından kaynaklanıyor.
- Windows 10 ve Server 2022’ye kadar olan sürümlerde aynı senaryo genellikle daha anlaşılır bir hata döndürüyordu: “sayfaya ulaşılamıyor” gibi bir hata döner.
- Windows 11 24H2 ve Server 2025’te ise aynı konfigürasyon Error 500 ile sonuçlanıyor.
- Bazı durumlarda hata kodu 0x80070032 (ERROR_NOT_SUPPORTED) olarak loglarda görülebiliyor.
Sonuç olarak geliştirici açısından kafa karıştırıcı bir durum oluşuyor çünkü sorun uygulama tarafında değil IIS Express’in TLS 1.3 ile olan uyumsuzluğunda.
TLS 1.3’te Renegotiation Eksikliğinin Kontrol Edilmesi
IIS Express’in belirli ayarlarla istemci sertifikası talep etmesi bağlantının başında bir TLS renegotiation sürecine ihtiyaç duyar. Ancak TLS 1.3’te bu mekanizma artık desteklenmiyor. Dolayısıyla istemci sertifikası zorunlu kılındığında bağlantı kopuyor ve IIS Express istekleri işleyemiyor.
applicationhost.config Etkisi
Sorun genellikle proje dizininde yer alan applicationhost.config dosyasındaki sslFlags ayarlarından kaynaklanıyor. Örneğin:
<binding protocol="https" bindingInformation="*:443:localhost" sslFlags="SslNegotiateCert" />Bu ayarlar IIS Express’in istemci sertifikasını bağlantının başlangıcında aramasına sebep oluyor. TLS 1.2’de bu işlem desteklendiği için sorun çıkmıyordu fakat TLS 1.3 altında renegotiation yapılamadığı için bağlantı kesiliyor.
Microsoft konuyla ilgili yaptığı açıklamada:
- Bunun bilinen bir uyumluluk problemi olduğunu,
- IIS Express’in test amaçlı bir araç olduğundan kalıcı bir güncelleme yayımlanmasının planlanmadığını,
- Geliştiricilerin workaround yöntemleri kullanarak çalışmaya devam edebileceğini belirtiyor. Kısacası bu “geçici” değil uzun vadede de kabul edilmesi gereken bir sınırlama gibi görünüyor.
Çözüm Yöntemleri
1. Gelen Trafikte TLS 1.3’ü Devre Dışı Bırakmak
En pratik çözüm yalnızca server-side (gelen) TLS 1.3 bağlantılarını kapatmaktır.
- Bu yöntem kod veya proje ayarı değiştirmeyi gerektirmez.
- Tarayıcıların veya diğer istemci uygulamalarının dışa giden TLS 1.3 trafiği devam eder.
- IIS Express üzerinden yapılan sertifika testlerinde Error 500 ortadan kalkar.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"Enabled"=dword:00000000Bu değişiklik sonrasında sistemi yeniden başlatmak gerekir. Bu değişiklik sadece gelen trafiği etkilediği için genelde güvenle uygulanabilir.
2. applicationhost.config Dosyasını Düzenlemek
Eğer projenizde istemci sertifikası zorunlu değilse, sslFlags parametresini temizleyebilir veya SslNegotiateCert / SslRequireCert satırlarını kaldırabilirsiniz. Bu yöntem de sorunu ortadan kaldırır, ancak istemci sertifikası doğrulaması gerekiyorsa test kısıtlı hale gelir.
3. IIS Express Yerine Tam IIS Kullanmak
Eğer uzun vadeli bir geliştirme/test süreciniz varsa:
- IIS Express yerine IIS (Internet Information Services) kullanmak,
- TLS protokol ayarlarını daha esnek yönetmek,
- Sertifika tabanlı kimlik doğrulama senaryolarında daha gerçekçi test yapmak daha doğru bir yaklaşım olacaktır.
