SEC_E_ENCRYPT_FAILURE 0x80090329 Fix – Schannel TLS Handshake

When This Error Hits

You're running a Windows Server 2016 or 2019 box, and suddenly clients can't connect over HTTPS. Or maybe your .NET app throws this during an outbound API call. The exact error in the System event log under Schannel (source) is SEC_E_ENCRYPT_FAILURE (0x80090329) – The specified data could not be encrypted. I've seen this most often after a Windows update, a certificate renewal, or when a client with an older TLS version tries to connect.

What's Actually Happening

The core issue is that Schannel – Windows' SSL/TLS implementation – gets through the initial handshake negotiation but fails when it tries to encrypt data. Usually because:

• The server's certificate doesn't match the private key (happens more than you'd think after a renewal)
• A cipher suite mismatch – the client and server can't agree on an encryption algorithm
• The certificate chain is broken – missing intermediate CA or expired root

Don't waste time blaming the network. The culprit is almost always a certificate or cipher configuration issue on the server side.

Fix It – Step by Step

Step 1: Check the Certificate

Open certlm.msc (Local Machine certificate store). Go to Personal > Certificates. Find the one bound to your HTTPS listener. Double-click it:

• Does the certificate date say "This certificate has a private key"? If not, it's useless – reimport it with the private key.
• Check the chain – the Path tab should show all intermediates. Missing one? Download and install the correct CA bundle.
• Verify the subject name matches the server's FQDN or the URL clients use. Wildcard mismatches are a common gotcha.

Step 2: Bind the Correct Certificate

Run this in an elevated command prompt to see what's bound:

netsh http show sslcert

Look for the IP:Port (usually 0.0.0.0:443). If the certificate hash doesn't match the one you just verified, delete and rebind:

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

Get the hash from the certificate's Thumbprint field in certlm.msc (remove the spaces). The appid can be anything – use {4dc3e181-e14b-4a21-b022-59fc669b0914} as a generic one.

Step 3: Enable All Supported Cipher Suites

Some Windows updates or security policies disable weaker ciphers. That can break older clients. Use Group Policy or the registry to ensure these are enabled:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256

In GPedit: Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. Set to 'Enabled' and paste the above list (comma separated, no spaces). If you don't use GP, edit reg directly:

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Create a string value named Functions – paste the cipher suite list there. Reboot after.

Step 4: Check Schannel Event Logs

Event ID 36888 with error code 0x80090329 will tell you the specific failure point. Look at the Sub Status field – it often gives you the exact TLS alert code. For example, alert 40 means handshake failure, alert 21 means bad certificate. Cross-reference with IANA TLS Alert Registry.

If It Still Fails

Try these in order:

1. Check the client's TLS version – is it at least TLS 1.0? Most Windows servers after 2020 force TLS 1.2. Enable TLS 1.0 in registry if needed (not recommended for security).
2. Use openssl s_client -connect server:443 -tls1_2 from a Linux box to see exactly where the handshake chokes. The output gives you the exact alert message.
3. Update .NET Framework to 4.8 or later – older versions have known Schannel bugs. I've seen 4.6.1 choke on this exact error.
4. As a last resort, reboot the server. Schannel caches some state, and a clean restart flushes it.

I've fixed this exact error on maybe 30 servers over the years. 90% of the time it's a certificate binding or cipher suite issue. Start there.