我感觉这与 AppPool 的权限有关，但由于此应用程序托管在 Azure 中，因此无法更改它。
我的代码在控制台应用程序中运行，并且当 AppPool 设置为以用户（我自己）身份运行时。当 AppPool 设置为作为 ApplicationIdentity 运行并且服务托管在 Azure 中时，它无法运行（如果需要，我将发布代码，但我不认为这就是问题所在）。
我是否从存储、文件或字节数组加载证书并不重要。结果是一样的。
我不知道哪些信息有助于诊断此问题，但似乎链/路径在权限降低的情况下不会加载。调用 .Verify() 在控制台应用程序（以及以我的用户身份运行的 IIS）中返回 true，在 ApplicationIdentity 下返回 false。
在这两种情况下，证书似乎都能正常加载并包含私钥。
I've a feeling it's something to do with the permissions of the AppPool but as this app is hosted in Azure it's not possible to change that.
My code works in a console app and when the AppPool is set to run as a user (myself). It fails to run when the AppPool is set to run as ApplicationIdentity and when the service is hosted in Azure (I'll post the code if requested, but I don't think that's where the problem lies).
It doesn't matter whether I load the certificate from a store, from a file, or from a byte array. The results are the same.
I don't know what information will be helpful in diagnosing this but it appears that the chain/path doesn't load under the reduced privileges. Calling .Verify() returns true in the console app (and IIS running as my user) and false under ApplicationIdentity.
The certificate appears to load normally and contains a private key in both circumstances.
发布评论
评论（2）
事实证明，我的问题与此问题中列出的问题相同。我需要设置我的证书，以便其中一些证书位于 CA 和信任部分，以便正确构建链。
我安装了所有证书，但证书的位置似乎也很重要，而且它与安全性或哪个用户登录根本无关！
It turns out my problem was the same listed in this question. I needed to set my certificates up so that some of them were in the CA and Trust section so that the chain was built correctly.
I had all of the certificates installed but it would appear that the location of the certificate is important as well, and it was nothing to do with security or which user was logged on at all!
您可以更改 Azure 中的几乎所有内容。默认情况下，它是完整的 IIS（如果您不是从 SDK 1.3 或更早版本升级）。有几个选项可供尝试：
（这个是错误的！由 Steve Marx 指出）尝试在提升模式下运行应用程序（在本例中为 IIS AppPool）。这将使 AppPool 在“SYSTEM”帐户下运行，而不是在 AppPoolIdentity 下运行。您可以通过添加 来做到这一点; .CSDEF 文件中角色定义中的元素。
您可以为所有角色启用远程桌面。这将有效地在您的角色实例中创建一个帐户并将其添加到管理员组。然后，您可以使用启动任务和 powershell 脚本来更改 AppPool 身份以使用该帐户： Wade Wegner 撰写的关于如何以编程方式更改 AppPool 身份的博客文章。
好吧，这些都是让您的应用程序池在提升模式下运行的方法，但也表明您可以在 Windows Azure 实例上使用 IIS 执行几乎所有操作。我建议仅将在提升模式下运行的站点用于测试目的。首先让您的代码在本地 IIS 上的受限帐户中运行。然后查看您更改了哪些内容以使其在本地运行，并将这些更改应用到 Azure Web 角色。
编辑
另一件需要注意的事情是，为了使 .Verify() 工作，您必须拥有颁发已检查证书的 CA 的根证书，并安装在 Web 角色上。这可以通过从管理门户添加根 CA 证书作为“服务证书”来完成。此外，颁发已检查证书的 CA 必须是可信的。
You can change almost anything in Azure. It is full IIS (if you are not upgrading from SDK 1.3 or earlier) by default. There are couple of options to try:
(This one is wrong! Noted by Steve Marx)Try jus trunning the application (in this case IIS AppPool) in Elevated mode. That will make AppPool running under "SYSTEM" account, instead of AppPoolIdentity. You can do that by adding a <runtime executionContext="elevated" /> element in your role definition in .CSDEF file.
You can enable remote desktop to all your roles. That will effectively create an account in your role instance and add it to the Administrators group. Then you can use a startup task and powershell script to change AppPool identity to use that account instead: A blog post by Wade Wegner on how to programatically change AppPool Identity.
Well, these all are ways to make your application pool runs in Elevated mode, but also show that you can do pretty much everything with IIS on your Windows Azure Instance. I suggest to use site runing in elevated mode only for testing purposes. First make your code run in restricted account on local IIS. Then see what you changed to make it wokrk locally and apply these changes on the Azure Web Role.
EDIT
Another thing to pay attention is that in order .Verify() to work, you must have the Root Certificate of the CA that issued the checked certificate, installed on the web role. This can be done via adding the Root CA Certificate as a "Service Certificate" from the management portal. Also, the CA that issued the checked certificated must be trusted.