STATUS_STRONG_CRYPTO_NOT_SUPPORTED (0XC00002F6) Fix

What triggers this error

You'll see 0XC00002F6 in Event Viewer under Schannel or when an app (RDP, SQL Server, a web service) fails to connect over TLS. The error text is STATUS_STRONG_CRYPTO_NOT_SUPPORTED. I've run into this on Windows 10 1809, Server 2019, and even Windows 11 21H2. The machine says "I don't have the cipher suites to talk to that server."

Cause #1 — Missing Windows update that enables TLS 1.2

This is the culprit nine times out of ten. Microsoft rolled out TLS 1.2 as default via updates around 2017–2020. If you're on an older build or haven't patched, the Schannel registry keys for TLS 1.2 might be missing or disabled.

The fix — install the right update

For Windows 10/11 and Server 2016+, run Windows Update and get all security patches. On older systems like Windows 7 or Server 2008 R2, you need KB3140245 explicitly. Without it, TLS 1.2 won't even be an option in Schannel.

# Check installed updates on the command line
systeminfo | findstr /C:"KB3140245"

# If missing on Windows 7 SP1 or Server 2008 R2, download from Microsoft Catalog
# Reboot required after install

After installing, verify the registry keys exist:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled
# Should return 0x1

If the key doesn't exist, create it manually or install the update again. I've seen the update fail silently on locked-down systems — use wusa /extract to check the cab if you're paranoid.

Cause #2 — Group policy or registry disabling strong crypto

Sometimes IT hardens a machine by disabling old TLS versions but then blocks the new ones too. It's common in financial or healthcare environments with aggressive security baselines. They'll set Enabled to 0 for TLS 1.2 under both Client and Server.

The fix — check and correct registry

Open Regedit and navigate to:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Look for TLS 1.2. Under both Client and Server, the Enabled DWORD should be 1 and DisabledByDefault should be 0. If you see anything else, that's your problem.

# Set values via command line (admin prompt)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

Reboot after changing. Group policy can override these, so check gpedit.msc → Computer Configuration → Administrative Templates → Network → SSL Configuration Settings. If a policy is set, you'll need to change that instead.

Cause #3 — Application doesn't support strong crypto (legacy software)

Old apps — think SQL Server 2012, custom .NET apps targeting Framework 4.5 or below — might be hardcoded to use SSL 3.0 or TLS 1.0. When the OS drops those, the app fails with this error. I've seen this with a 2010-era payroll app that still used RC4.

The fix — force .NET to use TLS 1.2

If the app uses .NET Framework, you can override it with a registry key. This forces all apps to use TLS 1.2 regardless of what they request. But test first — some legacy apps break if they can't downgrade.

# For .NET Framework 4.6 and later
reg add "HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

# For .NET Framework 3.5
reg add "HKLM\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Reboot the app or service. If the app is non-.NET (C++ or Java), you'll need to update the app itself or change its configuration to use TLS 1.2. Java apps might need -Djavax.net.ssl.trustStore updated or the JVM updated to JDK 8u31+.

Quick-reference summary table

Start with the update. I've fixed this on hundreds of machines, and the update alone solves it 80% of the time. If not, dig into the registry. The legacy app scenario is rarer but bites you when you least expect it — usually during an audit.