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

Question

Recently deployed a Windows 2016 Standard Server, with Active Directory and Exchange 2016.

We have disabled SSL 1.0, 2.0 and 3.0 for both Server and Client, and have disabled TLS 1.0 and TLS 1.1.

We are repeatedly getting the following entry in our system log. What is causing this, and how can I fix it.

Abjuration

We also saw the exact same error after the last round of Windows updates for October, 2018. Not sure of the exact cause yet. On Windows 10, the only update I am seeing that looks like it might matter is KB4462933. The only other update installed for October patches is for Adobe Flash. I'm pretty sure that is not causing anything. I'll post an answer or update if I find anything else. Oh, and we also have FIPS turned on and disabled SSL 3.0, TLS 1.0, and TLS 1.1. Turning off FIPS and re-enabling TLS 1.0 seems to work for now as a workaround. Remember to reboot after changes though. – Monolith

I can't enable TLS 1.0 otherwise our PCI compliance scan fails. – Abjuration

Surely you need to keep in mind that this is exactly what should happen. You prevent apps from using a secure connection of the wrong flavor. Next you need to find out exactly which ones generates this diagnostic so you can fix/uninstall them. Find people that troubleshoot this stuff every day on a site like serverfault.com – Cytoplast

I have the same problem. I have TLS 1.2 and 1.1 enabled but get the error message. One thing is I do NOT have IIS installed and this is a Win10 client machine not a server. – Countersignature

Answer 1

Basically we had to enable TLS 1.2 for .NET 4.x. Making this registry changed worked for me, and stopped the event log filling up with the Schannel error.

More information on the answer can be found here

Linked Info Summary

Enable TLS 1.2 at the system (SCHANNEL) level:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

(equivalent keys are probably also available for other TLS versions)

Tell .NET Framework to use the system TLS versions:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001

This may not be desirable for edge cases where .NET Framework 4.x applications need to have different protocols enabled and disabled than the OS does.

Abjuration

I used IIS Crypto GUI (nartac.com/Products/IISCrypto) to make these registry changes after experiencing the same error. Just click "Best practices" then "Apply". Reboot. Job done 👍🏼 – Jaine

Neither manually adding to the registry nor using IISCrypto worked for me. Still looking for a solution as having 4 or these errors every 10 seconds means it's almost impossible to check for anything else in the event log. – Guayaquil

Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name SystemDefaultTlsVersions -Value 1 Set-ItemProperty 'HKLM:\SOFTWARE\wow6432node\Microsoft\.NETFramework\v4.0.30319' -Name SystemDefaultTlsVersions -Value 1 – Jamila

I too resolved this issue with IISCrypto, but I suspect making changes with that application also caused the problem in the first place. – Wearproof

This does NOT work for me. Any other ideas? – Seton

Same problem (windows 2016 - minus the exchange issue) Added items to registry - looks like the only time the 4673 appears is when I check the event log. Pretty strange. This fix did not work for me. – Audry

Answer 2

After none of the methods I could find anywhere helped me: I opened the Event Viewer and searched when this error started to show so often. I used filter set to Error from Schannel source. In my case, this error was happening every now and then but then, on certain date, it started to show every few seconds! I went to Settings -> Apps & features and searched if anything new was installed on this date – and bingo! It was PrivadoVPN. After uninstalling PrivadoVPN, the error stopped to show!

P.S. I’m not saying that specifically PrivadoVPN is problematic. Mybe it is something with my configuration… Just suggesting the method I used to find the root cause of the error in my case.

Unaesthetic

Answer 3

After making no changes to a production server we began receiving this error. After trying several different things and thinking that perhaps there were DNS issues, restarting IIS fixed the issue (restarting only the site did not fix the issue). It likely won't work for everyone but if we tried that first it would have saved a lot of time.

Corner

Answer 4

In my case, the Windows 2016 server where this was happening was hardened for security compliance. As a result, only specific cipher suites were allowed. This was causing an incompatibility when making HTTPS connections to highly secure endpoints (like Apple Push Notifications API aka APNS)

To fix the issue, I downloaded IIS Crypto and clicked on the Cipher Suites button on the left, to display the list of enabled/disabled cipher suites, and then clicked the "Best Practices" button and rebooted the server. Problem fixed.

Lions

Answer 5

I encountered this while rebuilding a server that was moving from Server 2012R2 to DataCenter 2019. It was making me crazy because I could debug it from Visual Studio just fine but IIS immediately returned a 500 error.

In my case, we have several .NET 3.5 and .NET 4.5 applications commingled on the same server and when I created the application for one of the 4.5 applications I had pointed it to the 2.0 App Pool.

Repointing it to the 4.0 App Pool resolved the issue.

Patrizius

Answer 6

I found this here: https://port135.com/schannel-the-internal-error-state-is-10013-solved/

"Correct file permissions Correct the permissions on the c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder:

Everyone Access: Special Applies to 'This folder only' Network Service Access: Read & Execute Applies to 'This folder, subfolders and files' Administrators Access: Full Control Applies to 'This folder, subfolder and files' System Access: Full control Applies to 'This folder, subfolder and Files' IUSR Access: Full Control Applies to 'This folder, subfolder and files' The internal error state is 10013 After these changes, restart the server. The 10013 errors should disappear."

Weltanschauung

I don't know why this one is getting no love. None of the registry hacks worked for me but this did with regard to eliminating the System event log entries. It still doesn't fix the issue I'm having with making connections to TLS v1.x using .NET APIs in Windows 11. – Chigoe

I haven't disliked you, but your post is "unreadable" and in this format hard to understand. You even made no Newline. You should do a better format and maybe add a snapshot of what you did. BTW: The hacks you mentioned didn't work for me either. But my Laptop is managed by Company and your proposal is also not possible for me. – Tiliaceous