在IIS上托管的C＃中使用USB令牌打开X509证书选择
我正在制定一项要求，要求在ASP.Net C＃中对PDF文件进行数字签名，并开发了一个在我的本地机器上使用USB令牌获取客户端证书的应用程序。 但是，在IIS服务器上托管此应用程序时收到错误“当前会话不是交互式” 。
任何人都有任何想法，我们如何从ASP.Net C＃中的客户端机器获取X509Certificates，并且此应用程序托管在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); } 免责声明：虽然，它不是您的问题的直接答案，但可能包含您根据业务要求获得正确方法的指示。 您的问题有两个主要问题。 其中一个我试着在评论中讨论，但可能需要解释一下。
让我们试着分析一下你的post：
任务：让用户将PDF上传到Web应用程序并进行签名。
要求：必须使用存储在客户端USB令牌上的证书对PDF进行签名。
您提出的解决方案：获取客户端证书（来自客户端）并在服务器端执行签名。
让我们正式化您的方案中使用的术语和操作。
签名：文档签名用于保证文档的完整性，并确保文档在签名后不会以任何方式被篡改。 数字签名提供有关执行签名的实体的信息。 这增加了不可否认性function。 签名后，签名者不能否认签名事实，并certificate文件中的信息在签字时是正确的。 非对称签名需要私钥。 关联的公钥可用于validation和validation签名。
私钥：是属于特定客户端的密钥对的一部分。 没有人应该知道私钥。
安全边界：客户端（Web浏览器或其他Web客户端）和Web服务器在不同的安全边界中运行，并具有不同的信任级别。 他们受到不同的行政控制。 结果，Web服务器对客户端机器/数据的访问非常有限，反之亦然：Web客户端对服务器机器/数据的访问非常有限。
您提出的设计假定客户端选择文档并将其上载到服务器。 然后，客户端选择签名证书（特别是私钥）并将其上载到服务器以进行签名操作。
问题＃1：一旦私钥离开客户端并被复制到您的Web应用程序，您就会破坏安全边界。 结果，密钥不再是私有密钥，因为Web应用程序拥有私钥的知识，并且它（即使是临时的）存储在服务器内存中。 或者，简单来说，密钥泄漏并受到损害。
客户不再对密钥所做的密钥和操作负责。 客户可以拒绝使用其私钥进行的任何操作。 并拒绝您的Web应用程序所做的签名。
问题＃2：您提出的设计假设PDF按原样复制到服务器。 只有这样才签署。 但是，一旦文档（或其精确的二进制副本，更准确）触及网络，客户端就不再负责文档的准确性。 因为文档可能在传输过程中被转换，或者某些代码在客户端和文档签名代码之间触摸文档。
一旦文档离开客户端机器，客户端就不再负责文档完整性，因为文档通过组成文档的各种代码传递到适合于传输格式（例如封装）。 结果，客户端发送的文档和服务器端的文档签名代码收到的文档可能不一样。 文件的完整性无法保证。 虽然，您可以在传输过程中应用TLS来保护文档，但仍有一些地方可能会匿名篡改文档，没有人会注意到这一点。
同样，由于客户端无法保证Web应用程序收到他发送的同一文档，客户端可以拒绝您尝试签名的文档并拒绝签名。 因此，使签名无用，因为它没有任何证据。
问题3 🙁不是真正的问题，但值得解释）提供的代码片段不执行预期的任务（即使它看起来在开发环境中工作）。 您的目标是在客户端上调用证书选择对话框以选择适当的证书。
在测试期间，您将在本地运行所有代码。 在调试器中，Web应用程序在当前登录的用户（即交互式会话）下运行，并且能够显示证书选择对话框。 但是，您无法轻易识别它在哪个上下文（客户端或服务器）中执行，因为客户端和服务器都在同一台机器上并在相同的安全上下文中运行。 实际上，它是在服务器上下文中调用的。
将应用程序部署到Web服务器时，您会看到不同之处。 Web应用程序在某些应用程序池上下文（用户帐户）下运行，并且此会话不是交互式的。 结果， X509Certificate2UI类无法显示对话框，因为没有人会看到它，没有人可以按下它上面的按钮。 无论客户端和服务器是在相同或不同的计算机上运行，这种行为都是一致的，因为IIS（或其他Web服务器）会立即将关注点和安全边界分开，而调试器则不会。 客户端和服务器肯定会在不同的安全环境下运行。 即使您强制使用相同的上下文，IIS也会创建一个辅助非交互式用户会话来运行Web应用程序。
为了在客户端上显示证书选择对话框，您必须与客户端进行深度交互，例如，通过Silverlight（不确定Silverlight中是否有X509Certificate2UI ）或某些ActiveX控件。 您必须在客户端运行一些代码才能完成此任务。
以上所述都显示了初始设计中的潜在问题，它们只是打破了基本的安全规则。 技术和工具旨在遵循这些规则，而不是打破它们。 通过追求您的初始设计，您将被迫不断与技术斗争，以打破它们，使您的应用程序非常不安全和易受攻击。
首选解决方案：我们确定了您设计中的常见风险：客户端与服务器上的签名代码之间的密钥泄漏和文档完整性。 为了轻松缓解所有这些，您应该做唯一的事情：在客户端执行文档签名。 通过这样做，签署私钥永远不会从客户端泄漏，文件整合将在Web应用程序签名和接收过程中得到保证。
现在，我们可以讨论证书属性。 您的要求是使用存储在USB令牌上的证书。 我不知道你的意思是什么。 是带有PFX的标准USB大容量存储器，还是加密设备（带USB接口的智能卡，通常称为USB令牌。例如，阿拉丁（SafeNet）eToken设备）。
如果它是USB大容量存储设备，那么它不能成为要求的一部分，因为通用USB驱动器不提供任何有助于识别证书来源的东西。 任何证书都可以轻松复制到USB驱动器，任何证书都可以从USB驱动器复制。
如果是USB智能卡，则有一种方法可以识别证书是来自此设备还是来自其他来源。 智能卡具有一个独特的属性：私钥永远不会离开卡。 所有操作都在卡上执行（这就是为什么它们与存储在PC上的证书相比较慢的原因）。
这通常通过在证书颁发期间向签名证书添加额外信息来实现。 例如，通过添加Certificate Policies证书扩展。 这将要求CA操作员/经理确保将具有指定证书策略的证书仅部署到智能卡。
如果建立了这些进程，则可以使用服务器端的代码来接受签名的PDF文档并检查签名证书内容。 例如，您阅读证书策略并期望在那里看到特定条目。 如果出现，那么您可以安全地假设使用存储在智能卡上的证书对文档进行了签名，因为密钥无法从卡设备复制到任何地方。 如果证书不包含证书策略中的特定条目，则您可以拒绝接受文档，并要求客户端使用适当的证书。