Fix the TLS Client Credential Error

“A fatal error occurred while creating a TLS client credential” means Windows could not prepare the security credentials an application needed for a TLS connection; the fix depends on which application failed and which TLS settings it supports. If the error started after legacy TLS was disabled, check the application’s driver or provider before weakening Windows security settings. Use the symptoms below to choose a starting point, then correlate the Windows event with the failed operation.

Symptom	Likely Area to Investigate	Best Starting Action
SQL or ODBC connections fail after TLS hardening	An older database driver cannot use the remaining protocols	Check the driver actually used by the application
Application sign-in fails at the same time	Authentication components, proxy configuration, or local TLS policy	Collect the application’s sign-in error and match its timestamp
Windows certificate-based Wi-Fi or wired authentication fails	Certificate selection, private-key access, or EAP-TLS configuration	Check the Windows authentication profile and certificate
Failures begin immediately after a security-policy change	Incompatible protocol or cipher restrictions	Compare effective settings with the approved baseline
Schannel errors appear without an obvious application failure	An unidentified background connection or retry	Identify the triggering process before changing anything

What the TLS Client Credential Error Means

Windows uses Schannel, its Secure Channel security provider, for many TLS connections. This message commonly appears in Event Viewer > Windows Logs > System, with source Schannel and Event ID 36871.

A frequently encountered version reads:

> A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

A TLS client credential is the local security configuration and cryptographic material Schannel uses to initiate a secure connection. It is not necessarily a client certificate, and it is not simply a username and password. Many ordinary HTTPS connections do not require a client certificate at all.

“Fatal” refers to the failed security operation, not necessarily a Windows crash or damaged operating system. Likewise, the internal error state is a diagnostic clue, not a complete diagnosis. Do not interpret 10013 automatically as the similarly numbered Winsock error or assume it proves a permissions problem.

The word “client” describes the connection role. A Windows server connecting outward to a database acts as a TLS client, even though the machine runs Windows Server.

Credential creation happens locally, while a completed TLS connection also requires compatibility with the remote endpoint. For SQL connections, both endpoints must support a common TLS protocol, per Microsoft’s SQL Server TLS troubleshooting guidance.

How to Fix the TLS Client Credential Error

Identify the failing application, update supported components, and repair the matching ODBC data source only when database access fails.

Step 1: Identify the Application That Actually Fails

Identify the failing workload before changing Windows TLS policy.

The same Schannel message can accompany database access, application authentication, or certificate-based network authentication. The event text alone does not identify which repair applies.

Open Event Viewer > Windows Logs > System and find the Schannel event. Save its timestamp, full message, event ID, and Details information.
If the message identifies an SSPI client process or process ID, record it. Do not assume every process ID in the event’s XML identifies the application making the connection.
Reproduce one operation: run the database job, attempt the application sign-in, or reconnect to the affected network.
Check whether a new Schannel event appears at that moment. Collect the application’s own error as well.
Record the application version, Windows version, destination service, and account running the application.

The account matters. A connection that works from an administrator’s desktop may still fail from a Windows service using a different identity, certificate store, proxy configuration, or data source.

If no operation fails, leave security settings unchanged while investigating the background process. Clearing the log or disabling Schannel logging does not repair the connection.

Step 2: Check Recent Changes and Supported Components

Start with the narrowest changes rather than immediately editing the registry.

Identify what changed since the last successful connection: Windows updates, application updates, driver replacement, certificate renewal, proxy configuration, or security-policy deployment.
Install applicable, vendor-supported updates for the affected application, runtime, and connection provider. For production systems, use the application vendor’s supported versions rather than assuming the newest driver is compatible.
Confirm that the Windows release, client provider, and remote service share a supported TLS version. TLS 1.2 is a common compatibility target for older database integrations, but the complete software stack must support it.
For applications you maintain, inspect code and configuration for an explicitly selected obsolete protocol. Use the runtime’s supported system-default TLS behavior where available instead of forcing an outdated protocol.
Restart the updated application or service as required, then repeat the original operation.

A successful browser or OpenSSL test does not necessarily validate the affected application. Different programs can use different TLS libraries, providers, identities, and certificate stores.

If an update resolves the failure, stop making configuration changes. If it does not, keep the new error details: an update may expose a different problem, such as certificate validation, that needs its own diagnosis.

Step 3: Repair the ODBC Data Source When Database Access Fails

Use this branch when the correlated failure is a SQL/ODBC connection, particularly after legacy TLS was disabled. Otherwise, leave ODBC configuration unchanged.

Useful application-side clues include DBNETLIB, ConnectionOpen (SECCreateCredentials()), or “SSL Security Error.” These are more informative than an unrelated Schannel entry elsewhere in the log.

Confirm the application’s bitness. A 64-bit Windows installation can run a 32-bit database application. The ODBC administrator must match the application, not merely the operating system.
Back up the data-source configuration before replacing it. In Registry Editor, select the following key and use File > Export: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBC.INI\ODBC Data Sources This key contains the 32-bit system data-source listings and driver associations. Also export the affected DSN’s configuration subkey under ODBC.INI; the listings alone are not a complete backup of its connection settings. Record its server, database, authentication method, and encryption options, and protect the exported files as potentially sensitive configuration.
Install a compatible replacement provider. For Planning Analytics 2.0.9 on Windows Server 2019, the documented repair replaces Microsoft SQL Server ODBC Driver Version 10.00.14393 with Microsoft SQL Server Native Client Version 11.00.7462 (Planning Analytics repair details). These are exact versions from that legacy installation, not a universal upgrade range. Native Client is a legacy provider; for current deployments, choose a Microsoft ODBC Driver for SQL Server version supported by the application and SQL Server build.
Reconfigure the affected data source. For that 32-bit setup, open Control Panel > Administrative Tools > ODBC Data Sources (32-bit). Confirm the installed provider’s exact version on the Drivers tab, then replace the affected DSN using the replacement driver while preserving its original data-source name, server, selected database, and intended authentication settings. Installing a driver does not automatically switch an existing DSN to it. For a 64-bit application, use ODBC Data Sources (64-bit) and back up the corresponding configuration instead.
Test both the DSN and the real application. Run the driver’s connection test if available, restart the affected application or service if it retains connections, and rerun the original job under its normal identity.

If the replacement produces a certificate-validation error, investigate the certificate name, trust chain, and encryption requirements rather than disabling validation. If the change cannot be validated, restore the original DSN configuration and driver selection from the backup before attempting another repair.

Step 4: Inspect Both Client and Server TLS Policy

If the application and provider support modern TLS but the failure persists, inspect the effective Windows policy.

In Registry Editor, examine: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Inspect both Client and Server subkeys for the protocols involved. A machine can initiate one connection and accept another, so changing only one role does not establish its complete TLS configuration.
Compare the settings with the organization’s approved baseline and the supported protocols for that Windows version.
Determine whether Group Policy or a configuration-management tool owns the settings. Correct a managed setting at its source rather than making a local edit that will be overwritten.
If a required, supported protocol was disabled accidentally, restore the approved configuration and restart the affected components as required before retesting.

A missing protocol key does not automatically mean that protocol is disabled. Windows can use version-dependent defaults when explicit values are absent.

Also inspect recently changed cipher-suite restrictions. Enabling a protocol does not guarantee that an application has a usable cryptographic configuration.

Step 5: Apply Legacy-TLS Hardening Only When It Is Intended

The following commands reproduce the legacy-protocol policy used with the Planning Analytics repair. They disable legacy TLS; they are not a general-purpose fix for credential errors and do not enable modern TLS. Running them against an incompatible application can cause or prolong the failure.

Use them only when disabling those protocols is the approved goal and the affected client has been made compatible.

Export the affected Schannel registry branch before changing it. On a managed server, obtain approval and arrange recovery access in case a service or remote connection stops working.
Open Command Prompt using Run as administrator.
Apply only the settings required by the approved policy.

For this configuration, each listed protocol-role key uses DWORD Enabled set to 0 and DisabledByDefault set to 1. These are switches, not a variable range. Confirm the current and intended values in each named key on the affected server; /f overwrites an existing value without prompting.

For the TLS 1.0 Server role:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

For the TLS 1.0 Client role:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

For the TLS 1.1 Server role:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

For the TLS 1.1 Client role:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

After applying the approved changes, arrange a controlled restart so applications do not continue using cached credential handles. Repeat the original application operation and test any other affected services.

If the change causes a regression, restore the saved configuration through the policy mechanism that owns it, restart as required, and verify service recovery. Re-enabling obsolete protocols should not become the permanent substitute for repairing an incompatible client.

Correlate sign-in or network authentication failures with application, certificate, proxy, and RADIUS records before correcting the identified problem.

For Microsoft 365 Apps or another desktop application, a nearby Schannel event is not enough to prove that TLS policy caused the sign-in failure.

Capture the application’s exact authentication error, timestamp, and any correlation identifier.
Check the Windows clock, application update status, and whether the failure follows the same account, device, or network.
Inspect the proxy and any TLS-inspection configuration used by the affected application. Confirm required organizational trust certificates are deployed through the approved mechanism.
Correct the identified application, trust, or proxy problem, restart the application, and attempt the same sign-in again.

Do not disable certificate validation, clear broad credential stores, or reset system-wide TLS settings simply because an authentication dialog failed.

If the problem remains, provide the identity or application administrator with the correlated sign-in and Schannel records. That is a safer escalation point than experimenting with unrelated registry settings.

Certificate-Based Wi-Fi and Wired Authentication

In an EAP-TLS setup, Windows can fail to connect even when macOS and other devices connect successfully.

Confirm whether the Windows network profile uses user authentication or computer authentication.
Open the certificate-management console for that identity. Search Windows for Manage user certificates or Manage computer certificates, as appropriate.
Check that the intended certificate is valid, has an accessible private key, supports the required client-authentication purpose, and has the appropriate certificate chain.
Compare the Windows EAP profile with the intended RADIUS server name and trusted issuing authorities. Check the WLAN-AutoConfig or Wired-AutoConfig logs alongside the RADIUS server’s authentication logs.
Correct certificate enrollment or deploy the approved network profile, then reconnect and verify that authentication and network access succeed.

If the private key is inaccessible, repair access for the specific authentication identity through the certificate-management process. Do not grant broad permissions to Windows cryptographic folders.

For a managed network, unresolved certificate-selection or RADIUS rejection errors belong with the network administrator, accompanied by the Windows-side event and server-side rejection details.

How to Confirm the Fix and Prevent Recurrence

A successful repair means the original operation works, not merely that Event Viewer looks quieter.

Use this checklist after the relevant repair:

The original job, sign-in, or network connection succeeds.
It works under the normal user or service identity.
No new correlated Schannel credential-creation event appears during that test.
The intended security policy remains in place.
Other services affected by a system-wide change still work.

Keep the previous configuration and a record of the successful driver, runtime, application, and policy combination. Before future TLS hardening, inventory the applications that use Windows security providers, confirm their compatibility, and test the actual workloads in a representative environment.

If the error remains, collect the Windows build, application and provider versions, full Schannel event, application error, destination, recent changes, and a reproducible test. Use that evidence to choose the next targeted repair instead of applying a bundle of registry changes.

Frequently Asked Questions

What Does Fatal Error C0000022 Mean?

The Windows status code 0xC0000022 means STATUS_ACCESS_DENIED. It is not interchangeable with Schannel’s internal error state, even if both appear near a failed operation. Identify which process was denied access and which resource it tried to use before changing permissions.

Is an SSL Server Credential Error Fixed the Same Way?

Not necessarily: an SSL or TLS server credential error concerns an application accepting secure connections rather than initiating them. Check its certificate binding, certificate store, private-key availability, and access for the service identity, along with its supported TLS configuration. Replacing an outbound ODBC driver will not repair an unrelated inbound server credential problem.

Do I Need to Reinstall Windows After This Fatal Error?

Usually not; “fatal” describes the failed security operation and does not by itself establish Windows corruption. Driver compatibility, application configuration, certificate access, and TLS policy are more useful starting points for this message. Consider operating-system repair only when separate diagnostic evidence shows an operating-system problem.