SEC_E_ALGORITHM_MISMATCH (0x80090331) Fix: Common Algorithm Not Found

You're stuck because of a cipher suite mismatch — here's what that means

I know this error is infuriating. You try to connect to a website, a Remote Desktop session, or an IIS server and you get SEC_E_ALGORITHM_MISMATCH (0x80090331). The full message reads: "The client and server cannot communicate because they do not possess a common algorithm."

This tripped me up the first time too — especially on Windows Server 2012 R2 or Windows 8.1 boxes. Basically, your client and the server can't agree on an encryption algorithm to use during the TLS handshake. One side wants something the other doesn't support. Usually, the server is running an old OS that only has deprecated ciphers, or the client has newer defaults that block them.

Let's fix this. I'll cover the three most common causes in order — start with #1, because that's the fix 80% of the time.

1. The server is missing TLS 1.2 or modern cipher suites

This is by far the most common cause. If you're hitting this on a Windows Server 2012 R2, Windows 8.1, or even an older Windows 10 build (pre-1607), TLS 1.2 isn't enabled by default. The server only offers TLS 1.0 (broken) or weak ciphers like RC4, and the client (modern Chrome, Edge, or a Windows 10/11 machine) refuses to use them.

How to enable TLS 1.2 on Windows Server 2012 R2 / 8.1

Open PowerShell as Administrator and run these commands. They enable TLS 1.2 for both client and server roles:

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'DisabledByDefault' -Value 0 -Type DWord
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -Value 0 -Type DWord

Reboot the server. Then try the connection again.

Still failing? The server might need the Schannel update for TLS 1.2. On Windows Server 2012 R2 — install KB3140245. Without that, TLS 1.2 registry keys don't stick. Check your Windows Update history.

2. The client (or server) has weak ciphers disabled — or missing a required cipher

Sometimes TLS 1.2 is enabled, but the cipher suites don't match. Modern Windows (10/11, Server 2016+) disables RC4, 3DES, and sometimes even AES-CBC by default. If the server only offers AES-CBC or older ciphers — boom, mismatch.

Quick fix — use Nartac IIS Crypto to see what's enabled

Download Nartac IIS Crypto from nartac.com. Run it, and on the Ciphers tab, verify these ciphers are enabled:

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

If any are unchecked, check them, click Apply, reboot.

PowerShell alternative: List all cipher suites on the local machine:

Get-TlsCipherSuite

If you don't see any GCM suites, you need to add them. Here's how to enable a specific one:

Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Repeat for the others.

I prefer Nartac for this — it's faster and shows you exactly what's missing.

3. You're using an outdated .NET framework that doesn't support modern TLS

This one gets developers. Your app — maybe a C# console app, an ASP.NET website, or an old PowerShell script — is built against .NET 3.5 or 4.0. Those frameworks default to SSL 3.0 or TLS 1.0, which modern servers reject. Even if the OS supports TLS 1.2, the app won't use it unless you tell it to.

Fix for .NET apps

Add this line at the very start of your code (before any network call):

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

In PowerShell, it's:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

But wait — don't hard-code it to only TLS 1.2. Future-proof it by using:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 | System.Net.SecurityProtocolType.Tls13;

If you're stuck on .NET 3.5 (like legacy apps on Windows 7 or Server 2008), you can enable TLS 1.2 support by installing the Schannel update (KB3140245) and setting the SchUseStrongCrypto registry key:

New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\System.Net' -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\System.Net' -Name 'SchUseStrongCrypto' -Value 1 -Type DWord
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\System.Net' -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\System.Net' -Name 'SchUseStrongCrypto' -Value 1 -Type DWord

Reboot after this.

Quick-reference summary table

Start with cause #1. That's the most common by far — especially on older servers. If you're still stuck after trying all three, the server might be using a custom application that's hard-coded to a specific cipher. In that case — check the application logs on both sides for the exact cipher suite being offered. Good luck.