Windows Server 2022 and 2025 ship with TLS 1.2 enabled by default, but many hardened VPS images still have legacy protocol bits turned on, and TLS 1.3 support depends on the exact build of Schannel. If you run IIS, SQL Server, .NET services, or an RDP endpoint, the transport security layer is the single most leveraged setting on the box. This guide gives you the exact registry keys, the PowerShell to apply them, and verification commands so you can prove the change took effect.<\/p>\n\n\n\n
Schannel protocol defaults are controlled per-client and per-server under The practical rule for 2026: disable SSL 2.0\/3.0 and TLS 1.0\/1.1, keep TLS 1.2 enabled, and enable TLS 1.3 for every role that supports it. Note that enabling TLS 1.3 with both<\/em> the client and server subkeys is required \u2014 many broken deployments set only one.<\/p>\n\n\n\n Each value lives under both a Run the following in an elevated session. It creates the keys idempotently, so it is safe to re-run.<\/p>\n\n\n\n For .NET Framework applications you must additionally force the managed stack away from defaults using Schannel reads these keys at process start, so IIS, SQL Server, and any long-lived service must be restarted \u2014 a full reboot is the clean approach. Before you change production, export the Protocol version is only half the story. A TLS 1.2 connection can still use a weak CBC-mode cipher if the server offers it and the client prefers it. Windows Server 2022 and 2025 ship with a sane default order, but you should confirm that AES-GCM and ChaCha20 suites rank above any CBC suites, and that RSA key exchange is not inadvertently enabled for forward secrecy. The effective order is controlled under A practical verification step is to run a full handshake against every port that terminates TLS \u2014 443 for IIS, 1433 for SQL Server if you expose it, and any custom application ports. Different services can have different effective policies depending on when they started and which .NET runtime they loaded, so testing “the server” as a single entity is misleading.<\/p>\n\n\n\n Treat transport security as a recurring task, not a one-time project. New Windows cumulative updates periodically add cipher suites, and application upgrades can reintroduce old defaults. A quarterly review that re-exports the registry, re-runs the external handshake checks, and confirms no new legacy protocol has reappeared keeps you ahead of both attackers and compliance audits. Document the current policy in your runbook so the next administrator knows exactly why each key is set.<\/p>\n\n\n\n Finally, remember that TLS hardening is only the transport. Pair it with certificate hygiene, strong ciphers, and HSTS on the web tier. If you are planning a fresh deployment and want a clean starting point, see our Windows VPS plans<\/a>, and for team workflows read more about managed Windows environments<\/a> that ship with sane security defaults.<\/p>\n","protected":false},"excerpt":{"rendered":"SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols<\/code>. Microsoft disables SSL 2.0 and SSL 3.0 by default, but TLS 1.0 and TLS 1.1 remain negotiable on most server builds unless explicitly disabled. Any legacy application that still asks for TLS 1.0 will happily succeed, which weakens your compliance posture and can break later when a partner disables it on their side.<\/p>\n\n\n\nThe registry settings that matter<\/h2>\n\n\n\n
Protocol<\/th> Enabled<\/th> DisabledByDefault<\/th><\/tr><\/thead> SSL 2.0<\/td> 0<\/td> 1<\/td><\/tr> SSL 3.0<\/td> 0<\/td> 1<\/td><\/tr> TLS 1.0<\/td> 0<\/td> 1<\/td><\/tr> TLS 1.1<\/td> 0<\/td> 1<\/td><\/tr> TLS 1.2<\/td> 1<\/td> 0<\/td><\/tr> TLS 1.3<\/td> 1<\/td> 0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Client<\/code> and a Server<\/code> subkey, and each subkey needs a Protocols<\/code> child. That is 2 (client\/server) x 6 (protocols) x 2 (values) = 24 value writes if you do it by hand.<\/p>\n\n\n\nApply with PowerShell<\/h2>\n\n\n\n
$base = 'HKLM:\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols'\n$spec = @{\n 'SSL 2.0' = @(0,1); 'SSL 3.0' = @(0,1)\n 'TLS 1.0' = @(0,1); 'TLS 1.1' = @(0,1)\n 'TLS 1.2' = @(1,0); 'TLS 1.3' = @(1,0)\n}\nforeach ($proto in $spec.Keys) {\n foreach ($side in 'Client','Server') {\n $path = Join-Path $base \"$proto\\$side\"\n New-Item -Path $path -Force | Out-Null\n New-ItemProperty -Path $path -Name 'Enabled' -Value $spec[$proto][0] -PropertyType DWord -Force | Out-Null\n New-ItemProperty -Path $path -Name 'DisabledByDefault' -Value $spec[$proto][1] -PropertyType DWord -Force | Out-Null\n }\n}<\/code><\/pre>\n\n\n\nSchUseStrongCrypto<\/code> and SystemDefaultTlsVersions<\/code> under both the .NETFramework v2.0.50727 and v4.0.30319 keys. Without those, an old ASP.NET app on a modern Windows VPS can still negotiate TLS 1.0 even after the Schannel change.<\/p>\n\n\n\nVerification, not assumption<\/h2>\n\n\n\n
Get-TlsCipherSuite | Sort-Object Name<\/code> lists what the OS can offer.<\/li>[Net.ServicePointManager]::SecurityProtocol<\/code> shows what .NET negotiates by default.<\/li>openssl s_client -connect yourhost:443 -tls1_2<\/code> should succeed; -tls1<\/code> and -tls1_1<\/code> should fail with a handshake error.<\/li>Test-NetConnection -ComputerName yourhost -Port 443<\/code> confirms reachability before you blame TLS.<\/li><\/ul>\n\n\n\nThe reboot and rollback<\/h2>\n\n\n\n
Protocols<\/code> key with reg export<\/code> so rollback is a one-liner. If a legacy client breaks after the change, re-enable only TLS 1.1 for that protocol’s Client<\/code> subkey rather than reverting the server side.<\/p>\n\n\n\nCipher suites and ordering<\/h2>\n\n\n\n
HKLM\\SOFTWARE\\Policies\\Microsoft\\Cryptography\\Configuration\\SSL\\00010002\\Functions\\TLS12Ciphers<\/code> on newer builds, or via group policy when the server is domain-joined.<\/p>\n\n\n\nCommon failure patterns<\/h2>\n\n\n\n
Get-TlsCipherSuite<\/code> for any TLS 1.3 suites before assuming it works.<\/li>Operating rhythm<\/h2>\n\n\n\n