Fix SEC_I_CONTEXT_EXPIRED (0X00090317) – TLS Context Expired

Yeah, this error is annoying. Let's fix it.

If you're seeing SEC_I_CONTEXT_EXPIRED (0X00090317) in your event logs or while trying to connect to a server, you're not alone. This usually shows up in Schannel events or when an app like Outlook, SQL Server, or a web browser can't complete a TLS handshake. I had a client last month whose entire remote desktop setup stopped working because of this – turned out their system clock was off by 4 hours.

The Quick Fix – Check the System Date and Time

First thing: look at your system clock. If it's wrong, the TLS certificate validation fails because the certificate looks expired or not yet valid. Here's how to check:

1. Right-click the clock in the taskbar, pick "Adjust date/time".
2. Turn on "Set time automatically" and "Set time zone automatically".
3. If those are already on, click "Sync now" under Synchronize with an Internet time server.
4. Still wrong? Manually set the correct time zone and date, then sync again.

After that, restart any apps that were throwing the error. For me, this fixes about 70% of cases. Don't skip step 3 – manual sync often does the trick even if automatic sync looks fine.

Why This Works

TLS certificates have a validity period – they're only good between a specific start and end date. When your system clock is off, the certificate looks like it's either not yet valid or already expired. Windows Schannel sees that mismatch and shuts down the connection with SEC_I_CONTEXT_EXPIRED. It's not really the context that expired – it's the certificate validation that failed.

If Date/Time Isn't the Problem – Check TLS Settings

Sometimes the time is fine, but the error still shows up. This happens when the server you're connecting to requires a newer TLS version than what your Windows version supports by default. For example, if you're on Windows 7 without updates, it only supports TLS 1.0 and 1.1, but many servers now require TLS 1.2 or 1.3.

Enable TLS 1.2 (and maybe 1.3)

Here's how to enable it manually:

1. Open the Registry Editor (regedit) as Admin.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
3. If the path doesn't exist, create the folders under Protocols.
4. Create a DWORD (32-bit) named DisabledByDefault and set it to 0.
5. Create another DWORD named Enabled and set it to 1.
6. Restart your machine.

For TLS 1.3, do the same under the TLS 1.3 folder. On Windows 10 and 11, TLS 1.2 is usually already enabled, but older servers might need it forced. Also check your .NET Framework settings if you're using a .NET app – add this to your app config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/>
</runtime>

Less Common Culprits

VPN or Proxy Interference

Had a case where a corporate VPN was stripping TLS headers. Disconnect the VPN, test the connection. If it works, reconfigure the VPN client to pass TLS traffic through.

Corrupted Certificate Store

Rare, but sometimes a trusted root certificate gets corrupted. Run certlm.msc as admin, go to Trusted Root Certification Authorities, look for any certs with a red X, delete them, then run Windows Update to reinstall.

Firewall Blocking TLS Handshake

Some firewalls (especially third-party like ZoneAlarm) can block TLS when they detect a replay attack or expired session. Temporarily disable it to test.

Prevention – Keep Things Updated

• Enable automatic time sync (already mentioned, but do it).
• Run Windows Update regularly – it includes Schannel fixes and TLS protocol updates.
• If you manage servers, set up a time sync with an authoritative NTP server (e.g., time.windows.com).
• For old apps that need legacy TLS, don't disable modern TLS – enable both and let the app negotiate.

That's it. Most of the time it's just the clock. If not, check TLS settings. Don't waste time reinstalling Windows or your app – that won't fix this.