Enable TLS 1.2 and TLS 1.3 System-Wide on a Windows VPS: Schannel Registry Settings and Verification

TLS version support on Windows is decided at the operating-system level by Schannel, the built-in security provider. IIS, WinRM, RDP’s network layer, and every .NET application on the box inherit the same protocol settings — which is why a single registry change can modernize TLS for the whole VPS at once. TLS 1.0 and 1.1 have been deprecated for years, and modern browsers, payment processors, and security scanners expect at least TLS 1.2, preferably TLS 1.3. This guide shows how to enable TLS 1.2 and 1.3 system-wide, disable the legacy protocols, and verify the result from outside.

The procedure is identical on every edition of Windows Server, but TLS 1.3 requires Windows Server 2022 or newer. If your provider’s image is older, you may need to reinstall or pick a host with current templates — our comparison table of Windows VPS providers shows which vendors offer Server 2022 and 2025 images out of the box.

Step 1: Check which protocols are currently enabled

Open an elevated PowerShell and list the protocol keys under Schannel:

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" |
  Select-Object -ExpandProperty PSChildName

Protocols listed here are explicitly configured; protocols missing from the list fall back to Windows defaults. A quick check of what .NET will use is:

[Net.ServicePointManager]::SecurityProtocol

Step 2: Enable TLS 1.2 and TLS 1.3

$base = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
foreach ($proto in "TLS 1.2", "TLS 1.3") {
  foreach ($side in "Server", "Client") {
    New-Item "$base\$proto\$side" -Force | Out-Null
    New-ItemProperty "$base\$proto\$side" -Name Enabled -Value 1 -PropertyType DWord -Force | Out-Null
    New-ItemProperty "$base\$proto\$side" -Name DisabledByDefault -Value 0 -PropertyType DWord -Force | Out-Null
  }
}

On Windows Server 2022 and later, the TLS 1.3 keys are honored after a reboot. On Server 2019, TLS 1.3 is not available — the script creates the keys and the system ignores them, so configure TLS 1.2 only there.

If you prefer a GUI over the registry, the free IIS Crypto tool (from Nartac Software) exposes the same Schannel keys with checkboxes and applies them for you. It is useful as a second pair of eyes: it lists every protocol and cipher suite on one screen, and its Best Practices button preselects exactly the settings above. Everything it changes lives in the same HKLM path, so you can still verify with Get-ItemProperty afterward.

Step 3: Disable SSL 3.0, TLS 1.0, and TLS 1.1

foreach ($proto in "SSL 2.0", "SSL 3.0", "TLS 1.0", "TLS 1.1") {
  foreach ($side in "Server", "Client") {
    New-Item "$base\$proto\$side" -Force | Out-Null
    New-ItemProperty "$base\$proto\$side" -Name Enabled -Value 0 -PropertyType DWord -Force | Out-Null
    New-ItemProperty "$base\$proto\$side" -Name DisabledByDefault -Value 1 -PropertyType DWord -Force | Out-Null
  }
}

Warning: run this only when you are sure your clients support TLS 1.2 or better. Old RDP clients on unpatched Windows 7 and legacy browsers will no longer connect — for a VPS that is almost always what you want, but verify your remote access path before you reboot.

Step 4: Force .NET to use strong cryptography

Independent of Schannel, .NET Framework 4.x only respects the OS protocol settings if you set SchUseStrongCrypto. Without it, some .NET apps happily negotiate TLS 1.0. Set it for both the 64-bit and 32-bit (WOW64) registry views:

$dotnet = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty $dotnet -Name SchUseStrongCrypto -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" `
  -Name SchUseStrongCrypto -Value 1 -PropertyType DWord -Force | Out-Null

For .NET Core and .NET 5+, the runtime already prefers the OS protocols, so no registry tweak is needed.

Step 5: Reboot and verify from outside

All Schannel changes require a reboot to take effect. After the server comes back, verify each protocol from a machine with openssl (or run the Qualys SSL Labs test against your public IP):

openssl s_client -connect your-vps-ip:443 -tls1_3 -servername site.example.com < /dev/null
openssl s_client -connect your-vps-ip:443 -tls1_2 -servername site.example.com < /dev/null
openssl s_client -connect your-vps-ip:443 -tls1_1 -servername site.example.com < /dev/null

The first two commands should print a certificate chain; the TLS 1.1 attempt should fail with a handshake error. On the server itself, confirm the registry values and the running service:

Get-ItemProperty "$base\TLS 1.2\Server" | Select-Object Enabled, DisabledByDefault
Get-ItemProperty "$base\TLS 1.3\Server" | Select-Object Enabled, DisabledByDefault

Also re-test RDP and WinRM after the reboot — if your management client is modern, both should connect over TLS 1.2+ without any extra work.

A note on IIS sites

Because IIS uses Schannel, the moment the registry is in place every site on the server inherits the new protocol policy — there is nothing to configure per site. Certificates are a separate topic, but if your IIS bindings are already set up, the TLS version upgrade is invisible to visitors except for a better security rating.

Wrap up

System-wide TLS 1.2/1.3 is one of those rare changes that improves security, compatibility with modern clients, and your site’s reputation with scanners in a single reboot. For a host that ships current Windows Server images so the TLS 1.3 keys actually work, see the full specs and pricing in our Windows VPS provider comparison.

TLS 1.3 needs a modern OS, so choose a provider that deploys Server 2022 or 2025. Vultr’s Windows VPS instances are built from up-to-date templates, letting you enable TLS 1.3 and keep it enabled across rebuilds.