我正在研究一项要求ASP.Net C＃中的PDF文件具有数字签名的要求，并开发了一个应用程序，该应用程序使用本地计算机上的USB令牌获得了客户端证书。但是，在IIS服务器上托管此应用程序时，出现错误“当前会话不是交互式”。
任何人都有任何想法，我们如何才能从ASP.Net C＃中的客户端计算机获取X509证书，并且此应用程序托管在IIS服务器上而不是控制台应用程序。
我的代码供参考：
private void getSign()
{
X509Store store = new X509Store(StoreLocation.CurrentUser);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
X509Certificate2 cert = null;
//manually chose the certificate in the store
X509Certificate2Collection sel = X509Certificate2UI.SelectFromCollection(store.Certificates, null, null, X509SelectionFlag.SingleSelection);
if (sel.Count > 0)
cert = sel[0];
else
{
//MessageBox.Show("Certificate not found");
return;
}
SignWithThisCert(cert);
}
最佳答案
免责声明：尽管这不是您问题的直接答案，但可能会包含一些指导，供您根据业务需求找到正确的方法。您的问题有两个主要问题。我曾尝试在评论中讨论其中之一，但可能需要解释。
让我们尝试分析您的初始帖子：
任务：让用户将PDF上载到Web应用程序并进行签名。
要求：PDF必须使用存储在客户端USB令牌上的证书签名。
您建议的解决方案：（从客户端）获取客户端证书并在服务器端执行签名。
让我们对方案中使用的术语和操作进行形式化。
签名：文档签名用于保证文档的完整性，并确保文档在签名后不被篡改。数字签名提供有关执行签名的实体的信息。这增加了不可否认功能。签名后，签名人无法否认签名事实，并在签名时证明文档中的信息是正确的。非对称签名需要私钥。关联的公钥可用于验证和验证签名。
私钥：是属于特定客户端的密钥对的一部分。没有人应该知道私钥。
安全边界：客户端（Web浏览器或其他Web客户端）和Web服务器在不同的安全边界中运行并且具有不同的信任级别。他们处于不同的行政控制之下。结果，Web服务器对客户端计算机/数据的访问非常有限，反之亦然：Web客户端对服务器计算机/数据的访问非常有限。
您提出的设计假设客户选择文档并将其上传到服务器。然后，客户端选择签名证书（特别是私钥），并将其上载到服务器以进行签名操作。
问题1：一旦私钥离开客户端并复制到您的Web应用程序中，您将打破安全边界。结果，密钥不再是私有的，因为Web应用程序拥有私有密钥的知识并将其存储（即使是临时存储在服务器内存中）。或者，简而言之，密钥被泄露和泄露。
客户不再对其密钥以及该密钥进行的操作负责。客户可以拒绝使用其私钥所做的任何事情。并拒绝您的Web应用程序所做的签名。
问题2：您的拟议设计假设PDF已照原样复制到服务器。然后才签名。但是，一旦文档（或更确切地说，其确切的二进制副本）接触网络，客户端就不再对文档的准确性负责。因为文档可能会在运输过程中或某些在客户端和文档签名代码之间触及该文档的代码发生转换。
一旦文档离开客户端计算机，客户端就不再负责文档的完整性，因为文档会通过各种代码传递，这些代码将文档组合成适合传输格式的格式（例如封装）。结果，客户端发送的文档和服务器端的文档签名代码接收到的文档可能会不同。无法保证文件的完整性。尽管可以在传输过程中应用TLS来保护文档，但是仍然存在可以匿名篡改文档的地方，没有人会注意到这一点。
同样，由于客户端不能保证Web应用程序接收到与他发送的文档相同的事实，因此客户端可以拒绝您要签名的文档并拒绝签名。因此，使签名无用，因为它不能证明任何事情。
问题＃3 ：（不是真正的问题，但值得解释），前提是一段代码没有执行预期的任务（即使它看起来在开发环境中也可以工作）。您的目标是在客户端上调用证书选择对话框以选择适当的证书。
在测试期间，您正在本地运行所有代码。在调试器中，Web应用程序在当前登录的用户（交互式会话）下运行，并且能够显示证书选择对话框。但是，由于客户端和服务器都在同一台计算机上并在相同的安全上下文下运行，因此您不能轻易地确定在哪个上下文（客户端或服务器）中执行它。实际上，它是在服务器上下文下调用的。
将应用程序部署到Web服务器时，您会看到不同之处。 Web应用程序在某些应用程序池上下文（用户帐户）下运行，并且此会话不是交互式的。结果，X509Certificate2UI类无法显示该对话框，因为没有人可以看到该对话框，也没有人可以按其上的按钮。无论客户端和服务器运行在相同或不同的计算机上，此行为都是一致的，因为IIS（或其他Web服务器）会立即将关注点和安全性边界分开，而调试器则不会。客户端和服务器肯定会在不同的安全上下文下运行。即使您强制使用相同的上下文，IIS也会进行辅助的非交互式用户会话来运行Web应用程序。
为了在客户端上显示证书选择对话框，您必须与客户端进行深层交互，例如，通过Silverlight（不确定X509Certificate2UI在Silverlight中是否可用）或某些ActiveX控件。您必须在客户端运行一些代码才能完成此任务。
上述所有内容均显示了初始设计中的潜在问题，它们只是破坏了基本的安全规则。设计技术和工具时要遵循这些规则，而不是破坏它们。通过追求最初的设计，您将被迫不断地与破坏它们的技术作斗争，并使您的应用程序非常不安全且容易受到攻击。
首选解决方案：我们确定了设计中的常见风险：客户端与服务器上的签名代码之间的密钥泄漏和文档完整性。为了轻松缓解所有这些问题，您应该做的唯一一件事：在客户端执行文档签名。这样，签名私钥将永远不会从客户端泄漏，并且在Web应用程序签名和接收的过程中，将保证文档的完整性。
现在，我们可以讨论证书属性。您的要求是使用存储在USB令牌中的证书。我不知道您在这里指的是哪种代币。是带有PFX的标准USB大容量存储，或者是加密设备（带有USB接口的智能卡，通常称为USB令牌。例如，Aladdin（SafeNet）eToken设备）。
如果它是USB大容量存储设备，那么它就不是要求的一部分，因为通用USB驱动器无法提供任何有助于识别证书来源的信息。可以轻松将任何证书复制到USB驱动器，也可以从USB驱动器复制任何证书。
如果是USB智能卡，则有一种方法可以识别证书是来自此设备还是其他来源。智能卡具有一个独特的属性：私钥永远不会离开卡。所有操作都在卡上执行（这是与PC上存储的证书相比它们运行缓慢的原因）。
这通常是通过在证书颁发过程中向签名证书添加额外的信息来实现的。例如，通过添加Certificate Policies证书扩展名。这将要求CA操作员/经理确保将具有指定证书策略的证书仅部署到智能卡。
如果建立了这些过程，则可以在服务器端使用接受签名的PDF文档并检查签名证书内容的代码。例如，您阅读了证书策略，并希望在那里看到特定的条目。如果显示了该密钥，则可以安全地假定使用存储在智能卡上的证书对文档进行了签名，因为无法将密钥从卡设备复制到任何地方。如果证书在证书策略中不包含特定条目，则可以拒绝文件接受并要求客户端使用正确的证书。
关于c# - 在IIS上托管的C#中使用USB token 打开X509证书选择，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46686462/