Windows Server TLS 1.2 ve TLS 1.3 Nasıl Etkinleştirilir?

Microsoft Windows sistemlerinde TLS 1.2 ve TLS 1.3 yapılandırması, yalnızca bir registry anahtarı oluşturmakla sınırlı değil. İşletim sisteminin Schannel desteği, uygulamanın kullandığı TLS kütüphanesi, .NET Framework ayarları, sertifikalar ve cipher suite politikaları birlikte değerlendirilmelidir. Bu makalede Windows Server 2016, 2019, 2022, 2025 ve Windows 10/11 sistemlerinde doğru ve kontrollü bir yaklaşımı ele alacağım.

Önemli: Üretim ortamında herhangi bir protokol değişikliği yapmadan önce uygulama bağımlılıklarını kontrol edin, mevcut ayarları yedekleyin ve bakım penceresi planlayın. TLS 1.2 veya TLS 1.3’ün desteklenmesi, uygulamanın o sürümü mutlaka kullanacağı anlamına gelmez.

TLS 1.2 ve TLS 1.3 arasındaki fark nedir?

TLS (Transport Layer Security), istemci ile sunucu arasındaki iletişimi şifreleyen bir protokol ailesidir. TLS 1.3 el sıkışma sürecini sadeleştirir ve eski kriptografik seçenekleri kaldırır. Buna rağmen birçok kurumsal sistem ve uygulamada TLS 1.2 hâlâ gereklidir. İşletim sistemi varsayılanlarının bilinçsizce değiştirilmesi, özellikle eski yazılımlarda bağlantı kesintisine yol açabilir.

Hangi Windows sürümleri TLS 1.3 destekliyor?

İşletim sistemi	Schannel TLS 1.2	Schannel TLS 1.3
Windows Server 2016 / 2019	Desteklenir	Desteklenmez
Windows Server 2022 / 2025	Desteklenir	Desteklenir
Windows 10	Desteklenir	Desteklenmez
Windows 11	Desteklenir	Desteklenir

Dikkat: Windows 10 1909 veya 2004 üzerine TLS 1.3 registry anahtarı eklemek, işletim sistemine Schannel TLS 1.3 desteği kazandırmaz. Microsoft, TLS 1.3’ün daha eski Windows sürümlerinde etkinleştirilmesini güvenli bir sistem yapılandırması olarak değerlendirmiyor. Tablo Windows Schannel içindir; OpenSSL gibi bağımsız TLS kütüphanelerini kullanan uygulamaların desteği farklı olabilir.

Adım 1 — Mevcut Schannel TLS ayarlarını kontrol edelim

Önce yönetici yetkisiyle PowerShell açarak Client ve Server tarafındaki protokol ayarlarına bakalım. İlgili registry anahtarının bulunmaması, protokolün kapalı olduğu anlamına gelmez; birçok Windows sürümü kendi varsayılanlarını uygular.

$protocols = 'TLS 1.0', 'TLS 1.1', 'TLS 1.2', 'TLS 1.3'
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

foreach ($protocol in $protocols) {
    foreach ($role in 'Client', 'Server') {
        $path = Join-Path $base "$protocol\$role"
        $settings = Get-ItemProperty -Path $path -ErrorAction SilentlyContinue
        [pscustomobject]@{
            Protocol          = $protocol
            Role              = $role
            RegistryKeyExists = Test-Path $path
            Enabled           = $settings.Enabled
            DisabledByDefault = $settings.DisabledByDefault
        }
    }
}

Bu sorgunun çıktısındaki boş Enabled veya DisabledByDefault değerleri “devre dışı” şeklinde yorumlanmamalıdır. Sonuçları işletim sisteminizin destek ve varsayılan yapılandırma tablosuyla birlikte okuyun. Ayrı bir doğrulama için Get-TlsCipherSuite komutuyla kullanılabilir cipher suite listesini inceleyebilirsiniz; bu liste tek başına başarılı TLS el sıkışmasını kanıtlamaz.

Adım 2 — Değişiklik öncesinde kayıtları yedekleyelim

Schannel altındaki mevcut ayarların geri dönüşü için yükseltilmiş bir komut isteminde aşağıdaki yedeği alabilirsiniz. Ayrıca sanal makine yedeği, değişiklik kaydı ve uygulama test planı hazırlamak yerinde olacaktır.

reg export "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" "C:\Temp\Schannel-before-change.reg" /y

Örnekteki C:\Temp klasörü önceden oluşturulmuş olmalıdır. Yedek dosyasını yetkisiz erişime karşı koruyun. Geri dönüşte yalnızca planlanan değişiklikleri geri almak tercih edilir; tüm Schannel kayıtlarını körlemesine içeri aktarmayın.

Adım 3 — Gerekiyorsa TLS 1.2 istemci ve sunucu tarafını etkinleştirelim

Windows Server 2016 ve sonraki desteklenen sürümlerde TLS 1.2 çoğunlukla zaten etkin durumdadır. Dolayısıyla aşağıdaki PowerShell kodunu her sunucuda zorunlu bir işlem olarak uygulamayın. Yalnızca denetimde TLS 1.2’nin açıkça devre dışı bırakıldığı veya kurumsal yapılandırma standardınızın bu DWORD değerlerini gerektirdiği sistemlerde, test ederek kullanın.

$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2'

foreach ($role in 'Client', 'Server') {
    $path = Join-Path $base $role
    New-Item -Path $path -Force -ErrorAction Stop | Out-Null
    New-ItemProperty -Path $path -Name 'Enabled' -Value 1 -PropertyType DWord -Force -ErrorAction Stop | Out-Null
    New-ItemProperty -Path $path -Name 'DisabledByDefault' -Value 0 -PropertyType DWord -Force -ErrorAction Stop | Out-Null
}

Write-Host 'TLS 1.2 Schannel kayıtları yazıldı. Değişiklik ve bağlantı testlerini tamamlayın.'

Burada Enabled=1 protokole izin verirken DisabledByDefault=0 varsayılan kullanımının engellenmemesini sağlar. Ancak gerçek bağlantı hâlâ uygulamanın protokol seçimine, Windows sürümüne ve cipher suite uyumuna bağlıdır. Bazı Schannel değişikliklerinde hizmetlerin yeniden başlatılması yeterli olmayabilir; bakım penceresinde sistem yeniden başlatması planlanmalıdır.

TLS 1.3 için registry değişikliği gerekli mi?

Windows 11, Windows Server 2022 ve Windows Server 2025 üzerinde TLS 1.3 işletim sistemi tarafından desteklenir. Özellikle yeni kurulan sistemlerde desteklenen varsayılan Schannel yapılandırmasını korumak genellikle daha doğrudur. TLS 1.3 ayarları daha önce GPO, güvenlik sertleştirme betiği veya elle yapılan bir işlemle değiştirilmişse sorunun kaynağını araştırıp merkezi politikayla tutarlı şekilde düzeltin. Windows 10/Server 2019 ve öncesine TLS 1.3 kayıtlarını zorla eklemeyin.

.NET Framework kullanıyorsak Schannel ayarı neden tek başına yetmeyebilir?

Eski .NET Framework uygulamaları TLS sürümünü kod içinde sabitlemiş olabilir. Örneğin yalnızca TLS 1.0 talep eden bir uygulamada, işletim sisteminde TLS 1.2’nin açık olması bağlantının TLS 1.2 ile kurulacağı anlamına gelmez. Microsoft, mümkün olan durumlarda protokol seçiminin işletim sistemine bırakılmasını tavsiye ediyor.

ServicePointManager.SecurityProtocol değerini uygulama kodunda eski bir TLS sürümüne sabitlemeyin; uygun olduğunda SystemDefault kullanın.
SystemDefaultTlsVersions=1 işletim sisteminin seçtiği TLS sürümlerinin kullanılmasına yardımcı olabilir.
SchUseStrongCrypto=1 eski .NET Framework istemci uygulamalarında güçlü kriptografinin tercih edilmesini sağlayabilir.
Bu değerler HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 ve 32-bit uygulamalar için WOW6432Node altında ayrı ayrı değerlendirilebilir; yalnızca ilgili uygulama gerektiriyorsa uygulayın.

Özellikle Exchange, AD FS, IIS ve üçüncü parti .NET uygulamaları için ürünün kendi TLS destek dokümanını kontrol edin. Genel amaçlı bir registry dosyasını bütün sunuculara koşulsuz dağıtmak doğru yaklaşım değildir.

Adım 4 — TLS 1.2 ve TLS 1.3 bağlantılarını doğrulayalım

Yerel politika ve cipher suite kontrolü

Get-TlsCipherSuite | Select-Object Name, Protocols | Format-Table -AutoSize

Bu komut işletim sistemindeki cipher suite yapılandırmasını gösterir; bir uzak hizmete gerçekten hangi TLS sürümüyle bağlanıldığını tek başına göstermez.

Uzak bir HTTPS hizmetiyle gerçek TLS oturumunu kontrol etmek

Ortamınızda OpenSSL mevcutsa, hedef sunucunun gerçekten TLS 1.2 veya TLS 1.3 ile anlaşabildiğini kontrol edebilirsiniz. Alan adını ve portu kendi test ortamınıza göre değiştirin:

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Buradaki -tls1_3 seçeneği, OpenSSL kullanan test makinesinin TLS 1.3 desteğine de bağlıdır. Uzak hedefin protokol desteğini gösterir; doğrudan yerel Windows Schannel’ın desteklediği sürümü kanıtlamaz. Test için yerel Windows uygulamasının Schannel’ı kullandığından emin olun. Test-NetConnection ise TCP erişimini sınar, TLS anlaşmasının başarılı olduğunu doğrulamaz.

TLS 1.0 ve TLS 1.1 ne zaman kapatılmalı?

Eski protokollerin devre dışı bırakılması güvenlik açısından önemlidir; ancak önce uygulama envanteri çıkarılmalı, servis sağlayıcıları ve eski istemciler test edilmelidir. GPO, load balancer, reverse proxy, IIS, SQL Server, Exchange ve etki alanı servislerinin TLS bağımlılıkları değerlendirilmeden toplu kapatma yapılması kesintiye neden olabilir. Özellikle güncel Windows sürümlerinin varsayılanları ile kurumsal güvenlik standartları arasında tutarlılık sağlayın.

Sık yapılan hatalar

Registry’de TLS 1.3 klasörü oluşturmayı, desteklenmeyen Windows sürümünde TLS 1.3 etkinleştirmek sanmak.
TLS 1.2 zaten etkinken aynı anahtarları tekrar yazıp güvenliğin artırıldığını varsaymak.
Client ve Server rollerini karıştırmak.
Schannel, .NET Framework, Java ve OpenSSL tabanlı uygulamaları aynı TLS yapılandırma mekanizmasına sahip sanmak.
Ağ portu açık olduğu için TLS el sıkışmasının başarılı olduğunu varsaymak.
Güncelleme, uygulama uyumluluk testi ve geri dönüş planı olmadan eski TLS sürümlerini kapatmak.

Sonuç

Windows sunucularında TLS güvenliği tek komutla tamamlanan bir işlem değil, kontrollü bir sertleştirme çalışmasıdır. Önce işletim sisteminin TLS sürüm desteğini ve mevcut Schannel yapılandırmasını inceleyin. Gerekiyorsa TLS 1.2 ayarlarını düzeltin; TLS 1.3 için desteklenen işletim sistemlerinde varsayılanları koruyun ve gerçek bağlantı testleriyle sonucu doğrulayın. Son olarak uygulama katmanını, özellikle eski .NET Framework ve üçüncü parti istemcileri ayrıca değerlendirin.

Kaynaklar ve teknik dokümantasyon

Published On: 26 Mayıs 2020 / Categories: Windows Server / 7,7 min read /

Microsoft Windows Sistemlerde TLS 1.2 ve TLS 1.3 Nasıl Açılır – Aktif Hale Getirilir