创建 TLS 客户端凭据时发生致命错误。内部错误状态为 10013

Posted 2023-02-22

【中文标题】创建 TLS 客户端凭据时发生致命错误。内部错误状态为 10013

【英文标题】：A fatal error occurred while creating a TLS client credential. The internal error state is 10013

【发布时间】：2019-04-06 21:24:49

【问题描述】：

最近部署了 Windows 2016 Standard Server，带有 Active Directory 和 Exchange 2016。

我们已为服务器和客户端禁用 SSL 1.0、2.0 和 3.0，并已禁用 TLS 1.0 和 TLS 1.1。

我们的系统日志中反复出现以下条目。这是什么原因造成的，我该如何解决。

【问题讨论】：

在 2018 年 10 月的最后一轮 Windows 更新之后，我们也看到了完全相同的错误。尚不确定确切原因。在 Windows 10 上，我看到的唯一看起来可能很重要的更新是 KB4462933。为 10 月补丁安装的唯一其他更新是用于 Adob​​e Flash。我很确定这不会导致任何事情。如果我发现任何其他内容，我会发布答案或更新。哦，我们还启用了 FIPS 并禁用了 SSL 3.0、TLS 1.0 和 TLS 1.1。关闭 FIPS 并重新启用 TLS 1.0 目前似乎可以作为一种解决方法。不过记得在更改后重新启动。

我无法启用 TLS 1.0，否则我们的 PCI 合规性扫描会失败。

您当然需要记住，这正是应该发生的。您可以防止应用程序使用错误风格的安全连接。接下来，您需要准确找出哪些会生成此诊断信息，以便您可以修复/卸载它们。在 serverfault.com 等网站上查找每天解决这些问题的人

【参考方案1】：

基本上，我们必须为 .NET 4.x 启用 TLS 1.2。更改此注册表对我有用，并停止事件日志填满 Schannel 错误。

更多关于答案的信息可以找到here

链接信息摘要

在系统 (SCHANNEL) 级别启用 TLS 1.2：

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

（等效密钥可能也可用于其他 TLS 版本）

告诉 .NET Framework 使用系统 TLS 版本：

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

对于 .NET Framework 4.x 应用程序需要启用和禁用与操作系统不同的协议的边缘情况，这可能是不可取的。

【讨论】：

在遇到相同错误后，我使用 IIS Crypto GUI (nartac.com/Products/IISCrypto) 进行了这些注册表更改。只需单击“最佳实践”，然后单击“应用”。重启。工作完成??

手动添加到注册表或使用 IISCrypto 都不适合我。仍在寻找解决方案，因为每 10 秒出现 4 个或这些错误意味着几乎不可能在事件日志中检查其他任何内容。

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

我也用 IISCrypto 解决了这个问题，但我怀疑对该应用程序进行更改也会导致问题摆在首位。

这对我不起作用。还有其他想法吗？

【参考方案2】：

未对生产服务器进行任何更改后，我们开始收到此错误。在尝试了几种不同的方法并认为可能存在 DNS 问题后，重新启动 IIS 解决了问题（仅重新启动站点并没有解决问题）。它可能不会对每个人都有效，但如果我们先尝试它会节省很多时间。

【参考方案3】：

就我而言，发生这种情况的 Windows 2016 服务器已针对安全合规性进行了强化。结果，只允许使用特定的密码套件。在与高度安全的端点（如 Apple Push Notifications API aka APNS）建立 HTTPS 连接时，这会导致不兼容

为了解决这个问题，我下载了IIS Crypto 并单击左侧的密码套件按钮，以显示启用/禁用密码套件的列表，然后单击“最佳实践”按钮并重新启动服务器。问题已解决。

【参考方案4】：

我在这里找到了这个：https://port135.com/schannel-the-internal-error-state-is-10013-solved/

"正确的文件权限 更正 c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys 文件夹的权限：

所有人都可以访问：特别适用于“仅此文件夹” 网络服务访问：读取和执行适用于“此文件夹、子文件夹和文件” 管理员访问：完全控制适用于“此文件夹、子文件夹和文件” 系统访问：完全控制适用于“此文件夹、子文件夹和文件” IUSR 访问：完全控制适用于“此文件夹、子文件夹和文件” 内部错误状态为 10013 完成这些更改后，重新启动服务器。 10013 错误应该会消失。”

【讨论】：

我不知道为什么这个人没有得到爱。没有一个注册表黑客对我有用，但这确实消除了系统事件日志条目。它仍然无法解决我在 Windows 11 中使用 .NET API 连接到 TLS v1.x 时遇到的问题。