0x80090337 SEC_E_CRYPTO_SYSTEM_INVALID crypto fix

Cause #1: Corrupted Schannel registry key (most common)

What's actually happening here is that Windows's Schannel (Secure Channel) component—which handles TLS/SSL—can't verify the cryptographic checksum during a handshake. The error pops up in Event Viewer as ID 36888, often after a failed RDP connection, an IIS request, or a .NET app calling a web service. I've seen it most on Windows Server 2016 and Windows 10 1909+ after a failed update or a manual registry tweak gone wrong.

The fix is to reset the Schannel registry to its defaults. Don't bother trying to repair just one key — you'll miss something. Nuke the whole Schannel subkey and let Windows rebuild it on next boot.

1. Open Regedit as Administrator.
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.
3. Right-click the Schannel key and export it as a backup (just in case).
4. Delete the entire Schannel key.
5. Reboot the machine.

After reboot, Windows re-creates the Schannel key with default cipher suites and protocols. The error should vanish. If it doesn't, move to cause #2.

Cause #2: Missing or disabled required cipher suite

The error 0x80090337 also fires when the client and server can't agree on a common cipher suite during handshake. This usually happens after a security hardening script disabled weak ciphers like RC4 or 3DES, but went too far and removed everything. Seen this on Windows Server 2019 after a CIS benchmark script ran.

The reason step 3 works is that Schannel needs at least one enabled cipher suite of each type (key exchange, authentication, encryption, hash). If you have TLS 1.2 enabled but no matching cipher, the handshake fails with this exact code.

Check your enabled cipher suites:

Get-TlsCipherSuite | Where-Object { $_.Enabled -eq $true } | Format-Table Name, Cipher, KeyExchange, Hash -AutoSize

If this returns nothing or only a couple suites, you need to add a safe fallback. I recommend:

Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"

These are supported on Windows 8.1 / Server 2012 R2 and later. If you're on Windows 10 1607+, you can also enable GCM suites:

Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"

Reboot after enabling. Test with openssl s_client -connect yourserver:443 -tls1_2 from a remote machine. If the handshake completes, you're cured.

Cause #3: Corrupted TLS certificate or private key

Less common, but when it hits, it's nasty. The crypto system can be invalid if one of the certificates in the chain has a mangled public key or the private key can't be accessed. I've seen this when a certificate was imported from a backup that had a different user profile or the machine key container got corrupted.

Open the Certificates MMC snap-in (certlm.msc for local machine). Look for any certificate with a yellow warning icon — that means the private key is missing or broken. Also check Event ID 36870 and 36871 in the System log; they'll point to the thumbprint of the bad cert.

If you find a bad cert, delete it and re-import it from a fresh .pfx export that includes the private key with strong protection:

certutil -importPFX -p YourPassword C:\path\to\cert.pfx

Make sure to select Mark this key as exportable during import only if you need backups. Skip it otherwise — it's a security risk.

If the cert is for IIS, rebind it after re-import:

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINT appid="{GUID}"

Get the app ID from the existing binding or use {00000000-0000-0000-0000-000000000000} for system-wide. Restart IIS with iisreset.

Quick reference summary

Start with cause #1 — it's the most common and the quickest to test. If the error persists, check cipher suites. Only then dig into certificates. Most people waste hours on certs when the real problem was a stale registry key.