ANAVEM
Languagefr
Network security monitoring dashboard showing TLS handshake analysis and Windows Schannel event logs
Event ID 36874ErrorSchannelWindows

Windows Event ID 36874 – Schannel: TLS Connection Handshake Failure

Event ID 36874 indicates a TLS handshake failure in the Schannel security provider, typically occurring when secure connections cannot be established due to protocol mismatches, certificate issues, or cipher suite incompatibilities.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
19 March 202612 min read 0
Event ID 36874Schannel 5 methods 12 min
Event Reference

What This Event Means

Event ID 36874 represents a critical security event that occurs when the Windows Schannel provider cannot complete a TLS handshake with a remote endpoint. The handshake process involves multiple steps including protocol version negotiation, cipher suite selection, certificate validation, and key exchange. Failure at any of these stages triggers this event.

The event details typically include the remote IP address or hostname, the attempted TLS protocol version, and a specific error code indicating the failure reason. Common scenarios include attempting to connect to servers using deprecated TLS 1.0 or 1.1 protocols, certificate validation failures due to expired or untrusted certificates, cipher suite mismatches where no common encryption algorithms are supported, and network connectivity issues during the handshake process.

In Windows Server environments, this event often appears when clients attempt to connect using outdated protocols or when certificate chains cannot be validated. The event is also common in environments with strict Group Policy settings that disable certain TLS versions or cipher suites for security compliance. Understanding the specific failure reason is crucial for determining whether the issue stems from client configuration, server configuration, or network infrastructure problems.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • TLS protocol version mismatch between client and server endpoints
  • Expired, revoked, or untrusted SSL/TLS certificates on the remote server
  • Cipher suite incompatibility where no common encryption algorithms are supported
  • Certificate chain validation failures due to missing intermediate certificates
  • Group Policy restrictions disabling specific TLS versions or cipher suites
  • Network connectivity issues interrupting the handshake process
  • Firewall or proxy interference with TLS negotiation packets
  • Server-side SSL/TLS configuration errors or service failures
  • Client-side certificate store corruption or missing root certificates
  • Time synchronization issues affecting certificate validity checks
Resolution Methods

Troubleshooting Steps

01

Analyze Event Details in Event Viewer

Start by examining the complete event details to understand the specific failure reason and remote endpoint information.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSystem
  3. Filter for Event ID 36874 by right-clicking the System log and selecting Filter Current Log
  4. Enter 36874 in the Event IDs field and click OK
  5. Double-click the most recent Event ID 36874 to view detailed information
  6. Note the remote endpoint IP address, protocol version, and error description
  7. Check the event timestamp to correlate with application or service connection attempts

Use PowerShell to extract multiple events for pattern analysis:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=36874} -MaxEvents 50 | Select-Object TimeCreated, Message | Format-Table -Wrap
Pro tip: Look for recurring patterns in the remote endpoints or specific times when failures occur to identify systematic issues.
02

Check TLS Protocol Configuration

Verify the TLS protocol settings on the local system to ensure compatibility with remote endpoints.

  1. Open Registry Editor as Administrator
  2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
  3. Check for subkeys like TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3
  4. Under each protocol version, examine the Client and Server subkeys
  5. Verify the Enabled and DisabledByDefault DWORD values

Use PowerShell to check current TLS configuration:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\*\*' | Select-Object PSPath, Enabled, DisabledByDefault

To enable TLS 1.2 client connections if disabled:

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -Value 0 -PropertyType DWORD -Force
Warning: Modifying TLS protocol settings requires a system restart and can affect all SSL/TLS connections system-wide.
03

Validate Certificate Chain and Trust Store

Examine the certificate chain and trust store to identify certificate-related handshake failures.

  1. Open Microsoft Management Console by running mmc.exe as Administrator
  2. Add the Certificates snap-in for Computer account
  3. Navigate to Certificates (Local Computer)Trusted Root Certification AuthoritiesCertificates
  4. Verify that required root certificates are present and not expired
  5. Check Intermediate Certification Authorities for missing intermediate certificates

Use PowerShell to test certificate chain validation for a specific endpoint:

$endpoint = "example.com"
$port = 443
$tcpClient = New-Object System.Net.Sockets.TcpClient
$tcpClient.Connect($endpoint, $port)
$sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream())
try {
    $sslStream.AuthenticateAsClient($endpoint)
    Write-Host "Certificate validation successful" -ForegroundColor Green
    $sslStream.RemoteCertificate | Format-List
} catch {
    Write-Host "Certificate validation failed: $($_.Exception.Message)" -ForegroundColor Red
} finally {
    $sslStream.Close()
    $tcpClient.Close()
}

To update the certificate store from Windows Update:

certlm.msc  # Open Certificate Manager
# Or use PowerShell to update root certificates
Invoke-Expression "certutil -generateSSTFromWU roots.sst"
Invoke-Expression "certutil -addstore -f root roots.sst"
04

Configure Cipher Suite Preferences

Adjust cipher suite configuration to resolve compatibility issues with remote endpoints.

  1. Open Group Policy Editor by running gpedit.msc
  2. Navigate to Computer ConfigurationAdministrative TemplatesNetworkSSL Configuration Settings
  3. Configure SSL Cipher Suite Order policy if available
  4. Alternatively, use PowerShell to manage cipher suites directly

List current cipher suite order:

Get-TlsCipherSuite | Select-Object Name, Certificate, KeyExchange, Cipher, Hash | Format-Table -AutoSize

Enable specific cipher suites for compatibility:

# Enable TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 if disabled
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"

# Set cipher suite priority order
$cipherOrder = @(
    "TLS_AES_256_GCM_SHA384",
    "TLS_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
)

foreach ($cipher in $cipherOrder) {
    Enable-TlsCipherSuite -Name $cipher
}

Check registry for cipher suite configuration:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002' -Name Functions -ErrorAction SilentlyContinue
Pro tip: Modern applications in 2026 prefer AEAD cipher suites like AES-GCM for better security and performance.
05

Enable Detailed Schannel Logging and Network Analysis

Implement comprehensive logging and network analysis to diagnose complex handshake failures.

  1. Enable detailed Schannel event logging in the registry
  2. Configure network packet capture for TLS handshake analysis
  3. Use Windows Performance Toolkit for advanced diagnostics

Enable verbose Schannel logging:

# Enable Schannel event logging
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL' -Name 'EventLogging' -Value 7 -PropertyType DWORD -Force

# Enable TLS handshake logging (Windows Server 2022/2025)
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL' -Name 'LogLevel' -Value 7 -PropertyType DWORD -Force

Capture network traffic for handshake analysis:

# Start network capture with netsh
netsh trace start capture=yes provider=Microsoft-Windows-TCPIP tracefile=C:\temp\tls_capture.etl

# Reproduce the TLS connection issue
# Stop capture
netsh trace stop

# Convert to pcap for Wireshark analysis
pktmon start --etw -f C:\temp\tls_packets.etl
# Reproduce issue
pktmon stop
pktmon etl2txt C:\temp\tls_packets.etl

Monitor Schannel events in real-time:

# Monitor Schannel events as they occur
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'} -MaxEvents 1 | Wait-Event

# Create custom event subscription
wevtutil cs schannel_monitor.xml
# Where schannel_monitor.xml contains subscription configuration

Analyze TLS handshake timing and performance:

# Use Performance Toolkit for detailed analysis
wpr -start GeneralProfile -start CPU -start Network
# Reproduce TLS issue
wpr -stop C:\temp\tls_analysis.etl

# Analyze with Windows Performance Analyzer
wpa C:\temp\tls_analysis.etl
Warning: Verbose logging can generate significant log volume and should be disabled after troubleshooting to prevent performance impact.

Overview

Event ID 36874 fires when the Windows Schannel security provider encounters a TLS handshake failure during secure connection establishment. This event appears in the System log whenever a client or server cannot complete the initial TLS negotiation phase, which is critical for establishing encrypted communications. The event typically includes details about the remote endpoint, protocol version, and specific failure reason.

Schannel is Windows' native implementation of the SSL/TLS protocols, handling all secure socket layer communications for the operating system and applications. When this event occurs, it indicates that the cryptographic negotiation between two endpoints has failed, preventing the establishment of a secure channel. This can affect web browsers, email clients, remote desktop connections, and any application relying on TLS encryption.

The event becomes particularly relevant in enterprise environments where strict security policies, certificate management, and protocol compliance are enforced. Modern Windows systems in 2026 have enhanced TLS 1.3 support and deprecated older protocols, making this event more common when connecting to legacy systems or misconfigured services.

Frequently Asked Questions

What does Event ID 36874 mean and when does it occur?+
Event ID 36874 indicates a TLS handshake failure in the Windows Schannel security provider. It occurs when a client or server cannot complete the initial TLS negotiation phase required to establish a secure connection. This happens during protocol version negotiation, cipher suite selection, certificate validation, or key exchange phases. The event includes details about the remote endpoint and specific failure reason, making it essential for diagnosing SSL/TLS connectivity issues in enterprise environments.
How do I identify which application or service is causing Event ID 36874?+
To identify the source application, correlate the event timestamp with application logs and network connections. Use PowerShell command 'Get-NetTCPConnection | Where-Object {$_.State -eq "Established" -and $_.RemotePort -eq 443}' to see active HTTPS connections. Check application-specific logs in Event Viewer under Applications and Services Logs. For IIS servers, examine IIS logs for failed SSL negotiations. Process Monitor (ProcMon) can also track which processes are attempting network connections during the timeframe when Event ID 36874 occurs.
Can Event ID 36874 be caused by Windows Updates or Group Policy changes?+
Yes, Windows Updates and Group Policy changes frequently cause Event ID 36874. Security updates in 2026 have strengthened TLS requirements, potentially disabling older protocols like TLS 1.0 and 1.1. Group Policy settings under Computer Configuration > Administrative Templates > Network > SSL Configuration Settings can restrict cipher suites or protocol versions. Recent updates may also update the certificate trust store, causing previously trusted certificates to become invalid. Always review recent policy changes and Windows Update history when troubleshooting sudden TLS handshake failures.
What's the difference between Event ID 36874 and other Schannel error events?+
Event ID 36874 specifically indicates handshake failures during initial TLS negotiation. Event ID 36888 typically relates to certificate validation errors after successful protocol negotiation. Event ID 36870 indicates fatal alerts received from the remote endpoint. Event ID 36871 shows successful TLS connections for comparison. Event ID 36874 occurs earlier in the connection process than certificate-specific errors, making it broader in scope and often indicating protocol-level incompatibilities rather than just certificate issues.
How can I prevent Event ID 36874 in a mixed Windows environment with legacy systems?+
In mixed environments, implement a phased approach to TLS modernization. Use Group Policy to configure TLS settings consistently across domain-joined systems. Enable TLS 1.2 and 1.3 while temporarily maintaining TLS 1.1 compatibility for legacy systems. Deploy intermediate certificates to all systems and ensure certificate chains are complete. Use PowerShell DSC or Group Policy Preferences to standardize cipher suite configurations. Monitor Event ID 36874 patterns to identify legacy systems requiring updates. Consider implementing a TLS proxy or load balancer to handle protocol translation between modern and legacy systems during the transition period.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...