A Fatal Error Occurred While Creating A TLS Client Credential | Fast Fix Guide

Seeing the event log message “a fatal error occurred while creating a tls client credential” can be worrying, especially when it repeats every few seconds or breaks line-of-business apps. The text is vague, the Event Viewer entry points at Schannel, and nothing on the desktop tells you what actually failed.

This guide walks through what the error really means, where it comes from, and clear steps you can use to stop it while keeping your Windows security level in a healthy place. The focus is on practical checks and fixes you can apply on Windows 10, Windows 11, and recent Windows Server builds.

What A Fatal Error Occurred While Creating A TLS Client Credential Means

The full entry usually shows up as Event ID 36871 under Schannel in the System log: “A fatal error occurred while creating a TLS client credential. The internal error state is 10013.” In plain terms, Windows tried to start a secure TLS session as a client and failed before the handshake finished.

TLS (Transport Layer Security) protects HTTPS, mail, and many other protocols by setting up an encrypted tunnel between client and server. During the handshake, both sides must agree on a protocol version (TLS 1.0, 1.1, 1.2, 1.3) and a cipher suite. If your system or the remote endpoint refuses the versions or ciphers on the table, the client credential cannot be created and Schannel logs this fatal error.

In many real cases, the log noise appears after someone tightens protocol settings, installs updates, or hardens a server with a tool such as IIS Crypto. Once older TLS versions or weak ciphers disappear, older apps and services sometimes cannot connect anymore and trigger the message.

Main Causes At A Glance

Here are common reasons this TLS client credential error appears on Windows systems:

• Disabled protocol versions — TLS 1.0 or 1.1 is turned off while legacy software still expects those versions.
• Missing or broken TLS 1.2 setup — Registry keys for TLS 1.2 are missing or disabled, so newer software cannot fall back correctly.
• Cipher suite mismatch — The server only allows a narrow cipher set that does not overlap with your client settings.
• Certificate problems — Expired, missing, or untrusted certificates cause the handshake to fail when client authentication is required.
• Security tools or policies — Group Policy, antivirus, or endpoint security tools block specific TLS versions or algorithms.

Quick Cause And Symptom Map

In short, when you see “a fatal error occurred while creating a tls client credential,” you are dealing with a handshake problem. The rest of this article focuses on safe ways to restore the handshake without dropping your security level more than needed.

Windows TLS Client Credential Error 10013 Fixes

Because this problem lives in the TLS stack, you fix it by lining up protocol versions, ciphers, and certificates between your system and the remote endpoint. A good workflow starts with simple checks, then moves into registry or policy changes only if needed.

Before changing anything, grab a quick snapshot of your current configuration. Screenshots from Internet Options, exported registry keys, or an IIS Crypto configuration file save time if you have to roll back.

1. Confirm where the error appears — Open Event Viewer, head to Windows Logs > System, and filter on source Schannel and event ID 36871 to verify the error pattern and timing.
2. Match errors to real failures — Check whether users or services report broken connections that line up with the timestamps, or whether this is mostly background noise.
3. Test with a browser — From the same machine, open the affected site in a modern browser; if the page fails with TLS messages, you know the problem is not just a single app.
4. Check TLS toggles first — Use inetcpl.cpl (Internet Options) to inspect protocol checkboxes before you touch the registry.

Once you have a clear picture, you can work through the main fixes for “a fatal error occurred while creating a tls client credential” in a controlled way.

Step-By-Step Fixes For A Fatal Error Occurred While Creating A TLS Client Credential

Check TLS Versions In Internet Options

Quick check: Start with the simplest view of TLS on the box. On many systems, Internet Options still controls Schannel at the OS level, especially for older apps that use WinHTTP or WinINET.

1. Open Internet Options — Press Win + R, type inetcpl.cpl, and press Enter.
2. Go to the Advanced tab — Scroll down to the Security section.
3. Review TLS entries — Look at the checkboxes for “Use TLS 1.0,” “Use TLS 1.1,” and “Use TLS 1.2.” Newer builds may also show TLS 1.3.
4. Keep TLS 1.2 on — Ensure “Use TLS 1.2” is selected, as this is the modern baseline for most services.

If TLS 1.2 was off and you enable it, test the failing app or site again. In many environments this single switch removes the repeated client credential error events.

Enable TLS 1.2 Correctly In The Registry

Deeper fix: Internet Options sometimes hides registry gaps. On hardened servers, TLS 1.2 might be checked in the UI while the underlying SCHANNEL keys are missing or disabled.

Before editing the registry, export the relevant keys or a system restore point so you have a way back if something goes wrong.

1. Open Registry Editor — Press Win + R, type regedit, and press Enter.
2. Browse to the TLS protocols path — Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
3. Confirm TLS 1.2 keys — Under Protocols, check that TLS 1.2\Client and TLS 1.2\Server exist.
4. Set enabled values — Inside each Client and Server key, create or edit DWORD values named Enabled (set to 1) and DisabledByDefault (set to 0).
5. Restart the machine — A reboot reloads the SCHANNEL configuration.

Many guides, and Microsoft’s own notes, point out that this proper TLS 1.2 configuration removes the need to turn on older protocol versions in order to stop the 10013 error flood.

Avoid Permanent Use Of TLS 1.0 And 1.1

Risk check: In some tutorials, the quick fix is to enable TLS 1.0 and TLS 1.1 globally, either via Internet Options or IIS Crypto. That can silence “A Fatal Error Occurred While Creating A TLS Client Credential” for older apps, but it also brings back protocols that Microsoft has deprecated for security reasons.

• Use legacy TLS only for testing — Turn on TLS 1.0/1.1 briefly to confirm that a failing app really needs those versions.
• Scope the change — Prefer per-app configuration or isolated servers instead of enabling legacy TLS across an entire farm.
• Plan a replacement — Once you confirm that legacy TLS is required, schedule an upgrade for the app or endpoint so you can turn those versions off again.

This balance lets you clear the TLS client credential error while still keeping your broader security posture in good shape.

Check Certificates And System Time

Health check: When client authentication comes into play, certificate problems can also trigger the fatal TLS error. A client certificate with the wrong key usage, an expired chain, or a machine clock that drifts far from reality can break the handshake.

1. Verify system time — Make sure the server or workstation follows a reliable time source; large drift can break certificate validation.
2. Inspect the certificate store — Open the Certificates snap-in for the local computer and confirm that required client and root certificates exist and are not expired.
3. Match certificates to the app — Check whether the failing app or service points to a specific certificate, and confirm that thumbprint still matches what is in the store.

Review Security Software And Policies

Policy check: Endpoint protection suites, SSL inspection, and Group Policy hardening templates can all restrict TLS. In some setups, these tools remove cipher suites or protocols that one line-of-business service still needs.

• Compare with a clean system — If you can, test the same connection from a similar Windows build without the extra security tools.
• Review applied GPOs — Look for settings under Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.
• Check firewall logs — Inspect logs for blocked TLS handshakes or deep packet inspection errors during the timeframe of the 36871 events.

Repair System Files And .NET TLS Settings

Stability check: Corrupted system files or older .NET settings can also trigger this TLS client credential failure, especially on servers that have been through many upgrade cycles.

1. Run SFC and DISM — From an elevated command prompt, run sfc /scannow, then use DISM /Online /Cleanup-Image /RestoreHealth if SFC finds issues.
2. Review .NET configuration — For apps built on .NET, confirm that they use the OS default TLS settings rather than hard-coding an older protocol such as TLS 1.0.

By the time you reach this point, most cases of “a fatal error occurred while creating a tls client credential” should either be resolved or clearly tied to one legacy app or endpoint that needs extra handling.

Safer Handling For Legacy Apps That Depend On Old TLS

Sometimes the reality is simple: the only way an older app talks to its server is by using TLS 1.0 or 1.1. Turning those protocols off then leads straight to Event ID 36871 entries and connection failures. In that situation, the goal is to keep the risk as contained as possible.

Contain The Risk Instead Of Opening Everything

• Isolate legacy workloads — Move the app to a dedicated server or VM where you can enable older TLS versions without exposing the rest of the environment.
• Limit network access — Use firewalls and access rules so that only the needed systems can reach the legacy service.
• Monitor the event log — Keep an eye on Schannel events; new errors or spikes may point at configuration drift or fresh misconfigurations.

Plan Migration Off Deprecated TLS

Legacy TLS is not just a noisy line in the event log. It also opens the door to attacks that modern protocols prevent. Treat the “A Fatal Error Occurred While Creating A TLS Client Credential” warning as a nudge to move away from software that insists on TLS 1.0 or 1.1.

• Map dependency chains — Identify which apps and partners still rely on legacy TLS versions.
• Coordinate with vendors — Ask vendors for versions that support TLS 1.2 or 1.3 and confirm upgrade paths.
• Test upgrades in a lab — Validate new builds in a non-production environment so you can switch protocol settings with confidence later.

How To Prevent TLS Client Credential Errors Over Time

Once the current issue is under control, you can lower the chance of seeing the same TLS client credential error again by tightening a few habits around updates, monitoring, and change control.

Keep TLS Settings And Windows Builds Aligned

• Stay current with updates — Apply security and .NET patches on a regular schedule, especially those related to cryptography and networking.
• Review TLS policy after hardening — When you change cipher suites or disable protocols, schedule validation for key apps soon after the change.
• Document standard settings — Keep a short baseline of approved TLS versions and ciphers so you can spot and correct drift.

Use Logging And Tools To Catch Problems Early

• Watch Schannel logs — Set up basic alerting if Event ID 36871 spikes, since that often signals a new compatibility problem.
• Run TLS scanners — Periodically scan public-facing services to verify which protocol versions and ciphers are active.
• Test from both sides — Check connections from client to server and from server back to known endpoints, especially after configuration changes.

Handled carefully, “A Fatal Error Occurred While Creating A TLS Client Credential” does not have to mean days of downtime. With a methodical approach that starts at Internet Options, confirms TLS 1.2 in the registry, and then looks at certificates and policy, you can bring connections back while still keeping old and weak protocols under tight control.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback