SEC_E_UNSUPPORTED_FUNCTION (0x80090302) Fix: TLS & Kerberos Issues

Broken TLS Settings (The Most Common Cause)

I know this error is infuriating — one minute you're connecting to a server or opening Outlook, the next you get SEC_E_UNSUPPORTED_FUNCTION (0x80090302). Nine times out of ten, it's because Windows has its TLS settings scrambled. This happens after a botched Windows update, a security tool disabled TLS 1.2, or a registry tweak went sideways.

The real fix is checking and enabling TLS 1.2 on your system. Here's how to do it:

1. Press Win + R, type regedit, and hit Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client.
3. If the TLS 1.2 or Client keys don't exist, right-click Protocols → New → Key → name it TLS 1.2. Then inside that, create a Client key.
4. Inside the Client key, create a DWORD (32-bit) called DisabledByDefault and set it to 0.
5. Create another DWORD called Enabled and set it to 1.
6. Do the same for Server under TLS 1.2 (if you want both sides enabled).
7. Reboot your PC.

After the reboot, try your connection again. This tripped me up the first time too — I spent hours chasing the wrong cause before realizing TLS 1.2 was disabled.

Pro tip: If you're on Windows 7 or Server 2008 R2, you need the KB3140245 update to fully support TLS 1.2. Without it, the registry fix alone won't stick.

Outdated or Corrupted Windows Security Stack

Sometimes the error isn't about config — it's about missing updates. Windows updates routinely patch schannel.dll and related security components. If you're running an old build (especially Windows 10 1809 or earlier, or Windows 11 21H2), you're more likely to see this error when connecting to modern servers that require TLS 1.2 or higher.

Here's what I do when registry tweaks don't work:

1. Open Settings → Update & Security → Windows Update → Check for updates. Install all pending updates, especially optional security patches.
2. If you're on Windows 11 22H2 or later, also check for the latest cumulative update under Advanced options.
3. After updates install, reboot and test.

Specific scenario: I've seen this error most often when someone tries to connect to Microsoft 365 services (Outlook, Exchange Online) from an old Windows 10 build. The server rejects the client's outdated TLS version. Updating Windows 10 to at least version 20H2 (or better, 22H2) resolves it every time.

If you can't update Windows (maybe you're on a locked-down corporate machine), you can try enabling TLS 1.2 manually via .NET Framework. Open PowerShell as admin and run:

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

This sets the .NET apps to use TLS 1.2 for the current session. For a permanent fix, set the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto to 1 (DWORD).

Kerberos Authentication Mismatch (Enterprise/AD Scenarios)

If you're on a corporate network and this error shows up when you try to access a SharePoint site, SQL Server, or a file share, it's likely a Kerberos problem. The SEC_E_UNSUPPORTED_FUNCTION error here means the Kerberos token your machine sent doesn't match what the server expects.

This usually happens after a domain controller upgrade or a security policy change. The fix involves checking the Kerberos encryption types on both sides.

1. On the client machine, open Local Group Policy Editor (gpedit.msc).
2. Go to Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
3. Find Network security: Configure encryption types allowed for Kerberos.
4. Make sure AES256_HMAC_SHA1 and AES128_HMAC_SHA1 are checked. Also check RC4_HMAC_MD5 if your environment still uses older systems.
5. Click OK, then run gpupdate /force in Command Prompt (as admin).
6. Reboot and test.

Real-world trigger: I saw this at a client's office after they migrated from Server 2012 R2 to Server 2022. The new domain controllers stopped accepting RC4-encrypted tickets by default, but the old workstations hadn't been updated to support AES. Enabling AES on the clients fixed it immediately.

If group policy changes don't work, you can also check the client's Kerberos ticket cache. Run klist purge in Command Prompt (as admin) to clear old tickets, then try accessing the resource again.

Quick-Reference Summary Table