.NET Core X509Certificate2.PrivateKey引发nte

本文介绍了.NET Core X509Certificate2.PrivateKey引发nte_bad_keyset错误的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

当尝试使用以下代码从 X509Store 获取 X509Certificate2 对象时：

When trying to get a X509Certificate2 object from the X509Store using the following code:

private X509Certificate2 GetKey() { try { X509Store store = new X509Store("WebHosting", StoreLocation.LocalMachine); store.Open(OpenFlags.ReadOnly); var collection = store.Certificates.Find(X509FindType.FindBySubjectName, "xxxxxxx", true); if (collection.Count == 0) { throw new Exception("No keys matched"); } if (collection.Count > 1) { StringBuilder sb = new StringBuilder(); sb.Append("More than 1 key matched:\r\n"); foreach (var cert in collection) { sb.Append($"{cert.SubjectName} - {cert.Thumbprint}\r\n"); } throw new Exception(sb.ToString()); } return collection[0]; } catch (Exception ex) { // something really bad happened, log it Logger.LogException(ex); throw; } }

我成功获得了密钥；但是，当尝试使用 key.PrivateKey 在对象内获取私钥时，出现以下错误： OpenCSP失败，错误代码2148073494。 / code>查找Windows错误2148073494，我得到 nte_bad_keyset 。 此处他们修正了该错误。当我在控制台应用程序中运行这段代码时，它可以正常工作，并且在我在IISExpress下运行的测试环境中也可以正常工作。在IIS下的生产环境中运行时，每次都会出现此错误。我尝试在管理员用户的上下文中运行，只是为了确保它不是奇怪的权限错误，这是一样的。根据我对Windows错误的了解，Windows向我提供了密钥的存放位置，然后告诉我该地址没有任何内容。我为此使用 System.Security.Cryptography.Algorithms： 4.3.0 。

I successfully get the key; however, when trying to get the private key within the object using key.PrivateKey, I get the following error: OpenCSP failed with error code 2148073494. Looking up the Windows error 2148073494, I get nte_bad_keyset. It looks like there have been errors around other situations that throw this same error here, but they closed that bug as fixed. When I run this bit of code in a console app, it works fine and it also works fine in my test environment running under IISExpress. When run in a production environment under IIS, I get this error every time. I've tried running under the context of an admin user just to make sure it wasn't an odd permission error, same thing. From what I understand about this Windows error, is that Windows gave me where the key lives, then told me there is nothing at that address. I'm using "System.Security.Cryptography.Algorithms": "4.3.0" for this.

编辑：我应该注意，作为测试的一部分，我实际上从生产环境中获取了我要查找的确切证书，并将其加载到测试环境中。我还在生产环境上运行了控制台应用程序，使用了相同的密钥，并且运行良好。

I should note that as part of my testing, I actually grabbed the exact certificate I'm looking for from the production environment onto my test environment and it loaded fine. I also ran the console app on the production environment pulling the same key and it worked fine.

推荐答案

最终，答案是某事在将私钥导入证书存储区后删除了私钥（或者，也许Windows可能会记住它居然不在其中，而记住它在哪里）。

Ultimately, the answer is "something deleted the private key after importing it to the certificate store" (or, maybe it's possible to confuse Windows into remembering where a key lives despite it not actually living there).

例如，如果您知道它可以工作一会儿然后停止：

If you know that it, for example, works for a little while then stops:

> certutil -store my ... ================ Certificate 6 ================ Serial Number: 3451b93c10f9279348a949f729d1ff10 Issuer: CN=localhost NotBefore: 1/26/2015 2:19 PM NotAfter: 1/25/2020 4:00 PM Subject: CN=localhost Signature matches Public Key Root Certificate: Subject matches Issuer Template: Cert Hash(sha1): 15 e3 4c d3 2d a7 54 99 a9 17 8f 17 26 25 63 25 8f 3a 94 28 Key Container = IIS Express Development Certificate Container Unique container name: fad662b360941f26a1193357aab3c12d_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd Provider = Microsoft RSA SChannel Cryptographic Provider Encryption test passed CertUtil: -store command completed successfully.

看到它位于 Microsoft RSA SChannel加密提供程序中，请转到 msdn.microsoft/zh-CN/库/windows/desktop/bb204778(v=vs.85).aspx ，看到密钥文件位于％ALLUSERSPROFILE％\Application Data\Microsoft\Crypto\ RSA\MachineKeys 。 唯一容器名称恰好是它将拥有的文件的名称。

Seeing that it's in "Microsoft RSA SChannel Cryptographic Provider", turn to msdn.microsoft/en-us/library/windows/desktop/bb204778(v=vs.85).aspx and see that the keyfile will be located at %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys. The Unique container name happens to be the name of the file it'll have.

因此，打开该目录，右键单击文件。

So, open that directory, right click on the file.

• 属性
• 安全选项卡
• 高级按钮
• 审核选项卡
• 编辑按钮
• 添加按钮
• 键入每个人，按检查名称，选择每个人，按OK，然后按OK。
• 检查删除：成功。
• 单击确定以关闭所有对话框。

• Properties
• Security Tab
• Advanced button
• Auditing tab
• Edit button
• Add button
• Type "Everyone", push "Check Names", pick "Everyone", hit OK, hit OK.
• Check Delete: Success.
• Hit OK to dismiss all the dialogs.

稍后，在开始出现键集错误后，请在安全日志中搜索对该文件删除进行审核（来自安全性审核的事件4663）：

Later, after you start getting keyset errors, search the security log for an audit on the file delete (event 4663 from Security-Auditing):

An attempt was made to access an object. Subject: Security ID: SOMEDOMAIN\theaccount Account Name: theaccount Account Domain: SOMEDOMAIN Logon ID: 0xabcdef Object: Object Server: Security Object Type: File Object Name: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\fad662b360941f26a1193357aab3c12d_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd Handle ID: 0xef8 Process Information: Process ID: 0xf54 Process Name: C:\Windows\explorer.exe Access Request Information: Accesses: DELETE Access Mask: 0x10000

这将告诉您删除进程是由哪个进程/用户执行的……也许这足以确定出了什么问题。

That will tell you what process/user did the delete operation... and maybe that'll be enough to identify what went wrong.

您大概可以更编程地进行私钥文件的标识和审核注册；但这是我知道的最快解释方法。

You could presumably do the private key file identification and audit registration more programmatically; but this was the quickest way I knew to explain it.