Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows System Log · Event 36871
Schannel is the Windows component that does HTTPS and TLS. This event means it failed while preparing the credential for a connection — before any server was contacted. The internal error state number is the entire diagnostic, and 10013 means the two ends had no protocol in common.
Also written as Schannel 36871internal error state is 1001336871 tls error
Windows failed to set up a secure connection for a program. If nothing on your PC is actually broken, you can leave it — this event is logged even when the program then retried and succeeded. If something specific cannot reach the internet, this is a clue about why.
The overwhelming cause in the field is a machine with TLS 1.0 and 1.1 disabled by a hardening baseline, talking to something that offers nothing newer, or the reverse — an application pinned to an old .NET default that never enables TLS 1.2. Note the direction: 'client credential' means this machine was the one connecting out, 'server credential' means it was accepting. Registry state under SCHANNEL\Protocols governs both, and .NET applications additionally need SchUseStrongCrypto or an explicit SecurityProtocol setting, which is why a machine can be configured correctly and an application still fail.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
A fatal error occurred while creating a TLS client credential. The internal error state is 10013.Everything else in the log line is context.
10013No shared protocol or cipher suite. The most common value by a wide margin and almost always a TLS version mismatch. 10011A problem with the certificate itself — missing, expired, or without a usable private key. 10001The credential could not be acquired at all, often a permissions problem on the private key. 1205 or 1203The handshake was abandoned rather than failing on configuration. Most of the time it is one of these.
What gives it awaySudden appearance of these errors across many machines at once, correlating with a network change nobody announced.
ATT&CK T1557What gives it awayFailures from an unfamiliar process, repeating on a fixed interval, to a destination with no business reason.
ATT&CK T1573Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'} -MaxEvents 100 | Select-Object TimeCreated, Id, Message | Format-ListGet-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Recurse | ForEach-Object { [PSCustomObject]@{ Path = $_.Name; Enabled = (Get-ItemProperty $_.PSPath).Enabled; DisabledByDefault = (Get-ItemProperty $_.PSPath).DisabledByDefault } }Event | where EventLog == 'System' and Source == 'Schannel' | summarize count() by EventID, Computer, bin(TimeGenerated, 1h) | order by count_ descThe two ends could not agree on a protocol or cipher suite. In practice it nearly always means this machine has old TLS versions disabled and whatever it was talking to offers nothing newer, or the other way round. It is a configuration mismatch, not a fault in Windows or in the certificate.
Only as a last resort and only scoped to what needs it. Re-enabling an obsolete protocol machine-wide undoes the hardening that produced the error and reopens it for everything else on the box. Fix the far end where you can, and where you cannot, understand exactly which connection needs the exception before granting it.
Often yes. Many clients try a protocol, fail, and retry successfully with another — Schannel logs the failed attempt regardless. If no application is actually broken and the count is not growing, it is noise. What makes it worth chasing is a specific thing that stopped working at the same time the errors started.
The event does not name it, which is its biggest limitation. The practical approaches are to check the timing against scheduled tasks and services, to look at the application's own error log, or to capture traffic and match failed handshakes to a process. On a busy server, correlating with Sysmon network-connection events is the quickest route.
Last reviewed 6 September 2026