Solved: SSL/TLS Handshake Failed Error in IIS on Windows Server 2025
Quick Fix Summary
TL;DRRestart IIS, verify the certificate is valid and bound correctly, and ensure TLS 1.2 is enabled in the registry.
The SSL/TLS handshake failed error in IIS indicates a breakdown in the secure communication negotiation between the server and client. This prevents HTTPS traffic from flowing, effectively taking down secure web services.
Diagnosis & Causes
Recovery Steps
Step 1: Immediate Service Restart & Basic Check
First, perform a controlled restart of IIS and verify the certificate is present and not expired. This resolves transient states and confirms certificate basics.
iisreset /restart
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*your-domain.com*"} | Select-Object Subject, NotAfter, ThumbprintStep 2: Verify and Correct IIS Certificate Binding
Ensure the correct certificate is bound to the correct IP:Port:Hostname combination in IIS. A mismatch here is a common root cause.
netsh http show sslcert
# To remove an incorrect binding:
netsh http delete sslcert ipport=0.0.0.0:443
# To add the correct binding (Use cert hash from Step 1):
netsh http add sslcert ipport=0.0.0.0:443 certhash=YOUR_CERT_THUMBPRINT appid="{4dc3e181-e14b-4a21-b022-59fc669b0914}"Step 3: Enable Strong TLS Protocols via Registry
Windows Server 2025 may have legacy protocols disabled by default. Explicitly enable TLS 1.2 and 1.3 at the system level.
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Name "Enabled" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force
# Repeat for 'TLS 1.2\Client' and 'TLS 1.3' keys if needed.Step 4: Audit and Align Cipher Suite Order
Weak or incompatible cipher suites can break handshakes. Use the IIS Crypto tool or PowerShell to prioritize strong, modern ciphers.
# Get current cipher suite order
Get-TlsCipherSuite | Format-Table Name, Priority
# Set a strong, compatible cipher suite order (Example)
$Suites = @('TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384','TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256')
Set-TlsCipherSuite -CipherSuite $SuitesStep 5: Validate from a Client and Check Schannel Logs
Test the fix externally and examine the Windows System Event Logs for Schannel errors (Event ID 36871, 36872, 36888) which provide precise failure reasons.
openssl s_client -connect your-server.com:443 -tls1_2
# Check Windows Event Viewer for Schannel errors
Get-WinEvent -LogName "System" -FilterXPath "*[System[Provider[@Name='Schannel'] and (EventID=36871 or EventID=36872 or EventID=36888)]]" -MaxEvents 10 | Format-ListArchitect's Pro Tip
"For Azure-hosted VMs, the platform-managed 'Azure TLS/SSL Certificate' resource can silently override IIS bindings. Always sync bindings via the Azure Portal or ARM templates."
Frequently Asked Questions
I get 'The specified logon session does not exist' when running netsh commands. What's wrong?
Run your command prompt or PowerShell as Administrator. Elevated privileges are required to modify system-level SSL bindings.
The handshake works locally but fails from the internet. What should I check?
This points to a network intermediary. Check your firewall (NSG/AWS SG), load balancer (Azure App Gateway, AWS ALB), or WAF for TLS termination or protocol inspection blocking the handshake.
How do I know if my certificate chain is trusted?
Run 'Test-NetConnection -ComputerName your-server.com -Port 443' in PowerShell 7+, or use the SSL Labs SSL Test online tool for a deep analysis of the chain and client compatibility.